Уже в который раз поднимаю тему динамического создания-удаления задач. Вот к чему пришёл:

Для того что бы это стабильно работало, стек у всех задач должен быть одного размера. Если он разный, то куча будет сегментироваться, и через какое-то время это приведёт к краху системы. Ни одна из стандартных схем выделения памяти не heap1 .... heap5 не реализует дефрагментацию кучи. Получается не очевидное сразу ограничение : "динамическое сознание и удаление требует одинаковый размер стека всех задач"

В самом общем случае куча может быть дефрагментирована только одним способом: если для доступа к области динамической памяти используется исключительно двойной указатель (указатель на указатель)

Или примено одного - не отличающегося более, чем вдвое. Ну и радикально проблема решается тем, что при проектировании системы есть проход через фазу кода все "временые" задачи убиты. Ведь они на то и временые что-бы не сущесвовать сколь-нибудь долго, иначе незачем их прибивать.

Как это решит проблему, если все стандартные системы выделения памяти heap1...heap5 не умеют дефрагментировать кучу, т.е. не умеют склеивать стоящие рядом пустые куски кучи ? Ни чем не занятая куча так и останется разбита на куски.

Почти первое, что я сделал во FreeRTOS много лет назад, это похерил то уродство, что было в нем менеджером памяти. Так что там дальше городили до heap5 мне неведомо, но нет нималейших причин зачем-то пытаться использовать негодные вещи - ничего не мешает иметь и склеивание и хоть сколь-нибудь разумные алгоритмы поиска свободного блока. Свой менеджер памяти на форуме выкладывал. Он и ВСЮ оставшуюся память сам забирает под распределение и блоки склеивает...

Как это не умеют?

Недавно наткнулся на такой момент в одном менеджере памяти - umm_malloc
Опенсорсный, может и FreeRTOS его позаимствовала.
Так там пока не сделаешь первое выделение и освобождение блока на весь объем памяти, этот менеджер довольно хитро работал.
Он не объединял свободную память если освобождаемые блоки в какой-то момент превышали определенный размер.
Очень знатный баг, но разбираться не стал.

Кстати, нынче модно вот такой менеджер применять - http://tlsf.baisoku.org/