The MCU-Link debug probes are versatile and very useful debug probes from NXP. This article describes how to update the firmware on it, both the ‘traditional’ way with using the ISP jumper, and the new way using a command line script without the need to use a jumper.
The Rust programming language is making its way into the embedded world, and getting more and more popular and not only at the Lucerne University. With Rust, the probe-rs is one of the popular debug choices, as it nicely comes with cargo. On the hardware side, the NXP MCU-Link is $15 debug probe hardware I use for many targets. Why not using the MCU-Link with probe-rs and Rust?
Float and double data types area a bad choice for embedded applications. At least in most applications, and can or should be avoided, even with hardware FPU support present.
But how can I be sure that no floating point operations are used?
wrapping float and double runtime routines
This article describes how to configure the GNU toolchain, so that no float or double operations are used, with the example of ARM Cortex-M. What I do? ‘Poisoning’ (!!!) the source code, force the gcc compiler to use software floating point operations and then catch them with the GNU linker :-).
Many cost-sensitive ARM Cortex-M devices like the M0+ do not have a hardware floating point unit, and some like the M4 only has an optional single-precision floating point unit (FPU). As outlined in “Be aware: Floating Point Operations on ARM Cortex-M4F“, using floating point operations without a hardware unit can be costly.
Looking at the disassembly for sure will tell you if the hardware is handling the float or double operation or not:
Disassembly showing runtime routines
But who wants check the all the disassembly? With the GNU tools there is an easier way: readelf.
Maybe you are using a multi-core device in your projects, but have not tapped into multi-core usage yet? FreeRTOS V11.0 is out, and the big news is that it has finally Symmetric Multi-Processing (SMP) integrated into the mainline. This greatly simplifies FreeRTOS usage, as I finally can use the same RTOS for my SMP targets and boards, and I can easily switch between single-core and multi-core applications.
Clock projects are cool. LED projects are cool too. And if it moves, the better. So why not building a moving pixel LED mechatronics clock? A matrix with addressable RGB LEDs, each can change color and is moved by a tiny stepper motor, to let pixels stand out?
One key element of a CI/CD pipeline is the automatic testing phase: whenever I check in new source code or manually trigger it, I can run a test suite to make sure that the changes do not break anything. For this, I have to run automated tests. For an an embedded target, it means that I have to run some tests on the board itself too.
I’m getting my head more and more around CMake and its features. After having so many issues with VS Code dealing with CMake Kits, I have found feature in CMake which really is a game changer for me: CMake Presets.
The MCU-Link is a small and inexpensive $10 CMSIS-DAP debug probe from NXP. It can work with OpenOCD, but has better target support using the NXP LinkServer which implements a gdb server. This makes it an ideal combination for scripting or automated testing.