Re: Bare Metal C vs. libc: Is the overhead worth it on small MCUs?

Oguz Kaan Ocal <[email protected]> writes:

> Hey guys,
>
> I've been debating this with myself for a while now. When you're working on
> resource-constrained hardware, do you guys actually use the standard C library
> (libc) or do you go full Bare Metal for everything?


the parallax propeller uses gcc compiler with different memory types. It
uses a brief libc.


> I'm talking about things like using sprintf() vs. writing your own itoa(), or
> malloc() vs. static buffers. Even a simple printf() can bloat the binary by
> several KB and eat up the stack like crazy.
>
> A few things I'm curious about:
>
> Does anyone here still use the full standard library on chips with <32KB
> Flash? Or is it an immediate "no-go" for you?

avr gcc. this is for atmega devices. the software seems to always fit
the sram.

> For string manipulation (memcpy, memset, etc.), do you trust the compiler's
> built-in optimizations or do you write your own assembly/manual loops to save
> those extra cycles?

that depends on the platform. not all languages like inline assembler -
this is usually my problem. compiling into a static library from C is
usually easier for me.

> How do you handle things like dynamic memory? Is malloc() ever acceptable in a
> mission-critical embedded loop, or is it always static allocation only?

best advice is to use the stack and set it in main () or alloc. I would
use alloc. be careful though.

> I feel like using the standard library is "cheating" and adds too much hidden
> overhead, but rewriting every basic utility feels like reinventing the wheel.

gcc is very good at compiling C especially for atmega devices.

> What's your take? Do you prefer the portability of standard C or the
> lean-and-mean performance of custom bare-metal implementations?

I find that assembler is useful if you are a good programmer; usually it
is better you change your algorith in C. Programming in C is _much_
faster than assembler.