I’m using many microcontroller in my projects. And a lot more are available out there in the ecosystem. Like many others, I tend to select what I am familiar with. But is this the correct approach to select the hardware and tools for a next project?
More and more these very-very-high-resolution (UHD, Ultra-High-Density) notebook displays show up in my class rooms.These displays have 3100×1800 or even more pixels, making it great for watching high-resolution videos or for playing games (maybe?). But such a high-resolution makes many tools including Eclipse very hard to use, because the toolbar icons get so tiny that they are really hard to hit with a mouse cursor on Windows:
Most of the time I’m using a dedicated terminal program like Termite or PuTTY to connect to a board using virtual or non-virtual COM port. Another way is to use the Eclipse built-in Terminal view: that way no extra program is needed to communicate with a real or virtual COM port to my target device:
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge. It this release more ARM Cortex devices/vendors are supported with different SDKs, plus it comes with several FreeRTOS enhancements for debugging highly optimized code.
For several projects I’m using library projects: I build a library and then use that library in the other project. If I change something in a library, I want to run make both on the referenced libraries and rebuild my application if needed. If you don’t know how to do this, then read on… 🙂
Shared Library Projects
(… actually it means workign around known Eclipse CDT bug too….)
ARM Cortex-M microcontrollers can have multiple memory controllers. This is a good thing as it allows the hardware to do multiple parallel memory read/writes. However this makes the memory map more complicated for the software: it divides the memory into different regions and memory segments. This article is about how to enable FreeRTOS to use multiple memory blocks for a virtual combined memory heap:
The tools and IDE market is constantly changing. Not only there is every year at least one new major Eclipse IDE release, the commercial tool chain and IDE vendors are constantly changing the environment too. For any ARM Cortex-M development, the combination of Eclipse with the GNU tool chain provided by ARM Inc. is the golden standard. But this does not mean that things can be easily moved from one IDE package to another.
While moving between Eclipse versions and GNU versions is usually not a big deal at all, moving between the Eclipse build tool integration is usually not simple. While the GNU MCU Eclipse plugins are widely used (see Breathing with Oxygen: DIY ARM Cortex-M C/C++ IDE and Toolchain with Eclipse Oxygen), the Eclipse based IDEs from the silicon vendors or commercial Eclipse toolchain vendors are using their own GNU toolchain integration. Which means the project files are not compatible :-(.
Eclipse as IDE takes care about compiling and building all my source files. But in an automated build system I would like to build it from the command line too. While using make files (see “Tutorial: Makefile Projects with Eclipse“) is an option, there is another easy way to build Eclipse projects from the command line:
I love 3D printing as it enables me to create custom enclosures for all kind of projects. The NXP LPC-Link2 probe is great, but it lacks a protective enclosure. So I decided to create a custom enclosure. And as 3D filaments are available in different colors, I experimented with red and black and custom painting:
The benefit of an IDE like Eclipse is: it makes working with projects very easy, as generates make files and it takes and automatically manages the make file(s). But sometimes this might not be what I want because I need greater flexibility and control, or I want to use the same make files for my continues integration and automated testing system. In that case a hand crafted make file is the way to go.
One thing does not exclude the other: This article explains how to use make files with Eclipse with similar comfort as the managed build system in Eclipse, but with the unlimited power of make files:
A bootloader on a microcontroller is a very useful thing. It allows me to update the firmware in the field if necessary. There are many ways to use and make a bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“). But such a bootloader needs some space in FLASH, plus it needs to be programmed first on a blank device, so a JTAG programmer is needed. That’s why vendors have started including a ROM bootloader into their devices: the microcontroller comes out of the factory with a bootloader in FLASH. So instead writing my bootloader, I can use the one in the ROM.
FRDM-KL03Z with ROM Bootloader
And as with everything, there are pros and cons of that approach.
For reliable applications, I avoid using functions of the standard libraries. They are banned for most safety related applications anyway. I do not use or avoid malloc(), printf() and all the other variants, for many reasons including the ones listed in “Why I don’t like printf()“. Instead, I’m using smaller variants (see “XFormat“). Or I’m using only the thread-safe FreeRTOS heap memory allocation which exist for many good reasons.
For a next-gen course I’m evaluating different platforms, and one of it are modules based on the NXP i.MX ARM architectures. In this article I have a look a the Variscite DART-6UL development kit which includes the NXP i.MX6Ultralite ARM Cortex-A7 plus a 7″ capacitive touch LCD: