23.4. Выделение памяти и управление ею

FreeRTOS не использует классические функции malloc() и free(), предоставляемые библиотекой среды выполнения Си24, потому что:

1.они используют много места в коде, увеличивая размер микропрограммы;

2.они не предназначены для обеспечения потокобезопасности;

3.они не являются детерминированными (время выполнения функции будет отличаться от вызова к вызову).

Таким образом, FreeRTOS предоставляет свою собственную схему динамического выделения для обработки необходимой памяти, но, поскольку существует несколько способов сделать это, каждая обладает своими преимуществами и компромиссами. FreeRTOS спроектирована так, что эта часть абстрагирована от остальной части ядра ОС, и она предоставляет пять различных схем выделения, которые пользователь может выбирать в зависимости от его конкретных потребностей. pvPortMalloc() и vPortFree() являются наиболее важными функциями, реализованными в каждой схеме, и их имя четко говорит о том, что они делают.

Эти пять схем не являются частью ядра FreeRTOS, но они являются частью уровня платформозависимого кода, и они реализованы в пяти файлах с исходным кодом Си, называющихся heap_1.c..heap_5.c и содержащихся в папке portable/MemMang. Скомпилировав один из этих файлов вместе с остальным кодом FreeRTOS, мы автоматически выбираем эту схему размещения для нашего приложения. Более того, мы можем в конечном итоге предоставить свою модель выделения, реализовав этот API-уровень (в худшем случае, нам нужно реализовать 5 функций) в соответствии с нашими конкретными потребностями.

23.4.1.1. heap_1.c

Многие встроенные приложения используют ОСРВ для логического разделения микропрограммы на блоки. Каждый блок имеет свои особенности, и часто он работает независимо от других блоков. Например, предположим, что вы разрабатываете устройство с TFT-дисплеем (возможно, контроллер современной посудомоечной машины). Обычно микропрограмма разделена на несколько потоков, один из которых отвечает за графическое взаимодействие (он обновляет отображение, печатая информацию и показывая потрясающие графические виджеты), а другие потоки отвечают за управление программой стирки (и, таким образом, за обработку датчиков, двигателей, насосов и т. д.). Эти приложения обычно имеют функцию main(), которая порождает потоки (как мы делали в предыдущих примерах), и почти ничего больше не инициализируя ОС, когда она начинает выполняться. Это означает, что аллокатор не должен учитывать какие-либо более сложные проблемы выделения, такие как детерминизм и фрагментация, и его можно упростить.

Аллокатор heap_1.c реализует очень простую версию pvPortMalloc() и не поддерживает vPortFree(). Приложения, которые никогда не удаляют поток или другие объекты ядра, такие как очереди, семафоры и т. д., подходят для использования этой схемы выделения памяти. Те области применения, где использование динамически выделенной памяти не рекомендуется, могут извлечь выгоду из этой схемы выделения, поскольку она предлагает детерминистский подход к управлению памятью, избегая фрагментации (поскольку память никогда не освобождается).

24 С одним заметным исключением в виде аллокатора heap_3.c, как мы скоро увидим.

для хранения объектов, выделенных во время выполнения. Тем не менее, он имеет другой подход при выделении памяти. Фактически, он использует алгоритм первого соответствия (first fit algorithm), который объединяет смежные свободные блоки в один большой блок, снижая риск фрагментации памяти. Этот метод, обычно используемый сборщиком мусора (garbage collector) в языках с динамическим и автоматическим выделением памяти, также называется объединением (coalescing).

К сожалению, такое поведение аллокатора heap_4.c приводит к тому, что он не детерминирован: выделение/освобождение многих небольших объектов вместе с созданием/уничтожением потоков может привести к большой фрагментации, что требует больше вычислительной обработки для упаковки памяти. Более того, нет никакой гарантии, что алгоритм вообще избежит утечек памяти. Однако обычно он быстрее, чем самая стандартная реализация malloc() и free(), особенно тех, которые предоставляются библиотекой newlib-nano.

Подробное объяснение алгоритма heap_4.c выходит за рамки данной книги. Для получения дополнительной информации обратитесь к документации FreeRTOS27.

23.4.1.5. heap_5.c

heap_5.c использует тот же алгоритм, что и у аллокатора heap_4.c, но он позволяет разделить пул памяти между различными несмежными областями памяти. Это особенно полезно для микроконтроллеров STM32, предоставляющих контроллер FSMC, который позволяет прозрачно использовать внешние SDRAM для увеличения всей оперативной памяти. Программист может решить выделить какой-то интенсивно используемый поток во внутреннюю память SRAM (или в CCM-память, если она доступна), а затем использовать внешнюю SDRAM для менее значимых объектов, таких как семафоры и мьютексы.

Определив пользовательский скрипт компоновщика, можно выделить два пула в двух областях памяти, а затем использовать функцию vPortDefineHeapRegions() от FreeRTOS, чтобы определить их как пулы памяти. Однако это продвинутое использование ОС, которое мы не будем здесь подробно описывать. Если вам интересно, вы можете обратиться к превосходной книге создателя FreeRTOS Ричарда Барри «Освоение ядра реального времени FreeRTOS» (Mastering the FreeRTOS Real Time Kernel by Richard Barry).

23.4.1.6.Как использовать malloc() и связанные с ней функции Си с

FreeRTOS

Как было сказано ранее, за исключением схемы выделения heap_3.c, FreeRTOS не использует память кучи Си для ее выделения потокам и другим объектам. Таким образом, вы можете использовать malloc() и free() в своем приложении.

Если вместо этого вы хотите использовать процедуры pvPortMalloc() и vPortFree(), обеспечивая переносимость вашего кода, вы можете просто переопределить malloc() и free() следующим образом:

void *malloc (size_t size) { return pvPortMalloc(size);

}

27 http://www.freertos.org/a00111.html#heap_4