I have been running recently into an interesting case where the GNU ARM Linker failed to link an application with strange error messages:
The ARM mbed USB MSD bootloader which is used on many silicon vendor boards has a big problem: it is vulnerable to operating systems like Windows 10 which can brick your board (see “Bricking and Recovering OpenSDA Boards in Windows 8 and 10“). To recover the board, typically a JTAG/SWD programmer has to be used. I have described in articles (see links section) how to recover from that situation, including using an inofficial new bootloader which (mostly) solves the problem. The good news is that ARM (mbed) has released an official and fixed bootloader. The bad news is that this bootloader does not work on every board because of a timing issue: the bootloader mostly enters bootloader mode instated executing the application.
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:
It can happen to everyone using Eclipse: launching Eclipse with workspace, and then it is stuck loading it. As a last resort, create a new workspace and go on? Possible, but painful, right? For some time I have a strange issue nagging me: from time to time, I’m not able to switch to a workspace which worked before. The IDE starts loading, but then is stuck:
Sometimes it is handy to know in the running application the start address, end address and the size of a linked section, e.g. to know the boundaries of RAM or FLASH areas. This means that from the application code I can get access to knowledge of the GNU linker:
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 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.
Last month (June 2017), the latest version of Eclipse “Oxygen” has been released, and I have successfully used it in several embedded projects. Time to write a tutorial how to use it to build a custom Do-It-Yourself IDE for ARM Cortex-M development: simple, easy, unlimited and free of charge. While the DIY approach takes a few minutes more to install, it has the advantage that I have full control and I actually know what I have.
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:
NXP has released an updated of their Eclipse based IDE for ARM Cortex-M (Kinetis and LPC) microcontroller: the version v10.0.2 build 411:
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 🙂
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.
I believe in ‘life-long-learning’. With this I continue to learn and discover new things every day. I’m writing tutorials to give something back to the community from which I have learned so much.
On top of this, I receive emails on a nearly daily basis, asking for help. Many articles have the origin in such requests or questions. I prefer questions or comments in a public forum, because that way I feel all others can benefit from it. Last week Alessandro contacted me with this:
I hope this find you well! I’m starting to using ARM processors, but I find them quite complicated on the configuration side. I started in the past with PIC micro (PIC16) with asm, and I found them quite straightforward to be configured (clock, IO, peripherals, …). Then I moved myself on C language, and on PIC18 without any big issues.
Now I would really like join the ARM community, I see that these processors are what I’ve always looking for, on energy, calc power, peripherals, and FINALLY on IDE (editor, toolchain and utilities)… AMAZING!!!”
The topic is about how to start learning developing for ARM. Alessandro agreed to make this public, so I thought this might be a good topic for an article?
In the area of IoT (Internet of Things), one obvious need is to have a way to send and receive data with an internet protocol. MQTT (or Message Queue Telemetry Transport) is exactly like that: a light-weight Machine-to-Machine communication protocol. With the MQTT protocol a microcontroller (or ‘client’) can send data and/or subscribe to data. For example to the Adafruit.IO:
In “MCUXpresso IDE: Importing Kinetis Design Studio Projects” I explained how Kinetis Design Studio projects can be imported and used inside the MCUXpresso IDE. Processor Expert projects can be used, but no new components added, modified or new Processor Expert projects created. To fully use Processor Expert, two plugins need to installed, and this is what this article is about.
Many of my currently active projects are using Kinetis Design Studio (KDS) V3.2.0 from NXP (I have published many of my projects on GitHub). Now with the advent of the MCUXpresso IDE (see “MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers“), I have migrated several projects from KDS to MCUXpresso. This post is about how to easily get KDS projects ported and running in MCUXpresso IDE.
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: