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

[Ambroz Bizjak]

Hi Markus,

I'm confused. The arm-gcc-embedded toolchain does come with a libc, a
version of newlib. In fact they also ship a stripped down version
(nano newlib), which can be enabled by linking with
"--specs=nano.specs". It's not as straight-forward to use this libc as
avr-libc, since a few platform-specific things still need to be
defined to make it work, but it's easy enough.

I use this in my APrinter firmware [1], for different platforms:
AT91SAM3X83 (Arduino Due), AT91SAM3U4E (4pi board), Teensy3. For each
platform I rely on a third-party package for the chip-specific things
(in particular ASF, and teensy-cores for the Teensy3). But this is
used in conjunction with the newlib which is part of the
arm-gcc-embedded toolchain.

You can look into the APrinter code to see how I set this up. The
"basic" platform-specific code (to get the chip to boot) is in the
aprinter/platform/ folder, while the HALs (e.g. timers, ADC) are in
the aprinter/system/ directory. Actually I'm wondering if you're
really interested in a HAL as opposed to a pure libc.
Regarding setting up the build environment, I provide Nix expressions,
which means you don't need to fiddle with anything, everything that is
needed is automatically downloaded. As long as you're on Linux and
have the Nix package manager installed.

Best regards,
Ambroz

[1] https://github.com/ambrop72/aprinter

On Sun, Nov 2, 2014 at 5:25 AM, Dave Hylands <address@hidden> wrote:
> 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
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avr-libc-dev