1
\$\begingroup\$

I am working with the STM32F7 MCU in a project where I need to compute and create a LUT with the values of a signal which I will finally send to the DAC.

The problem with the LUT is that the size will be known only at run-time because it depends on some parameters sent to the MCU from a PC. I was searching info about how to implement that in C and the answer seems to be always the same: malloc().

I also read that malloc() is not a good way to allocate memory when working with embedded systems so I am wondering whether is there any way to implement such functionality in C not using malloc() (initialize an array using a variable calculated at run-time).

\$\endgroup\$
1
  • \$\begingroup\$ malloc is for allocating large blocks of memory, malloc has been hand optimized for decades and your probably not going to do better than it. Use malloc. If you need speed then just allocate space not at run time. \$\endgroup\$
    – Voltage Spike ♦
    Mar 25, 2017 at 5:30

2 Answers 2

Reset to default
4
\$\begingroup\$

The problem is not in using malloc() itself, the problem is with allocating and freeing memory chunks of arbitrary size repeatedly. If you only perform the allocation once and never free the block without restarting the device then you won't run into this problem.

\$\endgroup\$
12
  • \$\begingroup\$ If you only perform the allocation once you may as well use a predefined array. \$\endgroup\$
    – David
    Mar 26, 2017 at 21:40
  • \$\begingroup\$ The problem is actually malloc itself. Because in order to use malloc, you must have a heap that is at least as large as the worst-case largest size of the table. Therefore malloc can never be used to save space here. It can be used to waste space though, in case the heap size ends up larger that necessary for the worst case. \$\endgroup\$
    – Lundin
    Apr 4, 2017 at 12:48
  • \$\begingroup\$ @Lundin if you have a single malloc for a single table, then yes. Now, if you have a lot of tables to allocate, but you don't know in advance how many, and you don't know in advance the size of each, but you're pretty sure the total will be under a given size, then dynamic allocation is useful, even if you will never free the blocks. Because (worst number of blocks) x (worst size of each block) may be much bigger than your estimate of what is actually necessary. \$\endgroup\$
    – dim
    May 3, 2019 at 10:23
  • 1
    \$\begingroup\$ @dim That's not how you develop embedded systems. Or professional systems for that matter. You need to know the worst case in advance, you need to have a specification. If you cannot support the worst case scenario, then your program is broken and badly designed. If you set a worst case scenario that will never happen, then your spec is bad. Common sense will get you very far here. The worst thing you can do is to have a worse case that will only happen once in a million times, but don't support it. And so when it ultimately happens, your product fails mysteriously and nobody will know why. \$\endgroup\$
    – Lundin
    May 3, 2019 at 10:31
  • 2
    \$\begingroup\$ @Lundin: I've see real embedded systems where the manual had detailed guidelines about the memory use depending on configuration. If the theoretical worst case would need to be supported (all features configured to their individual maximum), the system would have costs literally billions, instead of millions. But the manual made it clear that memory was limited. You needed to configure the system such that the memory allocations would succeed. And if you didn't, the allocation would fail at start-up. That was certainly workable. \$\endgroup\$
    – MSalters
    May 3, 2019 at 14:12
4
\$\begingroup\$

You should know the maximum possible size of the LUT. Otherwise how will you know if the heap used by malloc is large enough? So just declare a statically allocated array that is large enough for the maximum size LUT. It's OK to use less than the maximum at run-time. This way you don't have to bother with malloc and a heap.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ This is the essence of it. malloc doesn't make any sense, because the table has to be large enough to cover the worst case anyway. \$\endgroup\$
    – Lundin
    Apr 4, 2017 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.