This year I managed to attend the Embedded World in Nürnberg/Germany after missing the 2016 show. And 2017 has been a blast! With more than 1000 exhibitors and >30’000 visitors it was huge! There were too many exciting things, so I just pick a few: NXP demonstrated the new MCUXpresso Software and Tools with a new Eclipse Neon based IDE, lots of IoT and Hexiwear, the tiny LPC800-DIP board, and I have met Alan Hawse in person!
The concept of Linux (Open Source, broad developer base and broad usage) is a success story. While there is a lot of diversity (and freedom) in the Linux world, Linux is Linux and again Linux :-). And the world has (mostly) standardized on Linux and its variants on the high embedded system side.
On the other side, the ‘middle and lower end’ Embedded world is fragmented and in many aspects proprietary. So it was no surprise to me when the Linux Foundation announced the ‘Zephyr’ project back in February 2016:
“The Linux Foundation Announces Project to Build Real-Time Operating System for Internet of Things Devices. Open source Zephyr™ Project aims to deliver an RTOS; opens call for developers to help advance project for the smallest footprint IoT devices.“
Ζεφυρος (Zephyros) is the Greek good of spring and the west wind. Obviously this inspired the logo for the Zephyr project:
One of the biggest road blocks (beside of closed source) using the BLE (Bluetooth Low Energy) stack from NXP is that it requires expensive tools to compile and build the stack. The good news is that I have now the NXP BLE stack for the Mikroelektronika Hexiwear ported to Eclipse and GNU gcc build tools for ARM 🙂
The Hexiwear device is a great and versatile device with two microcontrollers on it. Developing firmware on a Hexiwear means changing what was originally on it. And sometimes it happens that I’m not sure if the changes are for good. Or that I accidentally destroyed the firmware on the NXP Kinetis KW40 BLE microcontroller :-(. So I had to find a way to restore the original firmware, and this is what this post is about.
Command line tools to build applications are great. But productivity goes up if I can use the standard Eclipse environment with GNU tools. This tutorial is about how to use standard and free GNU and Eclipse tools to build my FreeRTOS application for the ARM Cortex-M4 on i.MX7 🙂 :
From time to time I face some problems which are really hard to find. Mostly these kind of bugs are very timing sensitive and depend on interrupt execution order. Maybe a dangling pointer is overwriting memory, code is running wild, or some functions are not reentrant as they should be. For these kind of bugs, good tools are worth their weight in gold. The Percepio FreeRTOS+Trace and the Segger SystemView have helped me many times to narrow down such kind problems in my applications. Another ultimate tools is hardware trace: Now I have a Segger J-Trace Pro for ARM Cortex-M in my arsenal of bug extinguishing weapons on my desk:
Dear bugs, look what I have on my desk. Your hiding time is over! 🙂
Smartwatches are around for a while now. To me it is still questionable how useful the ‘big’ ones for iOS and Android are. But there are definitely the crowd funded smartwatch projects which caught my attention. Maybe it is about the ‘do-anything’ with connectivity? One of these gadgets is Hexiwear: a hackable open source device
While it *could* be a kind of smartwatch, the value of this thing is more that it includes a plethora of sensors with two microcontroller, and I can use Eclipse with GNU tools to build my firmware :-).
Alert: Hackster.io is giving away 100 Hexiwears, but you need to hurry up (submission until July 15th 2016)!
My embedded applications are implemented mostly in C, a few in C/C++. But all of them have one or few assembly files included too: Assembly programming is the needed to do low-level things so it is a natural part of a true embedded application. For example I use often an assembly file for the application startup code.
I have run into a nasty Eclipse CDT issue which deals with assembly files projects. Here is a quizz for you: can you spot the problem in my project below?
With Processor Expert projects it is very easy to change the heap and stack size: There is a setting for this in the Cpu component settings, under the ‘Build options’ tab:
As there is no Processor Expert in the NXP Kinetis SDK V2.0 (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“), how to do the same in a SDK V2.0 project?
For my classes I had so far asked the students to install the Kinetis Design Studio (KDS) v3.0.0 and then apply several updates and upgrades available. NXP has now released the v3.2.0 of their KDS (Kinetis Design Studio):
The v3.2.0 is including all the 3.x.x updates in a single installation which makes things easier to start with. And it now works for Mac OS X “El Capitan” and the latest GNU ARM Eclipse plugins :-).
In case you are running into this problem that launching GDB hangs with this message in Eclipse:
If using a bootloader with an application, one thing is to to merge the bootloader with the application into a single file. I do this with the ‘SRecord’ tool like this:
srec_cat bootloader.s19 application.s19 -o merged.s19
When I create a project in Eclipse (e.g. in Kinetis Design Studio with the GNU ARM Eclipse plugins), I have to specify the name of the project during creation time:
But what if I change my mind later on and want to use a different name? How to rename the project?
For a space project we have to make sure that things are not failing while our hardware orbits around the Mother Earth. Therefore we are using different static and dynamic analysis tools, and one of it is using PC-lint from Gimpel to catch as many errors and bugs as possible. For that project, we are using Eclipse with the GNU ARM Embedded (launchpad) ARM compiler and Eclipse as IDE with the GNU ARM Eclipse plugins. There are commercial plugins available for linting with Eclipse (e.g. Linticator), but with a few tweaks it is possible to lint with Eclipse free-of-charge. So this article is about how to lint an Eclipse (Freescale/NXP Kinetis Design Studio) project with PC-Lint.
Readers of my blog know: I’m not a fan of printf(), and I think for many good reasons. Still printf() is widely used, and the GNU gcc tries to optimize things. This is observed with a simple example: If I’m writing
Then the code produced (ARM Cortex-M0+ with GNU ARM Embedded 4.9 2015q2 gives:
movs r0, #97 ; 0x61 bl 0xa98
Instead of calling
printf(), it is calling
putchar()! Why is that?
Many tool chains and linker are able to produce S19 files, such as with the GNU tools it is the ‘objcopy‘ which does this job (see “Binary (and S19) Files for the mbed Bootloader with Eclipse and GNU ARM Eclipse Plugins“). But these tools usually cannot handle the special cases. For example on the Freescale Kinetis K64F my serial bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“) had a problem with these lines in the S19 file:
Some of my robotics projects take a rather long time do a full build. When I developed applications with Visual C++ on the host, using precompiled headers gave me a big boost in compilation speed. I was looking for the same in similar with GNU and gcc, and as expected: gcc does support precompiled headers too. And indeed, I was able to cut down compilation time by 30% :-). So this post is about how to use gcc with precompiled headers in Eclipse/CDT to give my builds a boost.
It has been a while since I published my ‘build my own DIY IDE’ (see “DIY Free Toolchain for Kinetis: Part 1 – GNU ARM Build Tools“). I have used that approaches in my classes successfully. Now a new semester is coming up, so time to update the instructions using the latest Eclipse IDE (Mars) and tools (GCC ARM Embedded (launchpad) with GNU ARM Eclipse).
I have published a Sneak Preview how GNU gprof profiling looks for an embedded target ARM Cortex-M in an earlier post:
This tutorial explains how to profile an embedded application (no RTOS needed) on ARM Cortex-M devices with GNU gprof. Additionally I explain the inner workings to generate the data necessary for gprof.