STM32 ⁽⁶⁾

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…

A function to reverse the order of bits in a byte makes for a good interview question. The candidate has to think about loops, shifting and masking as well as the mundane but important issues of function and variable naming, data types, spacing and comments. As opposed to those "gotcha" questions apparently beloved by the tech giants where you have to know some trick, this can be worked through methodically. Once there is a solution on the table, there is an opportunity to talk about optimization for speed and/or space. There are lots of ways to approach this problem, but I suspect that many will take this simple idea of testing each bit and setting the LSB of the output in a loop which shifts up the output and mask one place each time. //bit reverse eg 0x80 return x01 //simple but straightforward approach uint8_t bitreverse_simple(uint8_t input) { uint8_t i, output, mask; output = 0; mask = 0x01; for (i = 8;i > 0;i--) { output <<= 1; if (input & mask) { output |= 1; } mask <<= 1; } return output; }; Testing The Simple Approach First we need to test that this produces correct results by running…

Generally, the advice on unit testing in embedded environments is to run your tests on the PC host rather than on the target device. Whilst I agree that this is the most productive arrangement, there are a variety of reasons for needing to test on the target which can be convincing in certain situation. The technique described here allows for both. Mike Long in his GOTO 2015 presentation Continuous Delivery for Embedded Systems says "Test on your host because that's fast - it's a really fast way to develop. But also test on the target because behaviour can change in different ways, different compilers, different hardware..." Niall Cooling in his talk at the EmbeddedOnlineConference 2020 "How agile is changing the face of embedded software development" says (at 46m) on the gap between testing on the host and the target Things like TDD really are based on testing in the host, and really that's fine but of course we are typically using host compilers like host GCC and of course we know that at the moment this is typically going to be an Intel based processor. So we are compiling for the underlying OS. And it is good for finding a…

While learning about RTOSes, I came across the idea of Timer Coalescing which improves performance by eliminating unnecessary context switches. But there is no reason that this technique cannot be applied to bare metal firmware (without RTOS). To test out how well it works, I implemented it using a STM32F4 discovery board. I wanted to see the improvement factor in a typical use case, so I decided on running 8 software timers on a 1ms timer peripheral. The software timers count down to 0 then reload themselves. From previous experience, typical periods were chosen for these timers of 1000, 200, 125, 50, 18, 27, 40 and 600ms. (If they had a common factor of say 5ms, then it would make more sense to use that as the peripheral timer rate, but it restricts the flexibility for future changes.) TIM6 was chosen because we only need a Basic 16 bit timer in the STM32F4 architecture. It runs off APB1 at 42 MHz (HCLK at 168 MHz). Prescaler was set to 41, Counter Period ARR set to 1999 for 1ms and auto-reload preload set to Disable. TIM6 interrupts were enabled. Once all this is set up in the Device Configuration Tool, all…