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|
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.