Dynamic memory allocation on embedded systems

[nctnico]

A linked list is just a way to store information. Still if you free a byte at one address and one at a completely different address, you still don't have two adjacent bytes in the end.

You don't release bytes but entire blocks. And in a linked list the order in which information is stored can be completely non-sequential when you look at the memory locations. The API hides that.

"ignoring input" is obviously a no-go for any kind of system.

Why? Dynamic memory allocation implies that running out of memory is a valid operating condition which has consequences just like a coffee machine running out of coffee beans.

[0xdeadbeef]

I guess your world of embedded programming and mine are miles apart. For me, an embedded system has hard real-time requirements.
Then again, nowadays people call some full fledged Linux system embedded just because it's running on an Arm and fits in a small case.
Without real-time requirements, a lot of RAM, no safety concerns and the freedom to ignore input events as you like, dynamic RAM allocation is no problem of course.
For the type of embedded systems I'm concerned with, it is though.

[nctnico]

I'm just saying that whether or not you can ignore inputs depends entirely on the design constraints. There is no general rule which says an embedded system can never ignore an input. In the past I have made interfaces for coffee machines. If the interface couldn't empty it's data buffer to the host it would make the coffee machine stop.

Besides that you can also do hard realtime applications with embedded Linux. One of my recent projects involves a low latency 60fps video player based on an embedded ARM system + Linux. It really can't do something else for a while.

[0xdeadbeef]

Well, dropping a frame is one thing. Ripping away a cylinder head another.

[grumpydoc]

The problem comes however with creating application specific functions. For example, when accessing the SD card, I've implemented a text reading application (opens file < max size, reads data into buffer, displays data on the screen with the ability to scroll through), so I think the best thing to do here would be to read in a constant buffer then request more data as required I suppose, for files less than the buffer size however, I would've liked to allocate less data than a constant buffer as there will always be other applications running in the background, for example monitoring the data stream from the GSM modem.

Allocate a buffer equal to the size you can display and fill it as appropriate from the file as the user scrolls through, no need for dynamic allocation (OK grab a block at start up and just hold on to it but that barely counts). Chances are the buffer will be faiely small so not much need to worry about he impact on other "applications"

It sounds like you have already decided on this approach for that particular function.

[nctnico]

Well, dropping a frame is one thing. Ripping away a cylinder head another.

And oddly enough the cost of the latter could be less than the first