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

[Markus Hitter]

Hello everybody,

while I hacked ATmegas and ATtinys using avr-libc for a number of years now, 
I'm new to this list. BTW., thanks for all the great work!

The reason I joined is, around a few corners, our ATmega performance is pretty 
much maxed out. Optimized to waste not a single clock cycle, still we need more 
performance. Accordingly, our community (RepRap) has started to move to 32-bit 
ARM MCUs.[1] An ARM Cortex-M0 is quite similar to an ATmega, but it processes 
32-bit integers in a single clock cycle and we do 32-bit integer math a lot.

Avr-libc was always a great help, but sadly, there is no _arm_-libc. There's a 
gcc toolchain (arm-gcc-none-eabi), but this toolchain makes no efforts to 
produce code which runs on actual hardware.

There is CMSIS, which does a few steps in this direction, but it takes care of 
the core, only. No UART, no digital I/O, no nothing.

There's also MBED, based on CMSIS, which has much of the functionality of what 
an arm-libc would do. But MBED apparently pretty much insists on being 
(Web-)IDE-only and their IDE wants to be ARM-only. Not good for code bases 
which run on AVR, too.

Why do I write here, risking to be flamed off the list for praising ARM on an 
AVR list?

Well, I can imagine very well many hackers on this list are in a similar 
situation, because even Atmel has started to move towards ARM.

Another one is, while avr-libc is apparently written with performance and small 
Flash sizes in mind, MBED very apparently has no such goals. Today I looked at 
setting up an UART port. Code is there and works, but wohow, it chimes in at a 
whopping 880 bytes just to set these 3 or 4 registers (ARM UART is quite 
similar to AVR UART). That's quite a lot for an MCU which comes with 32 kB 
Flash only. Putting together to a simple Hello World firmware, I was at 5880 
bytes already.

Looking at MBED at lower levels, possible performance improvements were more 
than apparent. Not because MBED developers are incapable somehow, but because 
they apparently more than happily trade performance and size for abstraction. 
That's the way I'd write code for a desktop PC, but not for a tiny embedded MCU.


The question now is, that's the reason I'm writing: Is there interest in 
creating something similar to avr-libc, but for ARM MCUs?

Target of arm-libc could be Cortex-M0 to Cortex-M4 in all their flavours (there 
are many), focus on size, focus on performance, making a Makefile based 
workflow possible (which doesn't rule out using IDEs, of course) and similar 
goals.

What do you think?


Thanks for your opinions,
Markus


[1] Yes, I'm aware of PICs and Propellers and Xmegas and a few more. Nice 
chips, but it's pointless to write a firmware for hardware which doesn't exist 
in our community.
-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/