Инженеры ST определили специальный API-интерфейс для статического выделения объектов FreeRTOS, таких как потоки, семафоры и т. д. Этот API-интерфейс немного отличается от официального API-интерфейса CMSIS-RTOS. Функции, отличающиеся в двух моделях выделения памяти, перечислены в таблице 3.

Таблица 3: Функции, отличающиеся в двух моделях выделения памяти

23.4.2.1.Выделение памяти потоку idle при использовании модели статического выделения памяти

Благодаря динамическому выделению FreeRTOS полностью заботится о выделении памяти потоку idle (вместе с его стеком и TCB). Вместо этого, при использовании статического выделения за правильное выделение памяти потоку idle отвечаем мы, как и с любым другим потоком.

Будучи потоком idle, автоматически выделяемым ядром во время его инициализации, FreeRTOS предоставляет универсальный способ выделения необходимого пространства памяти для потока idle. Функция:

void vApplicationGetIdleTaskMemory(StaticTask_t **ppxIdleTaskTCBBuffer, StackType_t \ **ppxIdleTaskStackBuffer, uint32_t *pulIdleTaskStackSize);

вызывается FreeRTOS перед запуском потока idle. Эта процедура должна использоваться для выделения TCB и стека потока idle и для передачи указателя на эти области памяти ядру. При использовании CubeMX для генерации проекта с FreeRTOS и выборе статической модели выделения памяти файл src/freertos.c уже содержит реализацию для функ-

ции vApplicationGetIdleTaskMemory().

23.4.3. Пулы памяти

Спецификация CMSIS-RTOS предоставляет понятие пулов памяти, и уровень, разработанный ST поверх ОС FreeRTOS, реализует их28. Пулы памяти (Memory pools) – это блоки фиксированного размера с динамически выделенной памятью, реализованные так, чтобы они были потокобезопасными. Это позволяет получить к ним доступ как из потоков, так и из ISR. Пулы памяти реализованы ST с использованием процедур pvPortMalloc() и vPortFree(), и, следовательно, действующее выделение памяти зависит от одного из аллокаторов heap_x.c. Пулы памяти являются необязательной функцией, которую можно включить, установив для макроса osFeature_Pool значение 1 в файле cmsis_os.h.

Пул памяти определен следующей структурой Си:

28 FreeRTOS не предоставляет эту структуру данных. Более того, пулы памяти доступны тогда и только тогда, когда мы включаем модель динамического выделения памяти.

22}

23}

В строке 8 определяется новый пул, который содержит восемь элементов, каждый из которых имеет размер, равный sizeof(MEM_BLOCK) (размер автоматически высчитывается макросом). Затем пул эффективно создается в строке 14, и один из восьми блоков извлекается из пула в строке 17 с помощью процедуры osPoolAlloc().

23.4.4. Обнаружение переполнения стека

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

К сожалению, дать конкретный ответ непросто, потому что это зависит от довольно длинного списка аспектов, которые нужно иметь в виду. Прежде всего, размер стека зависит от того, насколько глубок стек вызовов, то есть от количества функций, вызываемых нашим потоком, и от места, занимаемого каждым из них. Это пространство, по существу, состоит из локальных переменных и переданных параметров. Другими важными факторами являются архитектура процессора, используемый компилятор и выбранный уровень оптимизации.

Обычно размер стека потока вычисляется экспериментально, и FreeRTOS предлагает способ обнаружить переполнение стека. Читайте по губам: попытаться обнаружить. Потому что обнаружение переполнения стека является одним из самых сложных аспектов отладки, а также статического анализа программного кода.

FreeRTOS предлагает два способа обнаружения переполнения стека. Первый состоит в использовании функции:

UBaseType_t uxTaskGetStackHighWaterMark( TaskHandle_t xTask );

которая возвращает количество «неиспользуемых» слов стека потока. Например, предположим, что поток определен со стеком из 100 слов (то есть 400 Байт в STM32). Предположим, что в худшем случае поток использует 90 слов своего стека. Тогда

uxTaskGetStackHighWaterMark() возвратит значение 10.

Тип TaskHandle_t параметра xTask является не чем иным, как osThreadId, возвращаемым

функцией osThreadCreate(), и если мы вызываем uxTaskGetStackHighWaterMark() из того

же потока, мы можем передать NULL.

Эта функция доступна только если:

•макрос configCHECK_FOR_STACK_OVERFLOW определен со значением больше 0, или

•configUSE_TRACE_FACILITY определен со значением больше 0, или

•INCLUDE_uxTaskGetStackHighWaterMark определен со значением больше 1.

Все они должны быть явно определены в файле FreeRTOSConfig.h.