
Tracking Firmware Code Size - fra
https://interrupt.memfault.com/blog/code-size-deltas
======
tyhoff
OP here. I've worked at two embedded software shops, and every time we are
working on a new product and cramming to get it shipped, we run out of code
space. Each of those times, PR's stay open for 2-3 weeks waiting to be merged
until engineers can work their magic and reduce the size.

I've even seen instances where deals take place. We'll clean up our module
today and you can merge your 1k feature, but we'll need 1k in 2 weeks and you
need to find it for us by then.

Software engineers usually laugh when I tell them about my struggles with code
space and memory. I do enjoy it though.

~~~
davismwfl
Right there with you. I've dealt with the dreaded overflowed by XX bytes
message more then I'd like to remember.

I've also run into the issue where you tell the business hey, this isn't going
to reach QA for another 2-3 weeks now. And when you explain the details that
we are 20 bytes over memory (etc) and need to make space they think of it like
removing some characters in a sentence on a word document, not understanding
it might take reorganizing an entire module or 2 or rewriting entire state
machines or whatever it takes.

And yea, the deals thing is funny cause it seems to happen in every embedded
system where multiple people are involved on the project.

I'll laugh with you but not at you. It is a blast to do embedded work

~~~
tyhoff
> they think of it like removing some characters in a sentence on a word
> document

Too real. In the past, the way we usually went about saving space when we
needed it was removing small animations, shortening log messages (eventually
encoding/hashing them), compressing icons that were stored in the firmware,
and ensuring large functions don't get inlined.

LTO was also an option, but wow, does it slow down build times and make the
development cycle a pain.

