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?
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:
With this, I can run the code on the embedded target which stores the coverage data on the host.
Continue readingI’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.
“Our highest priority is to satisfy the customer
Agile Manifesto, https://agilemanifesto.org/principles.html
through early and continuous delivery
of valuable software.”
It is interesting to see that modern tools and agile development workflows are getting more and more into the embedded world. CI/CD is a strategy where code changes to an application get automatically integrated, tested and released automatically into a production environment.
In a previous article I have imported an example project. Now I want to compile and build it.
Traditionally, the build action inside VS Code is somewhat hidden. There is a keyboard shortcut, but recent additions to VS Code making the build action more accessible.
In many of my embedded projects I need persistent data or storage for settings. If using an SD card, then FatFS is usually my choice for the file system. But if using an external FLASH memory device, then my preferred choice is usually LittleFS: it is a little fail-safe filesystem, designed for micro-controllers, which I’m using with external flash memory devices.
In the case where there is enough MCU flash, or if there is no external FLASH device available in a design, it can use the MCU internal FLASH as storage storage too. This is the topic of this article:
Embedded hardware comes with limitations, and one if it is the given number of hardware breakpoints. Depending on your MCU, 4 or only 2 hardware breakpoints are available, making debugging and stepping in read-only memory (FLASH) a challenge.
Did you know that one can have ‘unlimited’ number of breakpoints in FLASH, with the help of GDB? This is very useful for extended debugging, or if you want to use breakpoints for testing?
Continue readingSometimes it makes sense to write everything in assembly, even these days. For example if using a tiny microcontroller. Or just if one just don’t need all the productivity of the C/C++ tools. And it is a good educational experience: getting hands-on on the lower levels.
A Triumvirate is or Triarchy is built by three individuals which lead or rule something. In this article I want to rule a project with Eclipse CDT, Visual Studio Code and with building it from the command line for automated builds.
So what if I have an Eclipse project (say MCUXpresso IDE and SDK), and want to build it on a build server, and and I want to use the same time the project with Eclipse IDE and Visual Studio code?
Key to this is CMake: I’m keeping the Eclipse CDT features, adding CMake with Make and Ninja to the fix, and have it ‘ruled’ by three different ’emperor’: Eclipse, Visual Studio Code and from a shell console:
One essential part of embedded development is the ability to debug the target application. The good thing with the Raspberry Pi Pico RP2040 Eco-system is: One can use another RP2040 Pico board as a debug probe to debug other ARM Cortex-M devices.
But instead using a Raspberry Pi Pico board with some wires, why not building a dedicated board? The result is a small, versatile and open source debugging probe which virtually can debug any ARM Cortex-M device as a standard ARM CMSIS-DAP probe:
MCU on Eclipse 