Rotary encoders are great devices. Monitoring just a few pins you can easily and quickly read in rotation and direction of a user input (as well as many other applications). But as with anything, there are caveats. I recently had the chance to dive into some of the benefits and drawbacks of rotary encoders and how to work with them.
I often work with students on different levels of electronic projects. One student project needed a rotary encoder. These come in mechanical and optical variants. In a way, they are very simple devices. In another way, they have some complex nuances. The target board was an ST Nucleo. This particular board has a small ARM processor and can use mbed environment for development and programming. The board itself can take Arduino daughter boards and have additional pins for ST morpho boards (whatever those are).
The mbed system is the ARM’s answer to Arduino. A web-based IDE lets you write C++ code with tons of support libraries. The board looks like a USB drive, so you download the program to this ersatz drive, and the board is programmed. I posted an intro to mbed awhile back with a similar board, so if you want a refresher on that, you might like to read that first.
Reading the Encoder
The encoder we had was on a little PCB that you get when you buy one of those Chinese Arduino 37 sensor kits. (By the way, if you are looking for documentation on those kinds of boards, look here.; in particular, this was a KY-040 module.) The board has power and ground pins, along with three pins. One of the pins is a switch closure to ground when you depress the shaft of the encoder. The other two encode the direction and speed of the shaft rotation. There are three pull-up resistors, one for each output.
I expected to explain how the device worked, and then assist in writing some code with a good example of having to debounce, use pin change interrupts, and obviously throw in some other arcane lore. Turns out that was wholly unnecessary. Well… sort of.
Continue reading “Encoders Spin Us Right Round”
Around here we love technology for its own sake. But we have to admit, most people are interested in applications–what can the technology do? Those people often have the best projects. After all, there’s only so many blinking LED projects you can look at before you want something more.
[Landingfield] is interested in astrophotography. He was dismayed at the cost of commercial camera sensors suitable for work like this, so he decided he would create his own. Although he started thinking about it a few years ago, he started earnestly in early 2016.
The project uses a Nikon sensor and a Xilinx Zynq CPU/FPGA. The idea is the set up and control the CMOS sensor with the CPU side of the Zynq chip, then receive and process the data from the sensor using the FPGA side before dumping it into memory and letting the CPU take over again. The project stalled for a bit due to a bug in the vendor’s tools. The posts describe the problem which might be handy if you are doing something similar. There’s still work to go, but the device has taken images that should appear on the same blog soon.
Continue reading “Custom Zynq/CMOS Camera Unlocks Astrophotography”
For simply getting your project connected to WiFi, a least among hacker circles, nothing beats the ESP8266. But it’s not the only player out there, and we love to see diversity in the parts and languages that we use. One of the big shortcomings of the ESP8266 is the slightly-oddball Xtensa CPU. It’s just not as widely supported by various toolchains as its ARM-based brethren.
And so, when [Zach] wanted to do some embedded work in Rust, the ESP8266 was out of the picture. He turned to the RTL8710, a very similar WiFi module made by Realtek. Documentation for the RTL8710 is, at the moment, crappy, much as the ESP8266 documentation was before the hacker community had at it. But in trade for this shortcoming, [Zach] got to use the LLVM compiler, which supports the ARM architecture, and that means he can code in Rust.
In the end, the setup that [Zach] describes is a mix of FreeRTOS and some of the mbed libraries, which should be more than enough to get you up and running fairly painlessly on the chip. We’ve actually ordered a couple of these modules ourselves, and were looking to get started in straight C, but having Rust examples working doesn’t hurt, and doesn’t look all that different.
Is anyone else using the RTL8710? An ARM-based, cheap WiFi chip should be interesting.
Every December and May the senior design projects from engineering schools start to roll in. Since the students aren’t yet encumbered with real-world detractors (like management) the projects are often exceptional, unique, and solve problems we never even thought we had. Such is the case with [Mark] and [Peter]’s senior design project: a pick and place machine that promises to solve all of life’s problems.
Of course we’ve seen pick-and-place machines before, but this one is different. Rather than identifying resistors and capacitors to set on a PCB, this machine is able to identify and sort candies. The robot — a version of the MeARM — has three degrees of freedom and a computer vision system to alert the arm as to what it’s picking up and where it should place it. A Raspberry Pi handles the computer vision and feeds data to a PIC32 which interfaces with the hardware.
One of the requirements for the senior design class was to keep the budget under $100, which they were able to accomplish using pre-built solutions wherever possible. Robot arms with dependable precision can’t even come close to that price restraint. But this project overcomes the lack of precision in the MeArm by using incremental correcting steps to reach proper alignment. This is covered in the video demo below.
Senior design classes are a great way to teach students how to integrate all of their knowledge into a final class, and the professors often include limits they might find in the real world (like the budget limit in this project). The requirement to thoroughly document the build process is also a lesson that more people could stand to learn. Senior design classes have attempted to solve a lot of life’s other problems, too; from autonomous vehicles to bartenders, there’s been a solution for almost every problem.
Continue reading “Pick-And-Place Machine for Candy”
We’re not sure why [lujji] would want to hack ST’s ST-Link programmer firmware, but it’s definitely cool that he did, and his writeup is a great primer in hacking embedded devices in two parts: first he unpacks and decrypts the factory firmware and verifies that he can then upload his own encrypted firmware through the bootloader, and then he dumps the bootloader, figures out where it’s locking the firmware image, and sidesteps the protection.
[lujji]’s project was greatly helped out by having the firmware’s encryption keys from previous work by [Taylor Killian]. Once able to run his own code on an intact device, [lujji] wrote a quick routine that dumped the entire flash ROM contents out over the serial port. This gave him the bootloader binary, the missing piece in the two-part puzzle.
If you’ve ever broken copy protection of the mid-1990’s, you won’t be surprised what happened next. [lujji] located the routine where the bootloader adds in the read protection, and NOPped it out. After uploading firmware with this altered bootloader, [lujji] found that it wasn’t read-protected anymore. Game over!
We glossed over a couple useful tips and tricks along the way, so if you’re into reversing firmware, give [lujji]’s blog a look. If you just want a nice ARM programmer with UART capabilities, however, there’s no reason to go to these extremes. The Black Magic Probe project gives you equal functionality and it’s open source. Or given that the official ST-Link programmers are given away nearly free with every Nucleo board, just buying one is clearly the path of least resistance. But a nice hack like this is its own reward for those who want to take that path. Thanks, [lujji] for writing it up.
We don’t always JTAG, but when we do, we use a Black Magic Probe. It’s a completely open ARM-chip debugging powerhouse. If you program the small ARM chips and you don’t have a BMP, you need a BMP. Right now, one of the main producers of these little gems is running a Kickstarter where you can get your hands on a nicely made one and/or a 1Bitsy STM32F415-based development board.
Why is the BMP so great? First off, it’s got a JTAG and a UART serial port in one device. You can flash the target, run your code, use the serial port for
printf debugging like you know you want to, and then fall back on full-fledged JTAG-plus-GDB when you need to, all in one dongle. It’s just very convenient.
But the BMP’s killer feature is that it runs a GDB server on the probe. It opens up a virtual serial port that you can connect to directly through GDB on your host computer. No need to hassle around with OpenOCD configurations, or to open up a second window to run [texane]’s marvelous st-util. Just run GDB,
target extended-remote /dev/ttyACM0 and you’re debugging. As the links above demonstrate, there are many hardware/software pairs that’ll get you up and debugging. But by combining the debug server with the JTAG hardware, the BMP is by far the slickest.
Full disclosure: we use a BMP that we built ourselves, which is to say that we compiled and flashed the firmware into a $4 STLink clone programmer that we had on hand. Breaking the required signals out required a bit of ugly, fiddly soldering, but we enjoy that sort of thing. If you don’t, the early-bird Kickstarter (with cables) looks like a good deal to us.
The usefulness of Raspberry Pis seems almost limitless, with new applications being introduced daily and with no end in sight. But, as versatile as they are, it’s no secret that Raspberry Pis are still lacking in pure processing power. So, some serious optimization is needed to squeeze as much power out of the Raspberry Pi as possible when you’re working on processor-intensive projects.
This simplest way to accomplish this optimization, of course, is to simply reduce what’s running down to the essentials. For example, there’s no sense in running a GUI if your project doesn’t even use a display. Another strategy, however, is to ensure that you’re actually using all of the available processing power that the Raspberry Pi offers. In [sagiz’s] case, that meant using Intel’s open source Threading Building Blocks to achieve better parallelism in his OpenCV project.
Continue reading “Running Intel TBB On a Raspberry Pi”