There are plenty of small microcontrollers available for all kinds of tasks, each one with its unique set of features and capabilities. However, not all of us want to spend time mucking about in C or assembly to learn the intricacies of each different chip. If you prefer the higher planes of Python instead, it’s not impossible to import Python on even the smallest of microcontrollers thanks to MicroPython, which [Rob] shows us in this project based on the ESP32.
[Rob] has been working on a small robot called Marty which uses an ESP32 as its brain, so the small microcontroller is already tasked with WiFi/Bluetooth communications and driving the motors in the robot. Part of the problem of getting Python to run on a platform like this is that MicroPython is designed to be essentially the only thing running on the device at any one point, but since the ESP32 is more powerful than the minimum requirements for MicroPython he wanted to see if he could run more than just Python code. He eventually settled on a “bottum-up” approach to build a library for the platform, rather than implementing MicroPython directly as a firmware image for the ESP32.
The blog post is an interesting take on running Python code on a small platform, and goes into some details with the shortcomings of MicroPython itself which [Rob] ended up working around for this project. He’s also released the source code for his work on his GitHub page. Of course, for a different approach to running Python and C on the same small processor, there are some libraries that accomplish that as well.
The Mandelbrot set is a curious mathematical oddity that, while interesting in its own right, is also a useful tool for benchmarking various types of computers. Its constant computing requirement when zooming in and out on the function, combined with the fact that it can be zoomed indefinitely, means that it takes some quality hardware and software to display it properly. [Thanassis] has made this a pet project of his, running Mandelbrot set visualizations in different ways on many different hardware platforms.
This particular one is based on an STM32 board called the Blue Pill, which [Thanassis] chose because he hadn’t yet done a continuous Mandelbrot zoom on a microcontroller yet. The display is handled by a tiny 16K IPS color screen, and some clever memory tricks had to come into play in order to get smooth video output since the STM has only 20 kB available. The integer multiplication is also tricky on a platform this small while keeping the continuous zoom function, so it’s limited to fixed point multiplication.
Even with the limitations of the platform, he is still able to achieve nearly double-digit FPS rates with this one. If you want to play around with graphics like this on an STM platform, [Thanassis] has released all of the source code on his GitHub page, but if you’d like to see more Mandelbrot manipulation you can check out one of his older projects where he built a similar project on an FPGA.
One of the most difficult user interfaces to get right is video editing. It is complex and fiddly with large amounts of precision required even after four or five hours of straight editing. Seeking to bring some of that interface out into the real world, [Zack Freedman] built a mechanical video editing keyboard.
The keyboard in question features popular shortcuts and keys to breeze through different parts of editing. The biggest feature is, of course, the large scrubbing knob, allowing [Zack] to fly through long video with precision. We’ve seen our fair share of mechanical keyboards that aren’t traditional keyboards on Hackaday before, such as this number pad or this macro pad.
One of the unique constraints of this project was the fact that Zack had a deadline of two days. This self-imposed deadline was to help focus the work and drive it towards completion. This meant that it had to be designed in such a way that roadblocks or troublesome features could be designed around or cut out altogether. At its heart, this project is just 14 mechanical switches, 4 potentiometers, and a Teensy to drive it all. It is the design, prototyping, and thought that went into this project that makes it noteworthy. There are plenty of lessons here about how to manage a project’s timeline and advice about how to actually finish it.
It’s a safe bet that most Hackaday reader’s interest in electronics started at a young age, and that their early forays into the world of hardware hacking likely involved some form of “playground” kit. As long as you didn’t lose any of the components, these kits promised the user that hundreds of possible projects were just a few jumper wires away. Extra points awarded for when you decide to toss away the manual and fly solo.
It’s still got the traditional layout: a center mounted breadboard surrounded by an array of LEDs, a handful of buttons, and a pair of potentiometers. But there’s also sockets for the Raspberry Pi, ESP8266, ESP32, and Arduino. Plus a few of their most popular friends to keep them company: a .96″ OLED, 2.4″ Touch TFT, and a BC05 Bluetooth module.
There are many ways to update an embedded system in the field. Images can fly through the air one a time, travel by sneaker or hitch a ride on other passing data. OK, maybe that’s a stretch, but there are certainly a plethora of ways to get those sweet update bytes into a target system. How are those bytes assembled, and what are the tools that do the assembly? This is the problem I needed to solve.
Recall, my system wasn’t a particularly novel one (see the block diagram below). Just a few computers asking each other for an update over some serial busses. I had chosen to bundle the payload firmware images into the binary for the intermediate microcontroller which was to carry out the update process. The additional constraint was that the blending of the three firmware images (one carrier and two payload) needed to happen long after compile time, on a different system with a separate toolchain. There were ultimately two options that fit the bill.
When working with hardware, whether a repair or a fresh build, it’s often necessary to test something. Depending on what you’re working with, this can be easy or a total pain if you can’t get the right signal to the right place. To eliminate this frustrating problem, [WilkoL] built a useful pulse generator for use in the lab.
[WilkoL] notes that historically, the job of generating pulses of varying length and frequency would be achieved with a smattering of 555 timers. While this is a perfectly cromulent way to do so, it was desired to take a different approach for the added flexibility modern hardware can offer. The pulse generator is instead built around an STM8 microcontroller; an unusual choice in this era, to be sure. [WilkoL] specified the part for its incredibly low cost, and highly capable timer hardware – perfect for the job.
Combined with an ST7735 TFT LCD screen, and programmed in bare metal for efficiency’s sake, the final project is installed in a project box with controls for frequency and pulse length – no more, no less. Capable of pulse lengths from 250 ns to 90 s, and frequencies from 10 mHz to 2 MHz, it’s a tool that should be comfortable testing everything from servos to mechanical counters.
When it comes to measuring time on microcontrollers, there’s plenty of ways to go about things. For most quick and dirty purposes, such as debounce delays or other wait states, merely counting away a few cycles of the main clock will serve the purpose. Accurate to the tens of milliseconds, they get the average utility jobs done without too much fuss.
However, many projects are far more exacting in their requirements. When you’re building a clock, or a datalogger, or anything that relies on a stable sense of passing time for more than a few minutes, you’ll want a Real Time Clock. So called due to their nature of dealing with real time, as we humans tend to conceive it, these devices take it upon themselves to provide timekeeping services with a high degree of accuracy. We’ve compiled a guide to common parts and their potential applications so you can get things right the first time, every time.