C/C++ compilers include a set of standard functions to be linked with user programs. They are called libc and libc++ respectively. For GCC, they are also called glibc and glibc++ (in the rest of this post, I would use glibc to mean both glibc and glibc++). Most of the functions are directly callable by the user programs, e.g. printf, but some are internal functions known to the compiler to support operations not directly supported by the target hardware. For example, double precision floating point add.
Traditional glibc is written for “big machines” such as Linux. For embedded use, it’s too bloated as embedded systems may not be running on top of an OS and advanced features such as locale (international language) support may not be needed. Even things like printf with full formatting and floating point support may take too much code for smaller microcontrollers.
From time to time, we refresh the GNU Embedded ARM compiler (GCC) in our JumpStart C++ with the latest stable GNU release. Earlier in 2019, we refreshed GCC to the 2018-Q4 release. Surprisingly, our testing showed a failure immediately:
objcopy.exe: 64-bit address 0x4b4fa300000000 out of range
The Microchip/Atmel SAMD21G18A is a powerful Cortex M0+ based MCU with 256K flash and 32K of SRAM. It’s used in the Arduino Zero as well as the Adafruit Metro and Feather lines of development boards, and is becoming a popular choice for users looking for a low cost powerful ARM Cortex-M MCU.
The SAMD21G18A used in the Arduino and Adafruit development boards is programmed with a bootloader. The Arduino IDE uses this feature to download programs onto the MCU.
However, instead of the limited Arduino IDE, you can instead use an advanced development environment such as JumpStart C++, Keil, or IAR. Besides getting the full benefit of using C/C++, you also can use visual debuggers that are lacking in the Arduino IDE.
In this article, we will examine some of the more popular Cortex-M hardware debug pods (also called debug probes), which are hardware devices necessary for debugging firmware on a Cortex-M based MCU.
Overview of Debugging
In the “good old days”, debugging an embedded system often meant the judicious use of printf to output debugging messages to a terminal. Fortunately, modern MCUs now come with hardware debug support that makes it easy to implement the core debugging features such as instruction breakpoints, and memory access. In the Cortex-M core specification, ARM Inc. includes a Coresight Debug Access Port (DAP) for just such purposes. As the DAP is present in all the Cortex-M base MCUs, this means that they all can provide debug support.
A strength of Cortex-M based MCUs is that the core CPU is designed by ARM Inc., while silicon vendors license the core design and then put their own I/O peripherals around it. With all major MCU vendors supporting the Cortex MCU, embedded designers have a large number of MCUs to choose from, while able to reuse their existing knowledge of the CPU information.
To make the software a bit more manageable, ARM has published the CMSIS (Cortex Microcontroller Software Interface Standard). CMSIS addresses the issues of portable macro defines and intrinsic functions common to the Cortex-M CPU cores. As each MCU has its own set of I/O peripherals, silicon vendors provide header files and sometimes C source files which let a user access the peripheral I/O registers and functions.
Hello, in 2018 we saw some exciting developments at ImageCraft. To celebrate, we are offering 18% off until end of the year. Use coupon code BYE2018 when you check out. Follow the instructions here: https://imagecraft.com/buy/how-to-use-coupon-code
Happy Thanksgiving! The first public release of REXIS is now available, as part of V9.07.00 of JumpStart C++ for Cortex, which you can download by clicking on the link.
ImageCraft creates different REXIS editions to fulfill the different needs of embedded developers. For consulting engineers, you can prototype, test, and work with the REXIS binary release by installing the JumpStart C++ for Cortex compiler. Get a ST-Nucleo F411RE and you can start running the examples immediately. The binary release is free to use for non-commercial use.
If you have read the blog on REXIS Examples, or the REXIS documentation, you may have noticed that REXIS supports synchronous message passing API, in addition to the more common asynchronous messaging with mailboxes. Synchronous message passing is not a new idea. Indeed, the inspiration came from QNX Neutrino, the message passing kernel that powered the BlackBerry smartphone devices in the early 2000s.
Synchronous message passing is a great idea. For example, it makes writing a “full-blown” OS (e.g. Linux) based on microkernel simpler. In such a system, OS services such as the file system support, networking etc. are written as regular tasks or processes instead of being part of the kernel code. Of course having a full OS is less important in a microcontroller system, but nevertheless, the use of synchronous message passing can give firmware a cleaner design. (We will see another example in this post below.) As a footnote, REXIS’ functions can be said to reflect those of a microkernel, perhaps pointing to a possible future path for its development.
Some RTOS producers are loathe to benchmark their products, or allow their users to do so. Here at ImageCraft, we welcome it :-). So let’s dive in and look at some numbers for the REXIS message passing API calls.
Even though we released the AVR and the Cortex-M debuggers a number of years ago, apparently some of our users do not know about it. JDB debugger is fully integrated with the CodeBlocks IDE, and contains a number of easy to use features such as I/O register view. The normal list price is $150, but for a limited time only, if you already have a compiler license, you can purchase the debugger for just $100.