Hackaday Podcast Episode 270: A Cluster Of Microcontrollers, A Rocket Engine From Scratch, And A Look Inside Voyager

Join Hackaday Editors Elliot Williams and Tom Nardi as they get excited over the pocket-sized possibilities of the recently announced 2024 Business Card Challenge, and once again discuss their picks for the most interesting stories and hacks from the last week. There’s cheap microcontrollers in highly parallel applications, a library that can easily unlock the world of Bluetooth input devices in your next project, some gorgeous custom flight simulator buttons that would class up any front panel, and an incredible behind the scenes look at how a New Space company designs a rocket engine from the ground up.

Stick around to hear about the latest 3D printed gadget that all the cool kids are fidgeting around with, a brain-computer interface development board for the Arduino, and a WWII-era lesson on how NOT to use hand tools. Finally, learn how veteran Hackaday writer Dan Maloney might have inadvertently kicked off a community effort to digitize rare documentation for NASA’s Voyager spacecraft.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download your very own copy of the podcast right about here.

Continue reading “Hackaday Podcast Episode 270: A Cluster Of Microcontrollers, A Rocket Engine From Scratch, And A Look Inside Voyager”

Modern Microcontroller Boosts Classic Logic Analyzer To New Heights

[Ted Fried] recently found a beautiful HP 1600A/1607A logic analyzer set. State of the art in 1975, it looks like glorious Space Age equipment today. He decided to hook it up some modern gear to put it through its paces.

Wanting to give the equipment a proper shakedown, he enlisted a Teensy 4.1 to spit a deluge of logic at the HP unit. The microcontroller was tasked with generating 32 data signals along with two clock outputs to give the analyzer plenty to analyze. The HP 1600A handled this no problem, so [Ted] kept tinkering.

His next feat was to explore the addressable “MAP” function of the unit, which allowed writing to the 64×64 pixel display. The Teensy 4.1 was easily able to send images to the display, but [Ted] isn’t stopping there. He’s got plans to do the usual thing and get Bad Apple going on the hardware.

Getting a logic analyzer to analyze logic isn’t much of a hack, sure. But it’s instructive of how to approach working with such hardware. If you want to spit a bunch of logic out fast, a Teensy 4.1 is a great choice because it’s got a ton of IO and a ton of clock cycles to tickle it with.

We enjoyed seeing this old piece of hardware light up the phosphors once more. If you’ve got your own projects going on with classic bits of HP test gear, don’t hesitate to let us know!

Breaking The Flash Encryption Feature Of Espressif’s Microcontrollers

Espressif’s ESP32 microcontrollers come with a Flash encryption feature that when enabled ensures that the data and code stored on the (usually external) Flash chip is encrypted with AES-256 (ESP32) or better (ESP32-C3, -C6). For the ESP32 this encryption feature has been shown to be vulnerable to side channel attacks (SCA), leading [courk] to not only replicate this result with a custom ESP Correlation Power Analysis (CPA) board (pictured) that captures power usage of the MCU, but also to try his luck with the ESP32-C3 and ESP32-C6 parts that should be tougher nuts to crack.

Whereas the ESP32 uses a fairly straightforward AES-256 encryption routine that together with the exposed Flash communication lines on the QSPI bus make for a textbook SCA example, the ESP32-C3 ups the encryption to XTS-AES, which uses two 128-bit keys on the -C3 part (XTS-256). This particular MCU is still susceptible to the same SCA attack with CPA, making it somewhat harder to attack than the ESP32, but by no means impossible.

Continue reading “Breaking The Flash Encryption Feature Of Espressif’s Microcontrollers”

Saving PIC Microcontrollers With DIY Programmer

When working on a project, plenty of us will reach for an Atmel microcontroller because of the widespread prevalence of the Arduino platform. A few hackers would opt for a bit more modern part like an ESP32. But these Arduino-compatible platforms are far from the only microcontrollers available. The flash-based PIC family of microcontrollers is another popular choice. Since they aren’t quite as beginner or user-friendly, setting up a programmer for them is not as straightforward. [Tahmid] needed to program some old PIC microcontrollers and found the Pi Pico to be an ideal programmer.

The reason for reaching for the Pico in the first place was that [Tahmid] had rediscovered these decade-old microcontrollers in a parts bin but couldn’t find the original programmer. Thanks to advances in technology in the last ten years, including the advent of micropython, the Pico turned out to be the ideal programmer. Micropython also enables a fairly simple drag-and-drop way of sending the .hex file to the PIC, so the only thing the software has to do is detect the PIC, erase it, and flash the .hex file. The only physical limitation is that the voltages needed for the PIC are much higher than the Pico can offer, but this problem is easily solved with a boost converter (controlled by the Pico) and a level shifter.

[Tahmid] notes that there’s plenty of room for speed and performance optimization, since this project optimized development time instead. He also notes that since the software side is relatively simple, it could be used for other microcontrollers as well. To this end, he made the code available on his GitHub page. Even if you’re more familiar with the Arduino platform, though, there’s more than one way to program a microcontroller like this project which uses the Scratch language to program an ESP32.

TMS 1000 Microcontroller - By Antonio Martí Campoy - Own work, CC BY-SA 4.0

The Early History Of The Microcontroller: It Came From Texas

Ti’s presentation of the rapid integration of calculator chips.
Ti’s presentation of the rapid integration of calculator chips.

Although for most generations alive today the era of microcontrollers (MCU) feels like it starts somewhere with the Intel 8051 and AVR MCUs, the history of these self-contained computing marvels that are now found just about anywhere begins long before those were even conceptualized. In a recent article titled Tiny Computers From Texas, [Babbage] goes through this early history of what would ultimately become such an integral part of daily life.

An MCU is defined as a small, self-contained computer, which requires few to no external components to function. This contrasted with the more traditional MPUs, or microprocessor units, where a computer was assembled out of one or more MPUs, I/O chips, memory SRAM and so on. It’s perhaps little surprise that the drive towards MCUs was the result of primarily the calculator market, where competing firms were trying to upstage each other with higher levels of integration into as few chips as possible, while driving down costs and power usage.

Ultimately, the Texas Instruments TMS 1000 was the first true MCU that got produced in large volumes after its release in 1974. Moving beyond calculators, the TMS 1000 found its way into toys, including the Speak & Spell – which uses another Ti chip (TMS 5100) for the voice synthesis – so that today any toy can be interactive in exciting and often noisy ways.

Back in 2020 we took our own affectionate look at this chip.

Tiny Linux On A No-MMU RISC-V Microcontroller

In the vast majority of cases, running a Linux-based operating system involves a pretty powerful processor with a lot of memory on hand, and perhaps most importantly, a memory management unit, or MMU. This is a piece of hardware which manages virtual memory, seamlessly giving each process its own memory sandbox in which it shouldn’t be able to rain on its neighbours’ parade. If there’s no MMU all is not lost though, and [Uros Popovic] gives us a complete guide to building the MMU-less μClinux on a RISC-V microcontroller.

The result is something of a Linux-from-scratch for this platform and kernel flavour, but it’s so much more than that aside from its step-by-step explanation. It’s probable that most of us have heard something of μClinux but have little direct knowledge of it, and he leads us through its workings as well as its limitations. As examples, standard ELF binaries aren’t suitable for these systems, and programmers need to use memory-safe techniques.

Whether or not any of you will run with this guide and build a tiny MMU-less Linux system, anything which expands our knowledge on the subject has to be a good thing. it’s not the first time we’ve seen a RISC-V microcontroller turned to this task, with a nifty trick to get round the limitations of a particular architecture.

MicroLisp: Lisp For Microcontrollers Now Has Lisp-Based ARM Assembler

In a way it feels somewhat silly to market a version of Lisp as targeting resource-constrained platforms, considering the systems it ran on back in the 1960s, but as time goes on, what would have given 1970s Big Iron a run for its money is now a sub-$5 microcontroller that you can run uLisp (MicroLisp) on. This particular project now even has an ARM assembler that is written in Lisp whose source code (GitHub) fits on a mere two A4-sized pages.

ULisp currently supports five platforms, being AVR-nano (ATmega328 and similar low-cost AVRs), AVR, ARM, ESP (8266 and 32), as well as RISC-V. The purpose of this assembler is to execute native ARM instructions when running on an ARM board, since uLisp itself runs a Lisp interpreter on the platform. When executed natively like this, a considerable speed-up of the task can be expected, as illustrated by a number of ARM assembler examples in the documentation.

Running a Fibonacci sequence that takes 24.6 seconds with the Lisp version on an Adafruit Metro M4 is reduced to a mere 61 ms when ARM assembly is used instead. This shouldn’t be too shocking, since this assembler essentially bypasses the Lisp runtime, coming closer to what would be the performance of firmware written in e.g. C. However, it also demonstrates that with this ARM assembler it is possible to have your Lisp and still get native performance when you want it, all using Lisp code.