Re: More useful support for low-end ARM architecture

[Joey Ye <joey dot ye dot cc at gmail dot com>]

Markus,

-mmcu probably will not work for ARM architectured MCUs. Reason are
* Confusion. -mcpu is encouraged and already widely used for ARM
architectures. Introducing -mmcu will be very confusing.
* Expensive effort. Either supporting none, or supporting all. There
are large number of MCUs from ARM eco-system partners. Supporting all
of them is a large project.
* Maintance nightmare. Having GCC developers to input and maintain
vendor specific configurations is inefficient and error-prone.
* Failed schedule dependence. Having -mmcu actually means whenever
there is a new MCU introduced into market, GCC has to be updated to
describe it. Given GCC's release cycle (once per year) and the
frequency of MCU release (could be tens each year), GCC will never be
able to catch up.

Further more all the board/MCU specific configurations are already
described in CMSIS and variant of GUI based toolchain for ARM MCU.
Replicating then in GCC does not sounds a right thing to do for me.

From the link you shared I also noticed some other discussion
regarding makefile, libraries and other options, which are very
interesting but off scope of GCC mail list. Shall we please continue
the discuss at https://answers.launchpad.net/gcc-arm-embedded/+question/257326
?

Thanks,
Joey

On Sun, Nov 9, 2014 at 3:42 AM, Markus Hitter <mah@jump-ing.de> wrote:
> 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
>
> --
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. (FH) Markus Hitter
> http://www.jump-ing.de/