Nucleo-F429ZI development board with STM32F429 microcontroller

Epic Guide To Bare-Metal STM32 Programming

[Sergey Lyubka] put together this epic guide for bare-metal microcontroller programming.  While the general concepts should be applicable to most any microcontroller, [Sergey]s examples specifically relate to the Nucleo-F429ZI development board featuring the ARM-based STM32F429 microcontroller.

In the realm of computer systems, bare-metal programming most often refers to programming the processor without an intervening operating system. This generally applies to programming BIOS, hardware drivers, communication drivers, elements of the operating system, and so forth. Even in the world of embedded programming, were things are generally quite low-level (close to the metal), we’ve grown accustomed to a good amount of hardware abstraction. For example, we often start projects already standing on the shoulders of various libraries, boot loaders, and integrated development tools.

When we forego these abstractions and program directly on the microprocessor or microcontroller, we’re working on the bare metal. [Sergey] aptly defines this as programming the microcontroller “using just a compiler and a datasheet, nothing else.” His guide starts at the very foundation by examining the processor’s memory map and registers including locations for memory mapped I/O pins and other peripherals.

The guide walks us through writing up a minimal firmware program from boot vector to blinking an LED connected to an I/O pin. The demonstration continues with setup and use of necessary tools such as the compiler, linker, and flasher. We move on to increasingly advanced topics like timers, interrupts, UART output, debuggers, and even configuring an embedded web server to expose a complete device dashboard.

While initially more time consuming, working close to the metal provides a good deal of additional insight into, and control over, hardware operations.  For even more on the subject, you may like our STM32 Bootcamp series on bare-metal STM32 programming.

Kved: An Embeddable Key/Value Datastore

At some point when developing embedded applications, you’re going to want to store unique values in non-volatile memory, values that can’t be fixed at compilation time. Many microcontrollers have a small amount of EEPROM memory for this very purpose, but it’s usually rather limited if it’s provided at all. Even if you do have a bit of space on an EEPROM at your disposal, actually formatting your values into the memory and dealing with the pesky problem of wear leveling (necessary for parameters that need to change often) can be a bit of a hassle.

Lucky for us, [Marcelo Barros] decided to share his own implementation, Kved (key/value database) which uses the flash memory instead for such storage. Kved implements a dictionary type data structure, using numeric keys and values, supporting a few integer types. Using the library should be straightforward enough, as [Marcelo] says, all you need are a pair of spare flash sectors and the ability to port the flash the sector read, write, and erase functions. There are plenty of examples of such code available for practically any microcontroller out there, so that should be no barrier. For those who want to play with it right now, the repo currently has ports for the STM32L433RC and STM32F411CE, as well as a simulated version you can compile and run on your computer.

From an implementation perspective, the write algorithm uses a COW (Copy On Write) method. Changed values are invalidated by over-writing the storage location with all-zeros, and re-writing the changed value to a new location, cycling through the unused locations until the sector is full. Data-integrity mechanisms are implemented, preventing corruption of the data structure due to power fail situations, so incorrectly written values will be corrected on start-up and not affect the integrity of the configuration.

When looking around, we found a similar project, Embedis, over on hackaday.IO, as well as this article on the subject of embedded filesystems from a little while back.

Remoticon Video: Pigweed Brings Embedded Unit Testing, Library Integration To Commandline

When it comes to embedded engineering, toolchains are the worst. Getting a new toolchain up and running correctly is often hard, and often prone to breaking when the IDE or other software is upgraded. A plethora of different toolchains for different hardware makes things even more murky, and if you want to get into time-saving tricks like automated testing, you’re in for a wild ride.

Those pain points led to the creation of the Pigweed project. As Keir Mierle demonstrates in this workshop from the 2020 Hackaday Remoticon, Pigweed is a set of libraries to make working with embedded development more hacker-friendly. The collection is accessed via commandline, and coordinates work with existing libraries to deliver unit testing, linting, static analysis, logging, and handling key-value stores, all alongside more commonly called-for tasks like compiling and flashing.

Demonstrated on a Teensy microcontroller and an STM32 Discovery board, the presentation drives home the utility of Pigweed, a Google project that was released as open source back in March of 2020. Graphical IDEs for these platforms are nowhere in sight, yet test firmware is built and flashed to these devices with relative ease. Unit testing, traditionally a sticky subject for on-chip applications, is demonstrated both emulated on the computer side, and running on the boards themselves. As the capabilities of microcontrollers have ballooned in recent years, writing tests for existing functions and confirming them during new development is becoming a must-have in your skillset.

There’s much more shown off here, so grab the workshop repository to follow along. It’s still considered experimental, and the irony of having to learn the intricacies of the Pigweed toolchain to ease the pain of other toolchains is not lost on us. However, most people reading will have their own affinity for the ability to use unified tools and commandline automation; this is a fascinating way to deliver a number of powerful software development techniques to low-level hardware projects.

Continue reading “Remoticon Video: Pigweed Brings Embedded Unit Testing, Library Integration To Commandline”

Why Ada Is The Language You Want To Be Programming Your Systems With

The Ada programming language was born in the mid-1970s, when the US Department of Defense (DoD) and the UK’s Ministry Of Defence sought to replace the hundreds of specialized programming languages used for the embedded computer systems that increasingly made up essential parts of military projects.  Instead, Ada was designed to be be a single language, capable of running on all of those embedded systems, that offered the same or better level of performance and reliability.

With the 1995 revision, the language also targeted general purpose systems  and added support for object-oriented programming (OOP) while not losing sight of the core values of reliability, maintainability and efficiency. Today, software written in Ada forms the backbone of not only military hardware, but also commercial projects like avionics and air-traffic control systems. Ada code controls rockets like the Ariane 4 and 5, many satellites, and countless other systems where small glitches can have major consequences.

Ada might also be the right choice for your next embedded project. Continue reading “Why Ada Is The Language You Want To Be Programming Your Systems With”

Raspberry Pi Zero, Or Minus One?

The Wall Street Journal reported that [Eric Schmidt] of Google and now Alphabet Inc, promoted the idea of an inexpensive version of the Raspberry Pi to the Raspberry Pi foundation’s [Eben Upton]. Apparently [Upton] accepted this recommendation despite existing plans to make a more expensive, more powerful version of the Pi. The outcome is the Raspberry Pi Zero that sells, in some places, for $5.00 and was given away for free on the cover of the MagPi magazine.

From the WSJ article:

“He [Schmidt] said it was very hard to compete with cheap. He made a very compelling case. It was a life-changing conversation,” Mr. Upton said, adding that he went back to the lab and scrapped all the engineering plans for more expensive versions of future Pi computers. “The idea was to make a more powerful thing at the same price, and then make a cheaper thing with the same power.”

Plans were scrapped. The more powerful Pi 2 was released at the price point of existing Pis, and now we have the Zero.

Pi’s Purpose

Foundation Mission

The Raspberry Pi Foundation is a registered educational charity in the UK. The purpose of this Foundation according to their About Us page is to, ‘advance the education of adults and children, particularly in the field of computers, computer science, and related subjects.’

Why is the Raspberry Pi Foundation so concerned about computer education? From the 1990s onward, fewer and fewer A Level students in the UK applying to study Computer Science had previous experience as hobbyist programmers. An applicant in the 2000s usually might have only done a little web design.

Why then does the Raspberry Pi Zero exist? [Upton] also told Cnet, “We really hope this is going to get those last few people in the door and involved in computer programming.”

Very good, but how well does the Zero support this goal or address their concerns?

Continue reading “Raspberry Pi Zero, Or Minus One?”

Code Craft – Embedding C++: Timing Virtual Functions

Embedded C developers shy away from C++ out of concern for performance. The class construct is one of their main concerns. My previous article Code Craft – Embedding C++: Classes explored whether classes cause code bloat. There was little or no bloat and what is there assures that initialization occurs.

Using classes, and C++ overall, is advantageous because it produces cleaner looking code, in part, by organizing data and the operations on the data into one programming structure. This simple use of classes isn’t the raison d’etre for them but to provide inheritance, or more specifically polymorphism, (from Greek polys, “many, much” and morphē, “form, shape”).

Skeptics feel inheritance simply must introduce nasty increases in timing. Here I once more bravely assert that no such increases occur, and will offer side-by-side comparison as proof.

Continue reading “Code Craft – Embedding C++: Timing Virtual Functions”