STM32 ⁽⁹⁾

In the first of these four blog posts on the firmware for the countdown timer, we'll look at the firmware layer design, the user interface functions and power consumption. The bargraph LEDs, buttons and switches are just GPIOs driven through my hardware independent driver layer, but there's more of interest in the seven segment display driver and speaker driver. Since there's no such peripheral as a seven segment display driver, at least not on this micro, I've had to write one. Driving the speaker with PWM proved slightly more difficult than you might expect, and there's some niceties around the sound that I wanted to include. We can't avoid main.c being generated by STM32CubeIDE and directly accessing the HAL, and it's the best place for the Wake pin callback, but we don't have to fall into the trap of putting our application logic in int main(void). Instead, we just call app_init() in the user code initialisation section, and app_run() in the while(1) loop, and let the app_main.c module handle the application layer. This structure allows it to be tested on the host without hardware problems getting in the way. board_config defines all the IO pins and peripheral register mappings so…

The idea for this project was a simple countdown timer to be used for various children's games and activities where the user interface was designed to be as simple as possible; the display was clear from across the room and provided a sense of urgency, with a clear notification when the time was up. I started from the need for a large bright display, which meant using the largest economically available 7-segment LED modules. Starting a timer should be as simple as pressing a single button with a fixed function, so there is no time adjustment (up/down) facility which can be fiddly and non-obvious to use. Those often require long presses to get into a fast increment mode and are not consistent in how they accelerate. Choosing the time periods at the start of the project meant that the front panel could be labelled. Seven periods covered the desired range of 10 seconds to 15 minutes and left one button to be used for cancel, making a nicely symmetrical 4 buttons arrangement down either side. A coloured bargraph display was designed to give a sense of what proportion of the original time has elapsed and how much remains, using 10%…

Given that the promise of STM32CubeIDE is that adding functionality should be as easy as clicking in checkboxes, you'd think it would be easy to set up Ethernet on one of STM's own Nucleo boards which is designed for it, and to get it responding to ping on your internal network at a fixed IP address within minutes. If so, you've been misled by the way that simpler interfaces such as UART, SPI, I2C, and GPIO are easily configured with STM32CubeIDE/CubeMX, especially if you don't need to have them working through DMA. Because of the high speed nature of Ethernet, it is essential to use DMA and to get the caching set up right, and until you do, it doesn't work at all. Unlike UART, SPI, I2C or CAN, you can't just start with the simpler case of transmit-only to see if your physical layer is working and the baud rate setting from the clock tree is right because Ethernet essentially requires receive and transmit to work before you'll see anything at the IP layer. If your lowest level test is ping, it's not going to work until your PC can get responses to it's ARP requests. Over the last…

Reusability is an idea often touted in software, and embedded projects are no exception. In fact, the reasons for needing re-usability or ease of porting are often more pertinent to embedded projects even though the initial use-case doesn't call for them, and speed to market is usually business-critical. Why would the processor (or microcontroller) change after it has been designed-in? After all, the hardware designer has to make lots of decisions which are tied to that specific processor in that specific package, so it would be a lot of work for them to change it. Timescales for embedded projects often require the code to be in progress whilst the hardware is being finalised, PCB laid out and prototypes produced. If we can't start the driver layers until the prototypes are available, then it becomes risky to work on the aspects of the application which depend on the lower layers, even with a well abstracted design. During the pandemic, we saw chip shortages affecting many industries because of large orders by the big players, and large order cancellations which messed up everybody's lead-times. STM32s in particular were impossible to obtain unless you were part of the automotive industry. We found that…

Code generation from ioc STM32CubeIDE is a powerful piece of software, including code generation from a GUI formerly known as CubeMX, a code editing environment and a full debugger. The code generation feature should not be dismissed as a beginner level gimmick because it can be used within a professional environment, saving a huge effort compared to doing that work yourself, when you know how to keep it under control. If you're not aware of how to keep the code generator under control, you could lose code, be unable to get your code where you need it in the files, and feel restricted by it's imposed code structure. The CubeMX part of STM32CubeIDE can be used as a standalone application or integrated into the IDE and uses the [project name].ioc file to store the configuration of the peripherals, drivers and middleware in a text file which can then be displayed in an interactive GUI. One ioc file is used for the project, even for multicore processors, which are configured using two columns of checkboxes. When working with the files generated by CubeMX, it is easy to be so overwhelmed by all the boilerplate lines that you just ignore them and…