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

[Dave Hylands]

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 <address@hidden> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>



-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com