Re: [avr-libc-dev] Is there interest in an arm-libc?

[Erik Walthinsen]

On 11/02/2014 03:52 AM, Markus Hitter wrote:
> You see? Lots of additional complexity, no less than four third party packages 
> plus gcc plus half baked libc to support just three chips (of about 50 
> available) on a single build host. Stuff which every developer has to learn, 
> has to adjust to his own project, has to be made working on all hosting 
> platforms (Linux, OS X, Windows, etc.). Not so much a problem for 
> single-developer projects like APrinter, but collaborative development becomes 
> almost impossible, because adjusting to one platform almost ineviteably breaks 
> another, so the maintainers are left with the integration part, which is 
> currently more work than the port its self.
>
> Excellent target for a combined, collaborative effort, IMHO. Time should be 
> spent on writing unique code, not on reinventing the wheel.

I am absolutely interested in working on such a project as time allows, 
since it's been on my TODO list for several years now.

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, in that it brings in all the register 
definitions and other bits for whatever processor you're on.  The fact 
that pretty much every ARM manufacturer uses a different style (CMSIS 
notwithstanding), and some of them even have several incompatible 
headers floating around, makes starting up an ARM project rather.... 
annoying.

To solve it on ARM I would advocate sucking all those headers into 
something like the Atmel XML, then dumping them all back out in a sane 
common format.

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

The biggest challenge (besides pushing this into GCC...) will be dealing 
with the fact that linker scripts are significantly more varied in the 
range of ARM chips.  You can link to run straight from RAM (e.g. in 
gdb), run straight from Flash, or in many cases you have to link it to 
Flash but the chip copies it all to RAM before executing.  Many ARM 
chips have multiple RAM blocks that are *not* (for no reason I can 
comprehend) contiguous, and there needs to be some way to specify what 
to do with those.

Right now I'm struggling on a project that's currently running an 
LPC1549 and is coded (by someone else) for in LPCxpresso, but is 
hopefully transitioning to an STM32F405.  I want to ditch the lame 
manufacturer IDEs and go bare-metal, but just finding a complete working 
example is hard enough ;-(