Flatten the Learning Curve for Programming STM32 MCUs

One of the most difficult issues in moving to Cortex-M MCU development from an 8-bit ecosystem is the complexity of the I/O peripherals. The Cortex-M peripherals are more capable and more flexible, but are also more difficult to use and write programs for. To help users gain proficiency as quickly as possible, we created the JumpStart API. You can see on the linked page how it clearly beats the competition such as mBed and ST’s libraries. In this post, we will look at some practical examples.

Challenge 1: Write a program that toggles an LED using a timer interrupt – let’s say, timer1 – with your favorite programming platform for an STM32F MCU. Let’s assume that the LED is attached to PA5, which will be toggling at 1Hz . Ready? Here is the complete code fragment if you are using JumpStart API. :

Continue reading
Posted in Uncategorized | Leave a comment

Your chance to JUMPSTART Cortex MCU development

Are you interested in upgrading your ease-and-speed-of-programming options?

Are you still working with 8-bit MCUs and wish to take advantage of the more powerful and even lower cost Cortex-M MCU, but are worried about making the jump? Are you working with slow Eclipse-based IDE or ST CubeMX and wish that just loading the tools won’t require taking a long coffee break? Are you daunted by how difficult it can be to just get an LED blinking and wish for an easier way to do it? Are you frustrated with unsupported free tools that cost you time and money to get started?

Your wish has now come true. With ImageCraft’s latest 9.12 release of the JumpStart C++ for Cortex, you can develop for most popular Cortex-M MCUs, with great visual debugging as well. Thanks to the efficiently-written JumpStart API (JSAPI), if you are using a supported $13 ST-Nucleo board, you can get “Hello World” and blinking LEDs working in literally minutes after you install the programs.

ImageCraft makes JumpStart C++ easy to use because we also use it ourselves. Confused by the difference between newlib or nanolib, and which to use? So are many other people, so we make it simple to use (a single checkbox is all you need to switch between the two libraries) and we even wrote a blog article about it to demystify the issues:

And now: ImageCraft is the first compiler vendor to provide seamless one-checkbox support for QFPlib, an alternative floating-point library that takes just over 1K bytes of code, including trigonometric functions! https://imagecraft.com/blog/2019/05/qfplib-a-compact-floating-point-library-for-cortex-m/

You may currently purchase the compiler plus the visual debugger for $300, a discount of $100! And, what could make this even better? How about taking an additional 10% off until June 15, 2019? Use the coupon code CRAZY10OFF (valid for the bundle purchase only) and follow the instructions here: https://imagecraft.com/buy/how-to-use-coupon-code

Posted in Uncategorized | Leave a comment

QFPlib, A Compact Floating Point Library for Cortex-M

Cortex-M0 based MCUs are notable for their low cost and relatively smaller amount of available flash memory. If you wish to use floating point operations but are running tight on space, QFPlib is a great alternative. The core single-precision floating-point add/sub/mul/div/cmp operations take less than 400 bytes. According to QFPlib’s author, the corresponding routines in the GCC native library, by contrast, are over 2700 bytes in size, and the whole M0 library, including some trigonometric routines, comes in just slightly over 1K bytes.

QFPlib is even smaller than floating-point routines for other micros, including some such as the one for MSP430, which is known to have high code density. This table is a screencap from the author’s page at https://www.quinapalus.com/qfplib.html This is a comparison for the core arithmetic routines only:

But how about the downsides of QFPlib? There are two major ones:

1. QFPlib is released using GNU GPL V2 license with alternate licensing possible from the author. This means that your code will also have to be released under GPL V2 if you use QFPLib (however, see below).

2. You have to manually call QFPlib functions to perform even the basic operations such as add, e.g.: instead of writing “float_a + float_b”, you write “qfp_fadd(float_a, float_b)”

For licensing issues for a commercial firmware developer, practically this means that you can try out QFPlib if you are running low in memory, and if you later want to use it in a final product where you will not be releasing your code under GPL, then you will have to contact the author and purchase a commercial use license. I do not know what the cost of a commercial license is, but the author has said that it is reasonable.

Regarding ease of use, if you are using JumpStart C++ for Cortex, now you can use QFPlib by just enabling it with a checkbox:

Once done, your (single precision) floating-point operations will be done “automagically” using the compact QFPlib with no source code changes needed! Just write “float_a + float_b”, and QFPlib will be used.

QFPlib also includes trigonometric functions that are much smaller than the default GCC code. For those, you will have to explicitly call the functions due to the way GCC works. You can find out more details in our online manual: https://imagecraft.com/documentation/jumpstart-c-documentation

Finally, QFPlib also comes in a Cortex-M3 version where the focus is on high-accuracy operations rather than small size. Again, the single checkbox shown above will enable it for -M3/M4/M7 based MCUs.

Posted in Uncategorized | Leave a comment

How Much Flash and SRAM Does My Project Use?

When developing firmware for an embedded project, it is important to know how much flash and SRAM the program is using. This allows you to make the best decision on whether the chosen MCU has sufficient resources for your needs.

By default, GCC does not give any information regarding program size. However, GCC does include a utility that can help, sensibly it is called “size.exe” (or “arm-none-eabi-size.exe” for the embedded GCC version). If you run the program as follows:

c:\iccv9cortex\gnuarm\bin\arm-none-eabi-size -A -x bin\Debug\Test.elf

The /path/to/ is as installed by ImageCraft’s JumpStart C++ program, but any embedded GCC installation will have this program. The last argument is the input file (in default ELF format). “-A” means to output in SysV format (Berkeley format is the other option), and “-x” is to use hexadecimal output. The above produces something as follows:

bin\Debug\TestDriver.elf  :
section size addr
.text 0x6720 0x8000000
.ARM.extab 0x258 0x8006720
.ARM.exidx 0x2f0 0x8006978
.ARM.attributes 0x2a 0x8006c68
.data 0x804 0x20000000
.bss 0x9c0 0x20000804
._user_heap_stack 0x2804 0x200011c4
.debug_line 0x405a 0x0
.debug_info 0x24c75 0x0
...
.debug_ranges 0x60 0x0
.comment 0x75 0x0
.debug_frame 0x2dd4 0x0
.stab 0x9c 0x0
.stabstr 0x14f 0x0
Total 0x3d8f3

Each line represents a “region” in the output file. If a region has an address of 0x0, it means that it is not using any space in the target MCU and most likely only contains debug information, and will be used for debugging only. The regions’ names and allocations are controlled by the linker script used so your output may look slightly different.

The entries of interest are: .text this is the size of your program, i.e. flash usage. In this example, 0x6720 or 26400 bytes of flash is used, plenty left over from the 512K STM32F411RE that I am using.

.data and .bss are the static SRAM usage. .data has the global/static variables that have initialization, and .bss has the global/static variables that have no initialization (but are initialized to zero per C/C++ definition). In this case, 4548 bytes are needed, also significantly less than the 128K bytes of SRAM available on the F411RE.

Finally, ._user_heap_stack is the area reserved for memory allocated at runtime, heap is for memory used by malloc/free, and C++’s “new” etc., and stack is used for mainly for local variables and function context. As the runtime memory size changes as your program is run, this is only the minimum amount set in the linker script. Your program controls how much dynamic memory it uses. Stack usage depends on the call patterns in your program and how much stack space (e.g. local variables) a function uses. A future blog post will describe one way to determine stack usage of a program.

You can write a simple utility program to process the “size” output to give a simple summary, which is what we have done with the JumpStart C++ tools. A typical post-build message looks like this:

ELF file output size
Code size: 26400 bytes starting at 0x08000000
SRAM data: 4548 bytes starting at 0x20000000
Heap and Stack: 10244 bytes heap starts 0x200011C4 stack starts 0x200039C8

With size.exe and some processing, it is simple to see your program’s flash and SRAM requirements.

Posted in Uncategorized | Leave a comment

Embedded GCC Libraries: newlib vs. nanolib

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.

Continue reading
Posted in Uncategorized | Leave a comment

2018-Q4 GNU Embedded ARM objcopy “64-bit address… out of range” Error

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 
Continue reading
Posted in Uncategorized | Leave a comment

Removing Bootloader Protection On The AdaFruit Metro / Arduino Zero / SAMD21

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.

Continue reading
Posted in Uncategorized | Leave a comment

Cortex-M Debug Pods

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.

Continue reading
Posted in Uncategorized | Leave a comment

Cortex Compiler: Vendor SDK

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.

Continue reading
Posted in Uncategorized | Leave a comment

Happy Holidays and 18% Off Until End of the Year

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

Continue reading
Posted in Uncategorized | Leave a comment