A guide to getting started with embedded systems

Re:A guide to getting started with embedded systems by tines on Friday May 13, 2022 @10:37AM (#31368226)

A couple of reasons, both to do with the fact that data memory is scarce on embedded systems. One is that it has high memory overhead (every entry includes a pointer), two is that making many small allocations can cause memory fragmentation, especially with the kinds of allocators commonly used in embedded systems.

Also if time is scarce, following pointers is slower than calculating offsets, but that's usually not an issue worth thinking about.

[ Parent | on HN ]

Re:A guide to getting started with embedded systems by shirleyquirk on Friday May 13, 2022 @11:04AM (#31368579)

Oh ok. Counterpoint: allocating a single node if memory is already fragmented will succeed where growing a vector would fail. But I suppose the point of the question is being able to discuss the issues involved.

[ Parent | on HN ]

Re:A guide to getting started with embedded systems by hwillis on Friday May 13, 2022 @03:37PM (#31371738)

You don't have to worry about dozens of other applications fragmenting your memory. You keep your threads neat and your memory neat, and you don't have to worry about failed allocations.

Another reason to keep memory contiguous is that fragmentation can be much more punishing (sometimes), especially when latency is important. On large devices it doesn't matter much if you're under-utilizing the CPU while waiting for RAM, because the OS will do other things and then let you do a lot of work all at once. Embedded processors will have nothing else to do.

[ Parent | on HN ]

Re:A guide to getting started with embedded systems by nicoburns on Friday May 13, 2022 @02:48PM (#31371197)

I feel like in many embedded systems you'd use a fix sized vector/buffer rather than a growable one.

[ Parent | on HN ]