They are mostly planning to fix this with more hardware it looks like. Dynamic memory creates possible performance problems, while static can create security problems when written for performance. That being said using static and encapsulation can go a long way, even in C. The issue with embedded is you do not have enough memory for stuff like decent size memory blocks or paging. If you just need a chunk of memory and don't plan on freeing it often malloc() is perfectly fine. To avoid fragmentation you can allocate the chunk of memory you need once and then use something like a slab allocator on top which is way faster for frequent allocations.

I have seen others make this mistake before and everyone switched to malloc() in the end. You will lose track of what goes where and how much space is left.

Manually managing memory is the worst you can do. Plan out your memory usage at the beginning and use unions or structures to share memory when you can. Early embedded development systems with their own compilers rarely implemented this function to stop people even trying to use it. But the key thing to me is it really needs a memory management unit and garbage collection process, and embedded processors don't tend to have these.

Lots of arguments why not to use it in embedded if you google for them, and I've never seen a convincing counter-argument. At the risk of starting a range war, the Pico is an embedded processor and one shouldn't use malloc() in embedded systems.

Track memory usage linux