Кто какую реализацию использует для распределения памяти на cortex? Опции

[Beginning]

Проще говоря вы используете malloc и т.п. из библиотеки или свои? Я вот FreeRTOS изучаю. Решил досконально изучить исходники (heap_2). Честно говоря это треш какой то. Конечно как кому, но для меня такой стиль писания... Все эти x,px и и т.д. километровые имена. Принцип бритвы Оккамы походу не известен разработчикам. Пока всю эту дибилистику не убрал постоянно терялся на середине алгоритма. Как там, мозг не может запомнить одновременно более 7 переменных величин. Но да ладно не об этом. Вобщем мне не понравилась такая реализация - нету дефрагментации кучи. Взял стандартные библиотечные (KEIL RVDS). Но их тоже оказывается 2 реализации http://www.keil.com/support/man/docs/armli...ib_Cihfiabf.htm
Как они толком работают, не поймешь - исходников я не нашёл.
Вобщем кто какой реализацией пользуется? Может кто исходниками поделится. Камень Cortex.

[Beginning]

Я не очень понимаю выражения "не использовать кучу". Тут 2 варианта, либо ты резервируешь память раз и навсегда, либо динамически выдаёш, забираеш. В первом варианти торетически память в большинстве случаев будет простаивать.

[jcxz]

Я не очень понимаю выражения "не использовать кучу". Тут 2 варианта, либо ты резервируешь память раз и навсегда, либо динамически выдаёш, забираеш. В первом варианти торетически память в большинстве случаев будет простаивать.

Во-втором случае будет простаивать как минимум в 2 раза большее кол-во памяти.
Все кучефилы почему-то забывают об элементарной вещи, которая сводит на нет все +-ы кучи в embedded:
если к примеру 2 потока используют периодически каких-то 2 блока памяти и зависимость во времени этих использований невозможно детерминировать и возможны моменты одновременного использования (т.е. - невозможно поместить эти 2 блока в union static), то они совершенно забывают, что если выделять эти блоки на куче, то тоже будут моменты одновременного использования, соответственно - объём памяти в куче должен быть равен не менее чем сумме размеров блоков (а в реальности - более из-за заголовков).
Поэтому в типичном эмбеддед-приложении где нет запускаемых пользователем задач (которым при нехватке памяти можно отказать в запуске) или если нет таких потоков, выполнение которых можно остановить без ущерба функционированию системе при нехватке памяти, использование кучи не приводит к уменьшению требований по памяти, а наоборот - увеличивает требования к памяти + приводит к проблемам фрагментации.
Поэтому обычное static-размещение + union для использований неперекрывающихся по времени, однозначно рулит.
Поймите-же эту простую мысль, кучефилы, и творения ваши станут чуть менее глючными!!!

[Axel]

Поэтому в типичном эмбеддед-приложении...
Поймите-же эту простую мысль, кучефилы, и творения ваши станут чуть менее глючными!!!

Ну чего уж так брутально... Для меня например уже долгое время типичными являются аппликации с несколькими альтернативными режимами. Динамическое создание и убиение соответствующих классов проходит "со свистом", а наоборот - не всегда... А если еще и компоненты оси присутствуют в качестве полей этих классов, то и перформенс улучшается (не то, чтобы я это ощущал, но сознавать приятно ).