Possible Compilers

In the previous two posts we took a look at the options in CubeMX (Cube) and the C code that it produced, but we haven’t discussed which particular C compiler to use. Cube supports many but I really can’t tell you which one to use.

Cube can generate projects for many toolchains, listed below.. Remember that the startup code that Cube generates is not specific to any particular compiler. In fact, I take the Cube generated code and alter it slightly for use with the RTEMS RTOS, compiled by GCC as supplied for RTEMS.

Any competent C compiler that can generate code for ARM Cortex-M processors should work. If you don’t want to be that experimental, choose one from the list that suits your circumstances.

  
    Toolchain name
    Supplier
    Cost
    Limitations
    Supported OSs
  

    MDK-ARM V4/5
    Keil MDK Lite
    Free
    Restricted to 32K of generated code
    Windows
  

    MDK-ARM V4/5
    Keil MDK
    $5.5K + $770/year
    No limits
    Windows
  

    EWARM
    IAR EWARM Kickstart
    Free
    Unrestricted for 30 days but not for commercial use. Or feature limited kickstart version with 32K limit.
    Windows
  

    EWARM
    IAR EWARM
    $6K + $900/year
    Unrestricted
    Windows
  

    TrueSTDIO
    Atollic TrueSTUDIO
    Free
    No limits
    Windows (Linux and macOS coming) Uses GCC, GDB, Eclipse.
  

    TrueSTDIO
    Atollic TrueSTUDIO PRO
    $700USD/year
    Adds debugging features and support
    Windows (Linux and macOS coming) Uses GCC, GDB, Eclipse.
  

    SW4STM32
    OpenSTM32
    Free
    No limits
    Windows, Linux, macOS. Uses GCC, Eclipse, OpenOCD
  

Links: Keil IAR Atollic OpenSTM32

Other tool chains are available, such as GPDSC, mBed, and platformio.

For Embedded Wednesdays at ENTS, we used the SW4STM32 tool chain. The students had a variety of operating systems on their PCs and I didn’t feel it was appropriate to throw a multi-thousand dollar IDE cost onto the students, and telling them to go buy a Mac wouldn’t fly either. But, everybody in the class got the C compiler and debugger working by following the instructions on the web site.

There are too many versions of Windows, Linux, macOS, and Java for me to give a step by step guide to installing these systems. Each has a support forum to guide you. Embedded systems programming isn’t a spectator sport, it’s time to choose a compiler and get it going.

Kill the Blinky

Unbox your F4Discovery board, but don’t throw out the packaging, it’s a good protective box for now. Hook up your board using a USB A to mini-B cable. The F4Discovery has 2 USB connectors, a mini-B and a micro-B. The debugger module is the circuitry next to the mini-B connector. The F4Discovery gets its power through the USB connector on the debugger module. Plug in the debugger module to your PC and see what happens.

The F4Discovery comes preloaded with a test program that blinks the 4 LEDs. But if you push the blue button, the program changes so that the accelerometer data is used to control the LEDs. If you tip the board, the LEDs in that direction will come on.

Here is the challenge for the week:

Choose an IDE
Install it
Create a Cube project that just uses the defaults
Generate code
Import the project into your IDE
Compile the code
Load the code into your F4Discovery board

This will turn off the blinky lights because the default Cube project just goes into an infinite loop. This has got to be the most anticlimactic project ever, you can’t even run up to your friend and say “seeee?” because there is nothing to see. But turning off the LEDs means that your compiler is installed properly, your debugger is working, you can download code, and your code ran.

Next time, we’ll blink the LEDs, but to do that you will need to figure out your tools and kill those blinkies!

This post is part of a series. Please see the other posts here.