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.
The ‘Verkehrshaus der Schweiz‘, the ‘Swiss Museum of Transport’ is Switzerland’s most popular museum.
In April 2023, it opened up a new building and the ‘Experience Energy!’ exhibition. For the opening event we created a unique construction kit to explore energy: from harvesting to storing and up to distributing and using energy.
“House of Energy” at the Swiss Museum of Transport in LucerneContinue reading →
For a research project and demonstrator at HSLU university I have to measure voltage a DC voltage and current. For this I’m planning to use the Texas Instrument Texas Instruments INA260, so I had to quickly develop a software driver for it.
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.
An important part of every CI/CD pipeline is having a testing phase. In this article I show how to use GNU gcov (coverage) with an embedded target, using Visual Studio Code as front end:
GNU gcov with VS Code
With this, I can run the code on the embedded target which stores the coverage data on the host.
One important thing in using VS Code and CMake projects is that one needs to have a CMake kit assigned to the project. But after a restart of VS Code or if I re-load a project, VS Code has lost the previously assigned CMake kit:
VS Code has forgotten about the previously assigned CMake Kit?
This is very annoying, but luckily I have found a fix for this.
I’m working recently on a new lecture module using the Raspberry Pi Pico (RP2040) board, which highlights several aspects of modern software engineering, including DevOps and CI/CD. An important part of any CI/CD pipeline is testing. For a host application, one could pass arguments to the application, e.g. ‘myapp --test=module1‘, or let it read such information from a configuration file which describes the tests. Or write GNU gcov data to a file to collect coverage information.
Unfortunately, a normal embedded application has no argv[], and many system have no file system. A solution to this problem would be using semihosting with file I/O. Unfortunately for the Raspberry Pi Pico SDK 1.5.1 for the RP2040, there is no semihosting file I/O implemented :-(.
I have now implemented and added file I/O to the SDK, making it possible for the RP2040 to access and use files on the host, among other things. This greatly extends the capabilities of the device, and is very useful for testing, including gathering test coverage information.
With semihosting I can use standard I/O function like printf() and I can read and write data on the host through the debug connection. If used with care, this is a great feature especially for unit testing.