Am 02.11.2014 um 18:08 schrieb Erik Walthinsen: > 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.
Thanks, Erik, you managed to explain this much better than me. > 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. Maybe I expose my lack of knowledge here, but what is the point of running off RAM? Chips I used so far are pretty sparse on RAM, so one couldn't do there much, anyways. Would it be an option to simply ignore these paths in gcc, letting the user deal with such rare(?) setups? If one really needs this, one can always copy into RAM per user code and jump to it, of course. One thing I couldn't find a reason for so far, is this insisting on user code before main(), usually named SytemInit(). I think if there is any code before main() It should be vector tables only, nothing which might change behaviour. For example, it should be entirely fine to setup the PLL clock in main(). It looks like Terry Guo, apparently ARM-employed arm-gcc maintainer, could be a bit more enthusiastic about hardware support in this toolchain: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1387906 Nevertheless, we're three interested parties now, so it makes sense to do some work. I think it might be a good idea to start with getting -mmcu into gcc. First step would be to provide built in #defines for each variant, like __LPC1114__, __STM32F405__ and so on. This would already allow to distinguish between different HAL variants and such stuff in user code. Could also be done with a user supplied -D, of course, but having this in gcc means people can rely on it, code using this becomes compatible, chances that every hacker uses a slightly different variant becomes low. Next step could be to let gcc choose its linker script on its own. At this point, I think, we had most of what programmers experience as "odd" solved already. Third step could be to provide these vector tables. And so on ... good plan? Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
