ARM Toolchain General Discussion

[jakeypoo]

Some interest about this in the other thread.

Discuss your preferred toolchain, compiler, debugger. Also post which cores you are compiling for and whether you use an OS/RTOS or any other sort of middleware.

I'm moving to Cortex M0 in the hope it's an 8-bit micro replacement. There are a bunch of M0 chips out there that are more powerful and have more peripherals than the average 8-bit microcontroller and they fall in the same price range or cheaper!

I'm used to developing on AVRs using avr-gcc, avrdude and avr-gdb from the command line. As I'm just looking to move to more capable cortex-M without any of the overhead of an OS, I'm currently building a toolchain based on the GNU ARM compiler (arm-none-eabi). Target is a NXP LPC11Uxx board, but hoping to move to atmel if they release some cheapo development boards for M0/M3/M0+

Getting through the startup and linker files has been painful. Next onto device files and peripheral files!

Personally I'm not a fan of any Windows only, Lite/Limited toolchains; but feel free to post about your experiences with them.

[jancumps]

TI proprietary IDE (code composer studio v6, eclipse based) and TI compiler/linker/jtag emulator, targeting TMS570 ARM R4.
On linux and windows.
Sometimes with freertos, mostly without.

[andyturk]

What does "8-bit micro replacement" mean? I guess it makes sense from a cost point of view... some of the Cortex M0s are really cheap. E.g., I've got a Cypress CY8C4013 on my desk at the moment. Those things are $0.29 in a SOIC-8 package and have 8K flash and 2K RAM. Right next to the tiny guy is the biggest PSoC from Cypress, an M3 with 256K of flash and 64K of RAM. On my other desk are various projects using STM32 M4 beasts with floating point, 1Mb of flash and 200K of RAM.

The cool thing is that I can use the same (free, open source) toolchain for any ARM Cortex mcu and I'm not stuck with some crippled, half-assed OEM development environment. Emacs for the win!

That startup/linker pain you feel is a good pain. It's probably a little more complicated than the 8-bit world (of which I have no experience), but once you can write your own reset code and craft a .ld file, you basically own the mcu and are free to make it do what you want. You'll probably want to make friends with openocd too, which has it's own learning curve.

Re startup code, here's some reset vector code I've been using:

Code: [Select]

#include "ptk/ptk.h"

#include "stm32f4xx.h"
#include <cstdint>

/*
 * This file contains ARM Cortex exeption handlers that are specific to the
 * application.
 *
 * The Reset_Handler() doesn't have any application specific code, but it
 * has to be in a different compilation unit than the "weak" default definition
 * in cortex_handlers.cc. For that reason, Reset_Handler() is defined here.
 *
 * Every exception handler is a void function without arguments. Furthermore,
 * since the vector table mechanism used here depends on GCC's implementation
 * of weak references, these functions must not be name-mangled by C++. That's
 * why they're in an extern "C" block.
 */
int main();

extern "C" {
  void _init(void) {
  }

  extern uint32_t SystemCoreClock;
  extern void SystemInit(void);
  extern void SystemCoreClockUpdate(void);

  // This function is generated by the linker
  void __libc_init_array();

  // These locations are provided by the linker file
  extern unsigned long _etext;
  extern unsigned long _data;
  extern unsigned long _edata;
  extern unsigned long _bss_start;
  extern unsigned long _bss_end;

  void Reset_Handler(void) {
    unsigned long *src = &_etext;
    unsigned long *dest = &_data;
    unsigned long *limit = &_edata;

    // initialize .data
    while (dest < limit) *dest++ = *src++;

    dest = &_bss_start;
    limit = &_bss_end;

    // initialize .bss
    while (dest < limit) *dest++ = 0;

    // GNU libc initialization
    __libc_init_array();

    // ARM CMSIS initialization
    SystemInit();

    // run the app
    main();

    while (1);
  }

  void HardFault_Handler(void)  {ptk_halt("hard fault"); }
  void MemManage_Handler(void)  {ptk_halt("memory management fault"); }
  void BusFault_Handler(void)   {ptk_halt("bus fault"); }
  void UsageFault_Handler(void) {ptk_halt("usage fault"); }

  void SysTick_Handler(void) {
    ptk::enter_isr();
    ptk::expire_timers(1);
    ptk::leave_isr();
  }
};


[dannyf]

CoIDE (for myself) and Keil / Iar for work. CCS for TI chips.

jlink generally and st-link for st chips.

[andyturk]

On the topic of Cortex reset vectors, here's an approach I've been playing with:

First, define an X Macro with one entry for each element of the vector table. Here's one for a STM32F4. Apologies in advance for tabs not lining up nicely in forum posts.

cortex_handlers.h

Code: [Select]

#pragma once

/*
 * This macro defines the names and order of the interrupt handlers for the
 * a STM32F4xx mcu. The macro is defined once and expanded multiple times as an
 * X Macro (ref http://en.wikipedia.org/wiki/X_Macro).
 * In this case, the first expansion generates forward declarations for the
 * interrupt entry points. The second expansion fills the vector table.
 *
 * Note that the forward declarations are weakly bound to the Unused_Handler.
 * This allows the linker to use that function for any interrupt handler that
 * hasn't been defined. To implement an interrupt handler, simply define a
 * function of the correct name in another file (e.g., void Reset_Handler())
 *
 * These interrupts are defined in RM0090, Section 9.1.3
 */

#define STM32F4XX_INTERRUPTS              \
  STM32_INTERRUPT(-3, Reset)              \
  STM32_INTERRUPT(-2, NMI)                \
  STM32_INTERRUPT(-1, HardFault)          \
  STM32_INTERRUPT( 0, MemManage)          \
  STM32_INTERRUPT( 1, BusFault)           \
  STM32_INTERRUPT( 2, UsageFault)         \
  STM32_INTERRUPT( 0, Reserved1)          \
  STM32_INTERRUPT( 0, Reserved2)          \
  STM32_INTERRUPT( 0, Reserved3)          \
  STM32_INTERRUPT( 0, Reserved4)          \
  STM32_INTERRUPT( 3, SVCall)             \
  STM32_INTERRUPT( 4, DebugMonitor)       \
  STM32_INTERRUPT( 0, Reserved5)          \
  STM32_INTERRUPT( 5, PendSV)             \
  STM32_INTERRUPT( 6, SysTick)            \
  STM32_INTERRUPT( 7, WWDG)               \
  STM32_INTERRUPT( 8, PVD)                \
  STM32_INTERRUPT( 9, TAMP_STAMP)         \
  STM32_INTERRUPT(10, RTC_WKUP)           \
  STM32_INTERRUPT(11, FLASH)              \
  STM32_INTERRUPT(12, RCC)                \
  STM32_INTERRUPT(13, EXTI0)              \
  STM32_INTERRUPT(14, EXTI1)              \
  STM32_INTERRUPT(15, EXTI2)              \
  STM32_INTERRUPT(16, EXTI3)              \
  STM32_INTERRUPT(17, EXTI4)              \
  STM32_INTERRUPT(18, DMA1_Stream0)       \
  STM32_INTERRUPT(19, DMA1_Stream1)       \
  STM32_INTERRUPT(20, DMA1_Stream2)       \
  STM32_INTERRUPT(21, DMA1_Stream3)       \
  STM32_INTERRUPT(22, DMA1_Stream4)       \
  STM32_INTERRUPT(23, DMA1_Stream5)       \
  STM32_INTERRUPT(24, DMA1_Stream6)       \
  STM32_INTERRUPT(26, ADC)                \
  STM32_INTERRUPT(27, CAN1_TX)            \
  STM32_INTERRUPT(28, CAN1_RX0)           \
  STM32_INTERRUPT(29, CAN1_RX1)           \
  STM32_INTERRUPT(30, CAN1_SCE)           \
  STM32_INTERRUPT(31, TIM1_BRK_TIM9)      \
  STM32_INTERRUPT(32, TIM1_UP_TIM10)      \
  STM32_INTERRUPT(33, TIM1_TRG_COM_TIM11) \
  STM32_INTERRUPT(34, TIM1_CC)            \
  STM32_INTERRUPT(35, TIM2)               \
  STM32_INTERRUPT(36, TIM3)               \
  STM32_INTERRUPT(37, TIM4)               \
  STM32_INTERRUPT(38, I2C1_EV)            \
  STM32_INTERRUPT(39, I2C1_ER)            \
  STM32_INTERRUPT(40, I2C2_EV)            \
  STM32_INTERRUPT(41, I2C2_ER)            \
  STM32_INTERRUPT(42, SPI1)               \
  STM32_INTERRUPT(43, SPI2)               \
  STM32_INTERRUPT(44, USART1)             \
  STM32_INTERRUPT(45, USART2)             \
  STM32_INTERRUPT(46, USART3)             \
  STM32_INTERRUPT(47, EXTI15_10)          \
  STM32_INTERRUPT(48, RTC_Alarm)          \
  STM32_INTERRUPT(49, OTG_FS_WKUP)        \
  STM32_INTERRUPT(50, TIM8_BRK_TIM12)     \
  STM32_INTERRUPT(51, TIM8_UP_TIM13)      \
  STM32_INTERRUPT(52, TIM8_TRG_COM_TIM14) \
  STM32_INTERRUPT(53, TIM8_CC)            \
  STM32_INTERRUPT(54, DMA1_Stream7)       \
  STM32_INTERRUPT(55, FSMC)               \
  STM32_INTERRUPT(56, SDIO)               \
  STM32_INTERRUPT(57, TIM5)               \
  STM32_INTERRUPT(58, SPI3)               \
  STM32_INTERRUPT(59, UART4)              \
  STM32_INTERRUPT(60, UART5)              \
  STM32_INTERRUPT(61, TIM6_DAC)           \
  STM32_INTERRUPT(62, TIM7)               \
  STM32_INTERRUPT(63, DMA2_Stream0)       \
  STM32_INTERRUPT(64, DMA2_Stream1)       \
  STM32_INTERRUPT(65, DMA2_Stream2)       \
  STM32_INTERRUPT(66, DMA2_Stream3)       \
  STM32_INTERRUPT(67, DMA2_Stream4)       \
  STM32_INTERRUPT(68, ETH)                \
  STM32_INTERRUPT(69, ETH_WKUP)           \
  STM32_INTERRUPT(70, CAN2_TX)            \
  STM32_INTERRUPT(71, CAN2_RX0)           \
  STM32_INTERRUPT(72, CAN2_RX1)           \
  STM32_INTERRUPT(73, CAN2_SCE)           \
  STM32_INTERRUPT(74, OTG_FS)             \
  STM32_INTERRUPT(75, DMA2_Stream5)       \
  STM32_INTERRUPT(76, DMA2_Stream6)       \
  STM32_INTERRUPT(77, DMA2_Stream7)       \
  STM32_INTERRUPT(78, USART6)             \
  STM32_INTERRUPT(79, I2C3_EV)            \
  STM32_INTERRUPT(80, I2C3_ER)            \
  STM32_INTERRUPT(81, OTG_HS_EP1_OUT)     \
  STM32_INTERRUPT(82, OTG_HS_EP1_IN)      \
  STM32_INTERRUPT(83, OTG_HS_WKUP)        \
  STM32_INTERRUPT(84, OTG_HS)             \
  STM32_INTERRUPT(85, DCMI)               \
  STM32_INTERRUPT(86, CRYP)               \
  STM32_INTERRUPT(87, HASH_RNG)           \
  STM32_INTERRUPT(88, FPU)                \

Here's how the table is actually defined:

cortex_handlers.cc:

Code: [Select]

#include "cortex_handlers.h"

// provided by the linker file
extern "C" unsigned long __stack_top__;

// To be called for an interrupt handler that isn't otherwise defined
// This is extern "C" because GCC's alias attribute can't deal with
// a mangled name.
extern "C" void Unused_Handler(void) {
  while (1);
}

#define STM32_INTERRUPT(prio,name) extern "C" void name ## _Handler(void) __attribute__ ((weak, alias("Unused_Handler")));
  STM32F4XX_INTERRUPTS
#undef STM32_INTERRUPT

// Expand the interrupt defnitions a second time to fill out the vector table
#define STM32_INTERRUPT(prio,name) name ## _Handler,
__attribute__ ((section(".vectors"), used))
void (*const cortex_interrupt_vectors[])() = {
  (void (*)(void)) &__stack_top__,
    STM32F4XX_INTERRUPTS
  };

#undef STM32_INTERRUPT


[CC58]

NXP makes toolchain easy.  LPCexpresso is based on GNU port by Code Red.  Get it here. Been a while since I used it, but is was super easy.  Much better than trying to cobble together stuff. 
http://www.lpcware.com/lpcxpresso/download

[andyturk]

NXP makes toolchain easy.  LPCexpresso is based on GNU port by Code Red.  Get it here. Been a while since I used it, but is was super easy.  Much better than trying to cobble together stuff. 
http://www.lpcware.com/lpcxpresso/download

Fine if you want a crippled GNU toolchain with a paid upgrade path for full functionality. 

Go here for the real deal.

As part of its ongoing commitment to maintaining and enhancing GCC compiler support for the ARM architecture, ARM is maintaining a GNU toolchain with a GCC source branch targeted at Embedded ARM Processors, namely Cortex-R/Cortex-M processor families, covering Cortex-R4, Cortex-R5, Cortex-M0, Cortex-M3, Cortex-M4, and Cortex-M0+. As part of this, ARM will, at regular intervals, release binaries pre-built and tested from the ARM embedded branch. The improvements will be freely available for integration into 3rd party toolchains, and for direct download by end-users.

[jakeypoo]

Andy, I'm totally on board with what you're preaching.

As for 8-bit micro replacement, I mean something that can replace your average ATmega or PIC16 device. That's just what a lot of people know, so you see them all over the place. For equal cost, Cortex-M seems to give you more memory, clock speed and peripherals.
The only place I could still see using an 8-bit is when you only need one of those 8 or 10 pin devices for some dead simple application. An ATiny or PIC10 still comes in cheaper than any cortex equivalents, and if it gets the job done...

Did you find any useful resources for building your own toolchain? I'm mostly using the CMSIS documentation and some app notes by Miro Samek.

[andersm]

Did you find any useful resources for building your own toolchain? I'm mostly using the CMSIS documentation and some app notes by Miro Samek.

See eg. crosstool-NG. There's also a ton of different build scripts floating around.

[SirNick]

Would just like to say:    Andy!

[andyturk]

Did you find any useful resources for building your own toolchain? I'm mostly using the CMSIS documentation and some app notes by Miro Samek.

Yeah, Miro has some nice examples for bare metal builds. I never really got my head around QP though.

Another good resource for this area is ChibiOS. Even if you don't want to use the RTOS itself, the distribution contains dozens of examples built with various toolchains. So if you're familiar with AVR you can look at the linker scripts and makefiles to see how he does it on a platform you know ("he" being Giovanni), and then use that to decipher a less familiar platform like ARM. Think of it as a sort of Rosetta Stone. Plus, Giovanni's code is very nice and worthy of study.

BTW, what do you mean by "building your own toolchain"? You shouldn't really need to compile GCC and the binutils, since launchpad.net has binary distributions ready to go. The only thing I've had to compile is openocd back when it was at a 0.5 or 0.6 release, and that was mostly due to my needing to run it on OS X. These days openocd seems much more stable (although I *do* still compile it from source).

Someday I'd like to try out Clang/LLVM, which should support ARM Cortex-M builds. Haven't gotten around to that yet, however.

[dannyf]

DS-5 is also just introduced (over the last 6 months). I have seen people experimenting with it but no personal experience.

One's choice of toolchains depends on many factors, some of them are highly personal. For example:

1) what are you using them for? If I make a living on the toolchains, I want reliability and good support. If I am just playing it for fun, I want something that's weird and interesting;

2) support for your chips;

3) support for your applications;

4) code base / examples.

...

[jakeypoo]

Another good resource for this area is ChibiOS.
...
BTW, what do you mean by "building your own toolchain"?
...

The ChibiOS stuff looks great. Thanks.

I just meant putting together all your development/debug tools. Not nessecairly compiling them. I'm a fan of "do one thing well" command line tools over something like eclipse and it's integrated tools. It takes some time and looking around at other people's tools before you get your own debug tools and template files set up so that you don't have to re-learn everything once you start a new project.

[AndyC_772]

I still use PICs for a good many projects because they run from 5V and have a good range of analogue peripherals integrated. If you need something with a 0-5V analogue output and a built-in op-amp or two, you could do a lot worse.

I totally agree that in terms of price/performance, or even on price alone, some of the ARM based devices look dramatically better than any 8 bit parts.

I first started looking at them seriously about a year ago, and wasted a lot of time on CoIDE (buggy, poor device support, even worse tech support), and even more time trying to install and get 'straight' Eclipse to compile and download code. Manufacturers' own free tools inevitably are limited to only that manufacturer's parts and have code size limitations that are easily used up by peripheral libs or lookup tables.

I ended up with CrossWorks, which with hindsight is what I should have simply bought on day one an saved myself a lot of hassle. It has excellent device support across a wide range of manufacturers, it 'just worked' out of the box when I came to compile, download and run my first project, and its price has been recently cut too. It's US$1500 for commercial use - unquestionably a better use of the money than several days wasted on free software IMHO - and for non-commercial hobby use it's just $150. For that amount it's a no-brainer.

[andyturk]

I just meant putting together all your development/debug tools. Not nessecairly compiling them. I'm a fan of "do one thing well" command line tools over something like eclipse and it's integrated tools. It takes some time and looking around at other people's tools before you get your own debug tools and template files set up so that you don't have to re-learn everything once you start a new project.

My bag of tricks is made up from:

• Launchpad.net's GNU tools for compiling
• GNU Make
• Openocd for flashing and debugging
• SEGGER J-Link for SWD/JTAG
• ST-LINK/V2 for SWD/JTAG on STM32
• GNU Emacs for cutting code
• git for source control
• Google Test for unit testing
• and OS X to run it all on

The least defensible tool in the list is Emacs, but it's also the one I'm most attached to. Been using it for more than 30 years. I swear, the nerve impulses for typing obscure commands like esc-minus-1-ctrl-x-o never make it to my head and are handled somewhere in the elbow region. Sorry. 

Modern mcu development environments always seem to come packaged with some kind of IDE. Aside from getting in the way of my emacs addiction, the other thing I don't like about IDEs is that the build systems tend to be non-searchable. E.g., I know I want to turn on -O3 optimization, but figuring out which dialog to open, and which nested list of little triangle thingies to drill into to is entirely non-obvious. If you look at the documentation for these things, they're filled with pages upon pages of screen shots interspersed with "click this", "press Continue", etc. Very annoying! I'll admit emacs is worse, but at least you only have to learn it once. Every new IDE is a fresh helping of GUI pain. 

In contrast, you can open up a Makefile in your text editor and search for stuff. Plus, with a little bit of effort your Makefiles will run equally well on Windows/Linux/OS X without modification. You can even bury setup commands for your debug probe and gdb inside a Makefile, so it becomes the first place to look at for configuration information. Here's an example. In most of my repos (but not that last one), "make flashit" compiles, links, and programs the mcu assuming the hardware bits are plugged in. Fortunately, all of the hardware/firmware teams I've worked with have been open to using Makefiles, and all the IDEs I've touched are able to run Make directly.

[jakeypoo]

vim, source files and datasheets is all I need.

It's good to know I'm not crazy (or maybe we're both crazy, but at least not alone) in not using any IDEs. 

[bingo600]

+1 for the launchpad arm-gcc

I'm using linux and:

launchpad arm-gcc
code::blocks (but only external makefiles) , no clicky..clicky setup.
segger, st , blackmagic or versaloon debuggers w. oocd.

/Bingo

[andyturk]

segger, st , blackmagic or versaloon debuggers w. oocd.

How well does blackmagic work in practice? I always thought it was a fascinating idea: put the gdb protocol handler in the JTAG/SWD hardware.

[bwat]

vim, source files and datasheets is all I need.

It's good to know I'm not crazy (or maybe we're both crazy, but at least not alone) in not using any IDEs.

The only time you'll find me using a graphical IDE is if I'm messing around with Smalltalk (and that's not often). Otherwise, I'm all Emacs. My revision control is exclusively git.

[dannyf]

vim, source files and datasheets is all I need.

Really? How do the source files turn to the binary? Automagically?

As to vim, you guys are just whim, unless you can one day code in binary directly. Or at least code over a punch hole tape machine.

maybe we're both crazy... in not using any IDEs.

That's more like it,

I tend to think that you see IDEs in wide spread use today for a (good) reason.

[bwat]

I tend to think that you see IDEs in wide spread use today for a (good) reason.

What is that good reason?

[andyturk]

I tend to think that you see IDEs in wide spread use today for a (good) reason.

Yep. An IDE is a chip vendor's way to convince all the bored, lazy, least-qualified, can't-code-their-way-out-of-a-paper-bag "engineers" to use that vendor's products.

 

[SirNick]

I don't get how any coder can install an IDE and blindly accept whatever is going on behind the "Send to dev board" button.  I feel like I don't understand the thing at all until I know how to compile and upload as distinct steps.  This has already been argued a few times even since I got here though.  Seems like people would more willingly trade in their daily driver for a different car than change development environments.  Me too.

[dannyf]

accept whatever is going on behind the "Send to dev board" button.

The same way you rely on unfamiliar devices / things to run far more important things for you: not all of us have a clue of how the monetary systems work, yet we use paper money; not all of us have a clue of how the banking systems work, yet we put our money in the banks, trade over them and let them hold our securities for us; not all of us have a clue of how a car works, yet we drive our loved ones in them; ...

To insist on using only things you understand is to limit your life to a primitive state.

[dannyf]

What is that good reason?

Efficiency, productivity, team work, ....