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