Blue Pill Vs Black Pill: Transitioning From STM32F103 To STM32F411

For many years now, the so-called ‘Blue Pill’ STM32 MCU development board has been a staple in the hobbyist community. Finding its origins as an apparent Maple Mini clone, the diminutive board is easily to use in breadboard projects thanks to its dual rows of 0.1″ pin sockets. Best of all, it only costs a few bucks, even if you can only really buy it via sellers on AliExpress and EBay.

Starting last year, boards with a black soldermask and an STM32F4 Access (entry-level) series MCUs including the F401 and F411 began to appear. These boards with the nickname ‘Black Pill’ or ‘Black Pill 2’. F103 boards also existed with black soldermask for a while, so it’s confusing. The F4xx Black Pills are available via the same sources as the F103-based Blue Pill ones, for a similar price, but feature an MCU that’s considerably newer and more powerful. This raises the question of whether it makes sense at this point to switch to these new boards.

Our answer is yes, but it’s not entirely clearcut. The newer hardware is better for most purposes, really lacking only the F103’s dual ADCs. But hardware isn’t the only consideration; depending on one’s preferred framework, support may be lacking or incomplete. So let’s take a look at what it takes to switch. Continue reading “Blue Pill Vs Black Pill: Transitioning From STM32F103 To STM32F411”

The (Probably) Most Thoroughly Commented Linker Script For The SAM D21 MCU

Linker scripts are one of those things which nobody who does software development really wants to deal with, but like many things in life sometimes they are inevitable to make things work. Although one could keep pretending linker scripts do not exist and let IDEs handle such pesky details, some of us suffer from this unfortunate condition called ‘curiosity’ and just have to know. People like [Thea].

Recently, [Thea] wrote a blog post on exactly what the linker script generated by the Microchip IDE for a Cortex-M-based SAM D21 project does. The result is a nicely annotated overview of the file’s contents, accompanied by links to the Arm and GCC documentation as well as other references where appropriate. The entire linker script (.ld file) can be viewed on GitHub. With the SAM D21 being a popular choice for Arduino and Arduino-compatible board, this article is a good starting point to understanding what a linker script does and how it affects one’s project.

For other (Cortex-M) MCUs this linker script is also useful as a starting point. Especially knowing which sections are required and what changing them affects in the final (ELF) binary and the firmware that is ultimately written to the MCU. We recently covered linker scripts for Cortex-M as well, along with the concept of memory-mapped I/O.

Dynamic Map Of Italy On A PCB

While most PCBs stick to tried-and-true methods of passing electrons through their layers of carefully-etched copper, modern construction methods allow for a large degree of customization of most aspects of these boards. From solder mask to number of layers, and even the shape of the board itself, everything is open for artistic license and experimentation now. [Luca] shows off some of these features with his PCB which acts as a live map of Italy.

The PCB is cut out in the shape of the famous boot, with an LED strategically placed in each of 20 regions in the country. This turns the PCB into a map with the RGB LEDs having the ability to be programmed to show any data that one might want. It’s powered by a Wemos D1 Mini (based on an ESP8266) which makes programming it straightforward. [Luca] has some sample programs which fetch live data from various sources, with it currently gathering daily COVID infection rates reported for each of the 20 regions.

The ability to turn a seemingly boring way to easily attach electronic parts together into a work of art without needing too much specialized equipment is a fantastic development in PCBs. We’ve seen them turned into full-color art installations with all the mask colors available, too, so the possibilities for interesting-looking (as well as interesting-behaving) circuits are really opening up.

Continue reading “Dynamic Map Of Italy On A PCB”

ESP32 Soil Monitors Tap Into Ultra-Low Power Mode

Soil moisture sensors are cheap and easy to interface with, to the point that combining one with an Arduino and blinking an LED when your potted plant is feeling a bit parched is a common beginners project. But what about on the long term? Outside of a simple proof of concept, what would it take to actually read the data from these sensors over the course of weeks or months?

That’s precisely the question [derflob] recently had to answer. The goal was to build a device that could poll multiple soil sensors and push the data wirelessly into Home Assistant. But since it would be outside on the balcony, it needed to run exclusively on battery power. Luckily his chosen platform, the ESP32, has some phenomenal power saving features. You just need to know how to use them. Continue reading “ESP32 Soil Monitors Tap Into Ultra-Low Power Mode”

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”

The Shell And The Microcontroller

One of the nicest amenities of interpreted programming languages is that you can test out the code that you’re developing in a shell, one line at a time, and see the results instantly. No matter how quickly your write-compile-flash cycle has gotten on the microcontroller of your choice, it’s still less fun than writing blink_led() and having it do so right then and there. Why don’t we have that experience yet?

If you’ve used any modern scripting language on your big computer, it comes with a shell, a read-eval-print loop (REPL) in which you can interactively try out your code just about as fast as you can type it. It’s great for interactive or exploratory programming, and it’s great for newbies who can test and learn things step by step. A good REPL lets you test out your ideas line by line, essentially running a little test of your code every time you hit enter.

This is your development environment

The obvious tradeoff for ease of development is speed. Compiled languages are almost always faster, and this is especially relevant in the constrained world of microcontrollers. Or maybe it used to be. I learned to program in an interpreted language — BASIC — on computers that were not much more powerful than a $5 microcontroller these days, and there’s a BASIC for most every micro out there. I write in Forth, which is faster and less resource intensive than BASIC, and has a very comprehensive REPL, but is admittedly an acquired taste. MicroPython has been ported over to a number of micros, and is probably a lot more familiar.

But still, developing MicroPython for your microcontroller isn’t developing on your microcontroller, and if you follow any of the guides out there, you’ll end up editing a file on your computer, uploading it to the microcontroller, and running it from within the REPL. This creates a flow that’s just about as awkward as the write-compile-flash cycle of C.

What’s missing? A good editor (or IDE?) running on the microcontroller that would let you do both your exploratory coding and record its history into a more permanent form. Imagine, for instance, a web-based MicroPython IDE served off of an ESP32, which provided both a shell for experiments and a way to copy the line you just typed into the shell into the file you’re working on. We’re very close to this being a viable idea, and it would reduce the introductory hurdles for newbies to almost nothing, while letting experienced programmers play.

Or has someone done this already? Why isn’t an interpreted introduction to microcontrollers the standard?

Bare-Metal STM32: Universal, Asynchronous Communication With UARTs

One of the most basic and also most versatile communication interfaces on an MCU is the UART, or Universal Asynchronous Receiver/Transmitter. Usually found in the form of either a UART or USART, the former allows for pure asynchronous serial communication, whereas the latter adds flow control. When working with MCUs, they’re also one of the most common ways to output debug information.

While somewhat trickier to set up and use than a GPIO peripheral, the U(S)ART of ST’s STM32 families is fairly uncomplicated to use, and immediately provides one with an easy way to communicate in a bi-directional fashion with a device. In this article we’ll see what it takes to get started with basic UART communication on STM32 microcontrollers.

Continue reading “Bare-Metal STM32: Universal, Asynchronous Communication With UARTs”