The Raspberry Pi Pico RP2040 is a very versatile microcontroller. It is not the least expensive or the most powerful microcontroller, but it is one which is available and has an excellent software and tool ecosystem.
This article shows how to use the Raspberry Pi Pico-W with BLE and optional WiFi, running with FreeRTOS.
Most embedded developers have probably used ‘semihosting’. And yes, it is generally seen as a bad thing. Maybe you have used it, without realizing what it really is and what it does. It is simple to add a printf() to the code (again: you should not use printf), and with the right standard library, it magically it shows up in a console view:
That looks great, but what is behind this, to make it happen? Actually, it is really amazing technology. And it can be used for better things than just printing text.
On my host machine I have many different development environment installed. From different make, cmake and python versions up to different versions of GNU tool chains. Adding them to the PATH environment variable on Windows is really a bad thing: instead I want to keep my PATH as clean as possible. If I need to set up a different environment with different tools, then I prefer to have a ‘local’ environment.
One of the biggest fears of embedded systems developers are stack overflows. FreeRTOS includes a cool feature to monitor and catch task stack overflows. But what about the MSP (Main Stack Pointer) on ARM, or the interrupt stack? What if not using an RTOS and running a bare-metal application?
There is a simple way monitoring stack usage at runtime, and for this I want to share the routines and what is now available inside the McuArm module.
Every embedded system developer should know by now, that using printf() is not a good thing for smaller systems. Printf() and the like are not only problematic from a code and data size perspective, they are infamous for vulnerability attacks too.
In this article I’ll show you multiple ways how to ban printf() or anything similar you want to avoid.
I’m in the final stage of finishing a electrical vehicle (EV) charger controller, which optimizes battery loading using the available PV system: use as much as possible the solar energy and not the grid.
When developing with C or C++ an application, then you mostly focus on your own code. You don’t want to bother with the details how input/output functions like printf() or scanf(), and you might just use these functions and helpers and that’s it.
The implementation is part of the ‘C Standard Library’ (or C++ Standard Library). In the world of Linux, this is usually the ‘glibc’ or ‘GNU C Library, and one usually link with ‘libc’. That provides the implementation of printf(), or use ‘libm’ if using math functions like sin() or cos().
In the embedded world, things are much more complex, with plethora of choices, for example in the MCUXpresso IDE:
The year 2022 is coming to an end, and I have spent some time today on a little side project. It is about making an Electrical Vehicle (EV) wallbox charger accessible over Modbus RTU. It is not finished yet, and I plan to publish more articles on it, but I can share that I’m able to access and control the Heidelberg EV charger with a Raspberry Pi Pico W (Dual Core Cortex M0+), NXP K22FN512 (Cortex M4F) and LPC845 (Single Core Cortex M0+):
The RP2040 Pico board comes with 2 MByte onboard FLASH memory. While this is plenty of space for many embedded applications, sometimes it needed to have more storage space. Having the ability to adding an extra SPI FLASH memory with a useful file system comes in handy in such situations. This makes the RP2040 ideal for data logger applications or otherwise store a large amount of data. In this article I’ll show you how to add an extra 16 MByte of memory to the Raspberry Pi Pico board, running FreeRTOS, a command line shell and using LittleFS as the file system.