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

Oguz Kaan Ocal <[email protected]> wrote:
> 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?
> 
> 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.

That is pretty much the reason why I don't use a standard library
on resource-constrained systems: it eats up too much memory.

However, if I need something like a printf, I'm certainly not
going to write it myself, but depending on how much resources
there are I'd go for one of the reduced-functionality versions
that have a lower memory footprint than the full-blown libc one.

I would also not write my own cryptographic functions usually,
but reach for an existing library.

> Does anyone here still use the full standard library on chips with <32KB 
> Flash? Or is it an immediate "no-go" for you?

Full library? Not likely. Just the initialisation code alone
would weigh heavily on such a low-memory system.

> 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?

This depends on how performance-critical the loop is and what
the alignment requirements are. Using a tried-and-true memcpy
from a standard library means you don't have to think about
all those pesky corner-cases.

> 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?

I tend to use static allocation, more predictable and usually there 
is no need for dynamic allocation in the context where I'd be using
such a resource-constrained system.

> 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.

Not sure how it is cheating. If it fits and solves your problem, use
it. 

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

I don't have a hard and fast answer for that. It really depends on
what the requirements and context are.

Cheers,

Koen

-- 
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/