As Georg-Johann Lay wrote: > They just add startup code, perhaps a linker script to describe > memory on their boards and compile for their architecture.
Still, if it's not the IDE that does it on their behalf, most of those professional ARM developers are hosed. They solely rely on their (often payware, like CodeSourcery) IDE to do it for them. If the IDE doesn't do it, they are standing in about the same rain as an AVR developer whose device is not supported by the toolchain. The AVR approach is somewhat more user-friendly, in that you can add a single -mmcu option, and then compile your sources the same simple way as you would e.g. be able to compile code for your host computer. Technically, the way you describe would still be possible even with today's AVR-GCC and binutils: just use the appropriate -mmcu=avrXXX option describing the CPU core / overall architecture, use your appropriate linker options (for SRAM start etc.) or linker script, supply your own IO header file. Minus a few things in avr-libc (like power management or EEPROM support), this would work. Right now. Nobody does it that way. I'd be more than happy if we could agree on the location and format of a single external file that combines those one-liner patches you mention, is read in by both binutils and GCC at *run-time* (so no recompilation is needed), and would be used as a base for the remaining decisions (possibly with a fallback to some compiled-in device list if the file is not present). However, that's not the way the GNU tools would currently work. And no, the GCC specs file wasn't really an alternative: first, it would not work for binutils anyway. Then, it's got an incomprehensible syntax (even for seasoned developers), and changes were needed in many places to add a single device. In order to be really able to offload new device support to the end user, it has to be a one-liner (or perhaps, a one-record addition, like to an XML file), and it must be possible to do this at run-time, without recompilation. For avr-libc, this would be even harder though, as some of the device support is really compiled in right now. But I think if the other tools agreed on such a central device definition file, we could start an effort to generalize avr-libc as well (perhaps accompanied by a script that recreates some of the device-dependant header files from a template file, based on those device definitions). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
