Blinkenlights To Bootloader: A Guide To STM32 Development

August 6, 2023 by Bryan Cockfield 15 Comments

While things like the Arduino platform certainly opened up the gates of microcontroller programming to a much wider audience, it can also be limiting in some ways. The Arduino IDE, for example, abstracts away plenty of the underlying machinations of the hardware, and the vast amount of libraries can contribute to this effect as well. It’s not a problem if you just need a project to get up and running, in fact, that’s one of its greatest strengths. But for understanding the underlying hardware we’d recommend taking a look at something like this video series on the STM32 platform.

The series comes to us from [Francis Stokes] of Low Byte Productions who has produced eighteen videos for working with the STM32 Cortex-M4 microcontroller. The videos start by getting a developer environment up and blinking LEDs, and then move on to using peripherals for more complex tasks. The project then moves on to more advanced topics and divides into two parts, the development of an application and also a bootloader. The bootloader begins relatively simply, and then goes on to get more and more features built into it. It eventually can validate and update firmware, and includes cryptographic signing (although [Francis] notes that you probably shouldn’t use this feature for production).

One of the primary goals for [Francis], apart from the actual coding and development, was to liven up a subject matter that is often seen as dry, which we think was accomplished quite well. A number of future videos are planned as well. But, if you’re not convinced that the STM32 platform is the correct choice for you, we did publish a feature a while back outlining a few other choices that might provide some other options to consider.

Continue reading “Blinkenlights To Bootloader: A Guide To STM32 Development” →

The ESP32 Doesn’t Need Much

July 28, 2023 by Bryan Cockfield 19 Comments

For those looking to add wireless connectivity to embedded projects or to build IoT devices, there is perhaps no more popular module than the ESP32. A dual-core option exists for processor intensive applications, the built-in WiFi and Bluetooth simplify designs, and it has plenty of I/O, memory, and interoperability for most applications. With so much built into the chip itself, [atomic14] wondered how much support circuitry it really needed and set about building the most minimalist ESP32 development board possible.

Starting with the recommended schematic for the ESP32, the most obvious things to remove are a number of the interfacing components like the USB to UART chip and the JTAG interface. The ESP32 has USB capabilities built in, so the data lines from a USB port can be directly soldered to the chip instead of using a go-between. A 3.3V regulator eliminates the need for many of the decoupling capacitors, and the external oscillator support circuitry can also be eliminated when using the internal oscillator. The only thing [atomic14] adds that isn’t strictly necessary is an LED connected to one of the GPIO pins, but he figures the bare minimum required to show the dev board can receive and run programs is blinking an LED.

Building the circuit on a breadboard shows that this minimalist design works, but instead of building a tiny PCB to solder the ESP32 module to he attempted to build a sort of dead-bug support circuit on the back of the ESP32. This didn’t work particularly well so a tiny dev board was eventually created to host this small number of components. But with that, the ESP32 is up and running. These modules are small and compact enough that it’s actually possible to build an entire dev board setup inside a USB module for a Framework laptop, too.

Continue reading “The ESP32 Doesn’t Need Much” →

ESP32 Freezer Alarm Keeps Tabs On Tricky Door

July 27, 2023 by Lewin Day 31 Comments

Leaving your freezer door open accidentally is a great way to make a huge mess in the kitchen. [Guy Dupont] had a freezer that would regularly fail to close properly, and was sick of the regular meltdown events. Thus, he whipped up a very digital solution.

The build combines an ESP32 with a reed switch, which is activated by a magnet on the freezer door. If the freezer door is open, the reed switch similarly remains open. The ESP32 checks the switch status every few minutes, and if the door remains open for two consecutive checks, it raises the alarm. A notification is sent to [Guy] via WiFi so that he can rectify the situation. The rig runs off a 400 mAh battery, which lasts for just over three weeks running door checks at two minute intervals.

Based on [Guy]’s YouTube video, it appears the freezer door is jamming up against the wall. Perhaps shoving the freezer into a better position would help, though we suspect he would have thought of that first. And, in his own words, “That would be a very boring YouTube video, wouldn’t it?”

It’s not the first fridge alarm we’ve featured, and it won’t be the last, refrigeration gods willing.

Continue reading “ESP32 Freezer Alarm Keeps Tabs On Tricky Door” →

Old Style 1802 Computer Has MMU

July 21, 2023 by Al Williams 8 Comments

When you think of an MMU — a memory management unit — you probably think of a modern 32-bit computer. But [Jeff Truck] has a surprise. His new RCA 1802 computer has bank switching, allowing the plucky little processor to address 256K of RAM. This isn’t just the usual bank-switching design, either.

The machine has several unique features. For example, an Arduino onboard can control the CPU so that you can remotely control the bus. It does not, apparently, stand in for any of the microprocessor support chips. It also doesn’t add additional memory or control its access.

The 256K of memory is under the control of the MMU board. This board generates two extra address bits by snooping the executing instruction and figures out what register is involved in any memory access. Memory in the MMU stores a table that lets you set different memory pages for each register. This works even if the register is not explicit and also for the machine’s DMA and instruction fetch cycles. If you know about the RCA “standard call and return technique,” which also needed a little patching for the MMU. [Jeff] covers that at the end of the video below.

This is a very simple version of a modern MMU and is an impressive trick for a 50-something-year-old CPU. We were surprised to hear — no offense to [Jeff] — that the design worked the first time. Impressive! There’s also some 3D printing and other tips to pick up along the way. But we were super impressed with the MMU. You might never have to do this yourself (although you could), but you can still marvel that it can be done at all.

We have a soft spot for the 1802s, real or emulated. The original ELF was great, but 256K is a lot better than the original 256 bytes!

Continue reading “Old Style 1802 Computer Has MMU” →

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

July 10, 2023 by Maya Posch 12 Comments

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.

Clock Runs Computer In Slow-Motion

July 8, 2023 by Bryan Cockfield 27 Comments

At the heart of all computers is a clock, a dedicated timepiece ensuring that all of the parts of the computer are synchronized and can work together to execute the instructions that the computer receives. Clock speeds for most modern off-the-shelf computers and smartphones operate around a billion cycles per second, and even clocks that tick at a human-dizzying speed of a million times per second have been around since at least the 1970s. But there’s no reason a computer can’t run at a much slower speed, as [Greg] demonstrates in this video where he slows down a 6502 processor to a single clock cycle per second.

To reduce the clock speed from the megahertz range down to a single hertz or single clock cycle per second, [Greg] is using the pendulum from an actual clock. He attaches a small magnet to the bottom of the pendulum which is counted by a sensor as it swings past. Feeding that pulse into a monostable conditioner yields a clock signal which is usable for one of his 6502-based computers, and at this extremely slow rate, it’s possible to see the operation of a lot of the computers’ inner workings a step at a time. In fact, he optimized the computer’s operation as this slow speed let him see some inefficiencies in the program he was running.

It helps if your processor is static, of course. Older CPUs with dynamic storage for registers and some with limited-range PLLs would not work with this technique. The 8080A, for example, required a clock of at least 500 kHz.

Not only can this computer use a pendulum clock as the basis for its internal clock, but [Greg] also rigged up a mechanism to use a heartbeat. Getting in a little bit of exercise to increase his heart rate first will noticeably increase the computer’s speed. And, if you’re looking to get a deeper glimpse into the inner workings of a computer, we’d recommend looking at one which forgoes transistors in favor of relays.

Continue reading “Clock Runs Computer In Slow-Motion” →

Four jumper wires with white heatshrink on them, labelled VCC, SCL, SDA and GND

Three Pitfalls In I2C Everyone Wishes Weren’t There

July 3, 2023 by Maya Posch 95 Comments

The best part of I2C is that it is a bus that is available just about anywhere, covering a vast ecosystem of devices that offer it as a hardware-defined interface, while being uncomplicated enough that it can also be implemented purely in software on plain GPIO pins. Despite this popularity, I2C is one of those famous informal standards that feature a couple of popular implementations, while leaving many of the details such as exact timing, bus capacitance and other tedious details to the poor sod doing the product development. Thus it is that we end up with articles such as a recent one on the tongue-twisting [pair of pared pears] blog, covering issues found while implementing an I2C slave.

As with any shared bus, whether multi-master or not, figuring out when the bus is clear is a fun topic, yet one which can cause endless headaches. One issue here comes from a feature that the SMBus version of I2C calls quick read/write. This allows for the rapid transfer of some data. Still, depending on the data returned by the slave, it may appear to the master that nothing is happening yet, since SDA is being held low by the slave until the stop condition, essentially locking the bus.

Where things get even more exciting comes generally in the form of what logic analyzers love to traumatically call a ‘spurious start/stop condition’. This refers to the behavior of SDA and SCL, with SDA going low before SCL indicating an error. This can occur due to a hold time that’s too low, causing other devices on the bus to miss the transition. Here SMBus defines a transition time of 300 ns, while I2C calls for 0 seconds, but it’s now suggested to delay calling a start/stop condition until a delay of 300 ns has passed. Essentially, it would seem that implementing a hold time is the way forward until evidence to the contrary appears.

The third pitfall pertains to the higher-speed modes of I2C, including Fast-Mode (FM) and Fast-Mode Plus (FM+). Backward compatibility with these higher speed versions is absent to spotty. Although FM+ (introduced by NXP in 2007) is supposed to be backward compatible with slower speeds, effectively the timing requirement differences between the FM+ and FM standards are too large to compensate for. At least in the current versions of the standards, but one of the joys of I2C is that there’s always another new set of revisions to look forward to.