MCU vendors offer SDKs and configuration tools: that’s a good thing, because that way I can get started quickly and get something up and running ideally in a few minutes. But this gets you into a dependency on tools, SDK and configuration tools too: changing later from one MCU to another can be difficult and time consuming. So why not get started with a ‘bare’ project, using general available tools, just with a basic initialization (clocking, startup code, CMSIS), even with the silicon vendor provided IDE and basic support files?
In this case, I show how you easily can do this with CMake, make and Eclipse, without the (direct) need of an SDK.
In this time where many micro-controllers have 100+ weeks estimated delivery time, it makes sense to look at alternatives. So it is not a surprise that the Raspberry Pi RP2040 gets used more and more in projects. It is not only inexpensive, it is (at least for now) available which makes all the difference. The RP2040 is the first microcontroller from Raspberry Pi: a dual-core ARM Cortex-M0+ running up to 133 MHz, 264 KByte on-Chip RAM and up to 16 MByte external FLASH.
It is a very versatile microcontroller, with a rich eco-system and set of tools. It can be easily used with C/C++ or MicroPython, and the Raspberry Pi Pico board only costs around $5. There are plenty of tutorials out there, for example how to use the Pico board as debug probe to debug another Pico board. While this is great, there is an easy way to use any existing J-Link and Eclipse IDE too, so this is what this article is about.
You might never heard about ROM Libraries, and you are probably not alone. Some might thing that this refers to the boot ROM modern MCUs have built in, which is kinda close. But the thing here is about to build your own (possibly constant) ROM library, program it to your device of choice, and then use it from the application running on the device.
So the concept is to have a (fixed, stable) part with code and data on your device, which can be used by a (possibly changing) application: Think about a stable LoRaWAN network stack in the ROM, with a changing application using it: Would that not be cool?
This not only adds flexibility, but as well allows smaller updates, as only a part of the program has to be changed or updated.
The question is: how to create and use such a ROM Library with the normal GNU build tools?
I’m now in the middle of the university fall semester exam season with writing exams and grading student work, and the same time the new semester courses need to be prepared. With the global silicon and board shortage, this will be again a challenge to equip all the labs with the needed infrastructure. The good thing is that there is no shortage on software and tools side of the infrastructure: NXP released last week their new flagship Eclipse based IDE: the MCUXpresso IDE 11.5.0. Time to check it out for the upcoming lectures and classes….
Spoiler Alert: It has a new view for FreeRTOS lovers, plus new features for energy/power measurements!
Welcome to ‘Alice in Wonderland‘! For a university research project using an ARM Cortex-M33 we are evaluating position-independent code as way to load applications or part of it with a bootloader. It sounds simple: just add -fPIC to the compiler settings and you are done.
Unfortunately, it is not that simple. That option opened up a ‘rabbit hole’ with lots of wonderful, powerful and strange things. Something you might not have been aware of what could be possible with the tools you have at hand today. Leading to the central question: how is position-independent code going to work with an embedded application on an ARM Cortex-M?
Let’s find out! Let’s start a journey through the wonderland…
“A young man is smoking one cigarette after each other without a pause. An elderly woman observes that and says: “Young man, you are smoking like crazy! Don’t you know that there is a warning on each cigarette package that this can kill you?” The young man finishes his cigarette, looks at the elderly person and says: “Yes, I know. But look, I’m a programmer, and it is only a warning.”
I don’t smoke, and I do pay attention to warnings :-). I always try to keep my source code free of compiler warnings. And I always pay special attention to the following on:
If you are developing Linux or desktop applications with GNU tools, you very likely are familiar with gcov: the GNU coverage tool. It collects data what parts of the code gets executed and represents that in different formats, great to check what is really used in the application code or what has been covered during multiple test runs.
Coverage Information with gcov
line never executed
GNU coverage is possible for resource constraint embedded systems too: it still needs some extra RAM and code space, but very well spent for gathering metrics and improves the firmware quality. As I wrote in “MCUXpresso IDE V11.3.0 for 2021” things are now easier to use, so here is a short tutorial how to use it.
There are many different aspects of Open Source projects: It is not only about the fact if the sources are available (‘open’). It is about the licensing terms (how permissible is it, what can I do with it), maintenance and continuous development (what has changed between releases), how and where is it delivered (Sourceforge, dedicated distribution, packaging) up to collaboration (how can I contribute or submit issues).
I’m in the middle of the university exam season: means writing exams and do grading. The same time the new semester is approaching too and I need to prepare the new course material. For the classes using NXP parts I’m using the Eclipse based MCUXpresso IDE, and I just received the announcement that a new version V11.3.0 is available: time to check out what is new.