More useful support for low-end ARM architecture (migrating from GCC mail list)

Migrating discussion from GCC mail list https://gcc.gnu.org/ml/gcc/2014-11/msg00105.html

From Markus Hitter <email address hidden> via gcc.gnu.org
Hello gcc folks,

recently I started to expand a project of mine running mainly on AVR ATmega to low end ARM chips. To my enlightment, gcc supports these thingies already. To my disappointment, this support is pretty complicated. One faces at least a much steeper learning curve that on AVR. Accordingly I suggested on the avr-libc mailing list to do similar work for ARM, Cortex-M0 to Cortex-M4. At least four people expressed interest, it looks like arm-libc is about to be born.

To those not knowing what this is, I talk here about all-in-one CPUs (MCUs) with memory and some peripherals already on the chip. Program memory can be as low as 8 kB, RAM as low as 1 kB. Usually they're programmed bare-metal, this is, without any operating system.

If you want to take a look at a simple Hello World application, here is one:

https://bugs.launchpad.net/gcc-arm-embedded/+bug/1387906

Looking at its Makefile, it requires quite a number of flags, among them nine -I with custom paths, --specs, -T and also auto-generated C files. Lots of stuff average programmers probably don't even know it exists. One of the interested persons on the avr-libc mailing list explained what's missing, much better than I could:

> I think what the other responders missed is that avr-libc (via its
> integration with binutils and gcc) gives you two key pieces of
> functionality:
>
> -mmcu=atmega88
> #include <avr/io.h>
>
> You *also* get classic libc functionality (printf, etc) that's provided
> on ARM by newlib etc, but that's not the big deal IMO.
>
> The #include is *relatively* easy, [... no topic for gcc ...]
>
> The -mmcu= functionality is even more deeply useful, although less
> easily repeatable on ARM. It brings in the relevant linker script,
> startup code, vector tables, and all the other infrastructure. *THAT*
> is what makes it possible to write a program like:
>
> #include <avr/io.h>
> int main() {
> DDRD = 0x01;PORTD = 0x01;
> }
>
> # avr-gcc -mmcu=atmega88 -o test test.c
> # avrdude....
>
> Writing a program for your random ARM chip requires digging *deeply*
> into the various websites or IDEs of the manufacturer, trying to find
> the right files (the filenames alone of which vary in strange ways),
> probably determining the right way to alter them because the only
> example you found was for a different chip in the same line, and then
> hoping you've got everything glued together properly.
>
> I want to be able to write the above program (modified for the right
> GPIO) and run:
>
> # arm-none-eabi-gcc -mmcu=stm32f405 -o test test.c

This is why I joined here, we'd like to get -mmcu for all the ARM flavours. It should pick up a linker script which works in most cases on its own. It should also bring in startup code, so code writers don't have to mess with stuff happening before main(). And not to forget, pre-set #defines like __ARM_LPC1114__, __ARM_STM32F405__, etc.

- How would we proceed in general?

- Many flavours at once, or better start with one or two, adding more when these work?

- Did AVR support make things we should not repeat?

Thanks for discussing,

Markus

P.S.: arm-libc discussion so far can be followed here:
http://lists.nongnu.org/archive/html/avr-libc-dev/2014-11/threads.html