There is https://github.com/mbedmicro/mbed for the offline version of mbed.
I think its important to distinguish the functionality that is part of avr-libc, which is just the C-runtime and as far a I'm aware doesn't include functionality liike UART. Perhaps you're thinking of avrlib? http://www.procyonengineering.com/embedded/avr/avrlib/ Dave Hylands On Sat, Nov 1, 2014 at 6:58 PM, Markus Hitter <m...@jump-ing.de> wrote: > 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 > -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
