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

[Senthil Kumar Selvaraj]

On Sun, Nov 02, 2014 at 09:08:12AM -0800, Erik Walthinsen wrote:
> 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

GCC has a way to do the device specific stuff (macro definitions,
include paths, crt selection, linker script selection) externally via
spec files - it doesn't have to go into GCC itself. The AVR port now
does it this way (thanks to Joern).

Of course, somebody needs to write the spec files :)

> 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 ;-(
> 
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avr-libc-dev