Cannot aloocate memory using malloc

"Malloc is useful in a PC or general purpose computing environment when you don't know how much RAM the system might contain."

I'd rephrase that as 'Malloc is useful when you know that the PC (etc) contains substantially more memory than you're going to try and use'. In many situations the only reasonable thing one can do if malloc fails is to terminate the program, which is usually not a very reasonable thing to do from the user's perspective.

"In the case of embedded systems, however, you typically know the total amount of RAM as well as how much of that RAM you can afford to devote to storing your data."

Absolutely.

"What I'm saying is: Just make a static variable of a size appropriate to hold the maximum dataset you'll need to work with."

Or, if the program storage requirements allow it, try to use local variables so the compiler can overlay the data. Then you have a sort of compile time 'safe' malloc.

It's all a bit like using an OS on an 8051 based system - there are probably some types of project where this is a reasonable thing to do, it's just that I can't think of one.

"Malloc is useful in a PC or general purpose computing environment when you don't know how much RAM the system might contain."

I'd rephrase that as 'Malloc is useful when you know that the PC (etc) contains substantially more memory than you're going to try and use'. In many situations the only reasonable thing one can do if malloc fails is to terminate the program, which is usually not a very reasonable thing to do from the user's perspective.

"In the case of embedded systems, however, you typically know the total amount of RAM as well as how much of that RAM you can afford to devote to storing your data."

Absolutely.

"What I'm saying is: Just make a static variable of a size appropriate to hold the maximum dataset you'll need to work with."

Or, if the program storage requirements allow it, try to use local variables so the compiler can overlay the data. Then you have a sort of compile time 'safe' malloc.

It's all a bit like using an OS on an 8051 based system - there are probably some types of project where this is a reasonable thing to do, it's just that I can't think of one.

In the case of embedded systems, however, you typically know the total amount of RAM as well as how much of that RAM you can afford to devote to storing your data.

I'd add that in addition embedded systems generally need to guarantee operation for certain specs. You can't just throw up an "out of memory" dialog box and quit back to the OS if you run out. You have to plan ahead of time and be sure that you will be able to allocate N foos simultaneously with M bars at run time.

When malloc (and the like) does show up, it's generally part of some sort of base configuration code. Perhaps a system can support up to 32 foos, or 64 bars, or some combination where every foo costs you 2 bars, and the user can select that tradeoff. In that case, I might allocate a pool of foos and a pool of bars out of a shared memory area. I might even use malloc, though its overhead is generally unnecessary in this case, since the memory will never be freed (until the system is reconfigured).

I commonly have code that dynamically allocates one item out of a table devoted to storing those things, but that's not the same as dynamic allocation from a generic shared, variable-sized memory heap, which brings lots of performance, fragmentation, and correctness questions, without adding much value.

simply:
take that PC hat off and put a '51 hat on.

Do not go by the urban legend "If you can do C, you can do any processor"

Erik