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