There are situations where what you need is an API of all the low level register access definitions and functions/Macros or whatever you want to call them, routines even… and you want to write your own code the best way you know how, whether using an infinite while loop in main or using an embedded operating system like FreeRTOS. The main focus at the beginning of writing embedded software is figuring out the memory mapping, startup and hardware drivers. Once you have those in place and test them roughly, you want to write application code. The tools provided by manufacturer as an IDE provide you with a way to create a new project for a specific micro-controller, putting together the MCU header file, the linker script, the startup script and potentially the peripheral registers declarations or drivers.
For ARM®, there is of course the Cortex® Microcontroller Software Interface Standard (CMSIS) that helps abstract hardware access. Its implementation provides a standard interface for the core of the micro-controller, the ARM CPU and peripherals. It has been extended beyond the core to interfaces like CMSIS-DAP debug and later to others including Drivers, DSP, RTOS-API, Software Packs and SVDs which are System View Descriptions for peripherals e.t.c. This has kind of standardized software interfaces make porting code to new microcontrollers easier and encourage code re-use. It is, I believe the reason why Mbed, FreeRTOS and other operating systems have been ported to ARM microcontrollers and support for different families of these microcontrollers added so fast. It has also allowed GUI tools developers add more features to their software suites to better help the developer debug hardware. Stuff like peripheral register views were not available in eclipse when I started writing tutorials on how to install vanilla eclipse, then add hardware debug plugins. USBDM is one debug software that I loved to learn about. GNU ARM Eclipse Plugins by Liviu Ionescu is another success story for me. I loved that at a time when I could not afford to procure the then CodeRed suite license, I could still own my hardware by adopting purely open-source tools like OpenOCD, USBDM, GNU-ARM toolchain and Eclipse IDE.
Zilog then Freescale
I started learning embedded systems development at the University of Nairobi, Physics department when I was doing my undergraduate degree, we were using Zilog Z8 microcontrollers back then. I wrote quite some code for those controllers, spent months figuring out the hardware architecture, reading datasheets and finally I had something going. I was able to understand how to write to specific hardware registers to implement drivers for peripherals in the microcontroller. I posted the Z8_64K and the Z8_4KXP repositories on github because I was proud of what I was doing. I started working for the department soon after graduating, and in the electronics section, we were having discussions on how to improve the courses offered. One of the resolutions was to move to ARM based microcontrollers. Luckily, we had a good relationship with Freescale, they donated 14 TWR-K60N512 microcontroller KITs to our lab. There was no money to buy their IDE, so the KITs had been gathering dust in storage for a while. I decided to look around and thats when it hit me: there were open-source options out there at every level from compile all the way to the IDE. I had already switched to Linux(Debian) and learned how to build software from source, including the kernel. I spent like a month working on the terminal to build sample projects for the KIT and testing, patching OpenOCD using patches from the forums and reading the datasheet for the k60 MCU and later integrating everything in Eclipse and testing with the Tower KIT. I was able to create a standard embedded systems programming lab based on the KIT, it has many peripherals to learn with and has an on-board debug probe which is supported by OpenOCD. We later also acquired the Freescale Freedom Boards: FRDM-KL25Z, FRDM-KL05Z and FRDM-K64F with a variety of microcontrollers in those families, made custom boards and successfully debugged them with the KITs without purchasing a “professional” debug probe.
After a while working with these self-configured IDE, Freescale released a well bundled Eclipse based Kinetis Design Studio IDE in which they integrated Processor Expert and Debug interfaces like P&E, Segger JLink and OpenOCD. It was like a dream come true for us because now we had a single installation file which simplified the installation procedure. When you have a class of more than 20 students, and most of them are requiring time to consult, its not the most ideal situation. KDS has been our preferred IDE until this month.
Just the other day I also saw that Zilog started making ARM-Cortex M3-based microcontrollers… but I would never go back to Zilog because they do not support open-source technologies.
Before purchasing the Freescale Freedom boards, we had acquired one NXP LPC board from embedded artists, the LPCXpresso LPC227 and some LPC microcontroller chips. We couldn’t get any open-source tools to work with this board, so again it has been gathering dust in storage. I have never read an LPC microcontroller datasheet for that reason. Then NXP bought Freescale, I did not see that coming. This left me wondering, are we going to see some form of merger of the microcontroller families or even the tools. NXP took over Kinetis Design Studio(KDS) which kinda put everything we were doing with Vanilla Eclipse and plugins into a single installation file with support for all kinds of debug probes, and Processor Expert(PE). They continued with the development of KDS but discontinued PE. NXP had LPCXpresso IDE, which is also eclipse based, but as far as I know isn’t free.
Not everybody is comfortable in writing embedded C code. I do teach my students with a goal to finally be able to do this, but sometimes it’s also about how fast you can be able to put together a working prototype with minimum efforts and test the waters in a project. This is where Processor Expert tool comes in. You just add a few components to a project, generate code and drag drop a few function calls in to the main method. You can change the hardware driver settings in drop-down menus and regenerate the code until you get the desired functionality. The generated code can be tweaked further as desired. In fact, most of the bare-metal projects I saw when I first started working with Freescale’s ARM cortex M0 and M0+ micro-controllers were bearing an acknowledgement that “This code was generated using Processor Expert tool and tweaked by hand to remove unnecessary code and comments, and to optimize”. Freescale seemed to know what they were doing, they had every kind of embedded systems developer in mind when developing their tools.
NXP just recently (March 2017) released a new IDE – MCUXpresso which is like LPCXpresso from what I hear, but on steroids. It has no PE support but has a feature for adding SDKs for specific microcontollers. There is a free version which seems to have no meaningful restrictions as an educational version, infact you can use it for commercial projects without the traditional code size limits we are used to in proprietary tools. Another thing is, it is a merger of support for both Kinetis and LPC microcontrollers. This allowed me to debug my LPCXpresso LPC1227 board with this IDE, which is pretty awesome.
The reason I am happy with this is simple: I have been having issues with how not flexible the SPI interface is in Kinetis devices, its either 8-bit data width or 16-bit. That’s it, if you have a slave that has any other data width in its communication protocol, you just have to do bit-banging SPI, which is really slow. Well, you can optimize the I/O transactions with timer interrupts and DMA but, isnt it just great if the hardware interface supported all kinds of data width? well, LPC controllers support all widths from 4-bit all the way to 16-bit. Not that I will ever do a 7-bit or 13-bit protocol, but who knows?
This has given me the freedom to use any of the Kinetis or LPC microcontrollers in my projects. With Kinetis families, I have the Kinetis SDK for drivers. I have no idea how one develops for LPC, I better learn that now that I have the opportunity and reason to.