We are creating a new course (PRG-G) at the Lucerne University. This course teaches C programming and is part of the new curriculum in EE (Electrical Engineering). Every student will receive a microcontroller board on an extension board as give-away, in a custom card box for the board and cable. To make things a bit more exciting, why not laser engrave that box? That gives me a perfect excuse to experiment with the laser cutter 🙂
Eclipse is probably the most used and de-facto standard IDE for any development for ARM Cortex or any other devices. It is very easy these days to construct an unlimited and unrestricted IDE (see “Breathing with Oxygen: DIY ARM Cortex-M C/C++ IDE and Toolchain with Eclipse Oxygen“). Up to the point that I can pack it into a .zip file and pass it around e.g. in a class room environment, so no installer at all is needed with the exception of the debug probe USB drivers. As Eclipse is using a Java Virtual Machine (VM), it is a good idea to bundle the VM with the IDE, and this article is about how to do this.
There are people around me who think I’m crazy. And they are probably right. Who else would buy a machine from someone he does not know. I have to pay upfront. It is not clear how things will get delivered, what gets delivered, or if it gets delivered at all. Up to the point I can lose the money I have spent. Best of all: that machine is dangerous enough to potentially kill me. And it has the potential to put my home on fire too. Well, that sounds like an exciting weekend project, or not?
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:
Sometimes it happens that arm-none-eabi-gdb complains about “no source file named” in the GDB console view in Eclipse when I debug a project with GDB:
FreeRTOS seems to get more and more popular, and I think as well because more and more debugger and Eclipse IDE vendors add dedicated debugging support for it.
By default, the GNU Linker expects a very special naming scheme for the libraries: the library name has to be surrounded by “lib” and the “.a” extension:
But what if the library I want to use does not conform to that naming standard?
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.
And as with everything, there are pros and cons of that approach.
If you are like me – someone who always wants to know what the compiler generates for a piece of source code – then have a look at the Compiler Explorer: A web-based compiler code comparison tool:
Thanks to Matt Godbolt, I can select different compilers and compare their output for a given source code. Very useful to see the impact of a compiler optimization or to compare different GCC compiler versions.
Happy Comparing 🙂
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
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.
Things get problematic if
malloc() still is pulled in, either because it is used by a middleware (e.g. TCP/IP stack) or if using C++. Dave Nadler posted a detailed article (http://www.nadler.com/embedded/newlibAndFreeRTOS.html) about how to use newlib and newlib-nano with FreeRTOS.
Some silicon vendors provide their Eclipse example and SDK projects using linked files and folders. For example a bootloader demo application is provided in the context of an SDK or library. That’s fine until the time I want to transform such an example into a real project or if I want to have it without the hundreds of files for all the other devices I don’t need or use. I cannot take the project and put it into a version control system as the linked files won’t be in my VCS. I cannot move the project to another place as the links are pointing to many places. What I need is a ‘standalone’ project: a project which has all the needed files in it and is self-containing.
Don’t get me wrong. I love a good slow-smoked and true BBQ pulled pork shoulder just as probably everyone else out there. And I love the babysitting (aka beer drinking 🙂 ) while the shoulder gets that incredible taste inside the smoker. But my workload for this weekend is insane high with all the university exam and grading work. My family loves that pulled pork too, and I knew upfront that I would not have the time to check and handle the smoking process for 12-18 hours (see “Easter Weekend Apple Juice Brined Pulled Pork Smoked on Beech Wood“). So I decided to prepare pulled pork the ‘easy’ way: Using a Sous Vide cooker and then use a normal oven to finish it. So it was an experiment, and the result is interesting:
I like to have as many lines of source code visible on my notebook or desktop monitor. And I think I have found a good balance between font size and readability.
On the other side: I’m getting older and my eyes are not getting any better. At the same time I noticed that students start using these ‘high-resolution-retina-displays’. They are great, but result in tiny default system fonts, so I have a hard time to read the source code on their machines.
Another challenge I noticed are the high-resolution projectors in class rooms or conferences. They are not well suited to show source code or text files because of the tiny fonts. Starting with Eclipse Neon there is an awesome feature which I can use to dynamically increase and decrease the font size which solves that problem:
The GNU tools include powerful utilities to collect coverage information. With coverage I know which lines of my code have been executed, which is a very useful test metric. The GNU coverage tools are commonly used for Linux applications. But to my surprise not much for embedded application development, mostly because it requires a few extra steps to have it available? Why not using free and powerful tools for improving software quality? This article explains how to install the GNU gcov tools into the Eclipse IDE.
In “Cycle Counting on ARM Cortex-M with DWT” I have used the ARM DWT register to count the executed cycles. With the MCUXpresso IDE comes with a very useful feature: it can capture the ARM SWO (Single Wire Output) trace data. One special kind of trace data is the ‘cycle counter’ information which is sent through SWO.
The spring university semester is coming to an end, and the Infotronic course closed with a Sumo robot challenge. Great challenge, new technologies, innovative approaches and funny designs 🙂
If I open a new workspace in Eclipse, it shows me the default ‘Welcome’ view: