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?
>
> 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?
>
> 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?
>
> 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 feel like using the standard library is
> "cheating" and adds too much hidden overhead, but
> rewriting every basic utility feels like
> reinventing the wheel.
>
> What's your take? Do you prefer the portability of
> standard C or the lean-and-mean performance of
> custom bare-metal implementations?

        I usually  use static  buffers only.   It is
  extremely rare  to have a use-case  that is really
  unbounded.  Even then, it's better to bound it for
  reliability anyway.  I  leave optimizations to the
  compiler usually, but keep an eye on the generated
  assembly, just in case.  If something is critical,
  or the generated code is bad, I might drop down to
  assembly, but that is rare for me nowadays.

        As for standard libraries,  I steer clear of
  them usually.  But, if  I'm feeling lazy, and need
  some small utility, I  may copy-paste the relevant
  code from musl libc into my own project.  Musl has
  simple readable code in most places I looked.  One
  other place to look, albeit usually less "pretty",
  is the gnulib project.  Lots of code to copy-paste
  if you don't feel like writing it.

        Other than that, as  you work over time, you
  develop  more and  more of  your own  utilities; a
  library of  your own.  It becomes  less tedious to
  go  bare-metal.  Unless  your employer  takes full
  ownership of it and prevents you from reusing your
  own work, I try my  best to not corner myself into
  such arrangements.

        Oh, and by the way, there's no "Cheating" in
  software engineering; use  your judgment to choose
  tools that help you solve a specific problem.  Did
  you solve the problem?  Good.  If not, then change
  your approach.  If you  hit your goals, within the
  resource limits  you have,  and did not  break the
  law, then no god of engineering is morally judging
  you based on what you used :)


Best Wishes,
Lumin Etherlight