Commented Out

Formatting is not something developers should be spending much time on, but we spend a lot of time staring at code to see if it's right so the formatting needs to be pleasing to the eye.

The reasons for having unit tests in your projects are well-known and accepted; I'm not going to rehash them here.

Most embedded C developers start writing their code on their microcontroller manufacturer's provided IDE - STM32CubeIDE, MPLAB X, TI Code Composer, NXP MCUXpresso, Segger Embedded Studio, Keil uVision, etc.

The ability to trace requirements through to implementation is an important property of commercial software development.

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 idea for this project was a simple countdown timer to be used by children for various 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, w…

When trying to write code samples in front of someone else, for example during an interview, it's a good idea to start by writing down the steps required before converting those to code.

Picking up someone else's design to get it into production is a common enough situation and yet there are always interesting problems to be solved.

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

Reusability is an idea often touted in software, and embedded projects are no exception.