4 ms·
That's right - some "safe" coding standards like MISRA C go as far as forbidding use of malloc() without explicit justification. If you still need dynamic allo
by edwinbalani 5y ago
That's right - some "safe" coding standards like MISRA C go as far as forbidding use of malloc() without explicit justification.
If you still need dynamic allocation, you might choose to have a custom allocator working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed).
- edwinbalani 5y ago(All that said, embedded systems sometimes don't have virtual memory, so the original problem stated in the link is just not a thing...) > working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed) And I should add to this that you probably want to access all of the pool/arena to do setup, or just ensure it's physically allocated if you are running in a virtual memory space. This is something that is reasonable at setup time, though.
- SV_BubbleTime 5y agoAll good stuff. I’m working on a project now and trying my best to make it MISRA compatible because FreeRTOS did the same. You don’t use malloc() but rather pvPortMalloc() which pulls from an already allocated pool. Their HEAP4 system tries to keep the chunks organized. So far I’ve been very happy with it.