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

[Markus Hitter]

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/