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