Перевод может содержать ошибки. Читайте первоисточник: Memory Management
| Назад: [Более подробно...] | Вверх: [Более подробно...] | Вперёд: [Более подробно...] |
Ядру ОС нужно ОЗУ при каждом создании задач, очередей, мьютексов, программных таймеров, семафоров или групп событий. ОЗУ может либо автоматически динамически выделяться из кучи FreeRTOS внутри вызовов функций API, создающих объекты, либо предоставляться разработчиком приложения.
Если объекты ОС создаются динамически, то иногда можно использовать стандартные функции библиотеки C, а именно malloc() и free() для этих целей, но...
... так что чаще всего требуется альтернативная реализация выделения памяти.
Однако различные встраиваемые системы реального времени могут иметь совершенно разные требования к ОЗУ и времени выделения/освобождения памяти, поэтому каждый алгоритм будет подходить только для некоторого подмножества приложений.
Чтобы обойти эту проблему, FreeRTOS поддерживает API выделения памяти на уровне портирования (переносимости). Уровень переносимости расположен отдельно от исходных файлов ядра ОС, что позволяет обеспечить реализацию, подходящую для конкретного разрабатываемого приложения. Когда ядру ОС требуется получить ОЗУ, вместо вызова malloc() оно вызвает pvPortMalloc(). А когда ОЗУ освобождается, вместо вызова free() ядро ОС вызывает функцию vPortFree().
FreeRTOS предлагает несколько схем управления кучей, которые отличаются по сложности и возможностям. Также вы можете использовать свою собственную реализацию кучи, и даже использовать две реализации одновременно. Использование двух реализаций одновременно позволяет размещать стеки задач и другие объекты ОС в быстром внутреннем ОЗУ, а данные приложения размещать в медленном внешнем ОЗУ.
Комплект поставки FreeRTOS включает в себя пять примеров реализации распределения памяти, каждый из которых описан далее в подразделах. Также в этих подразделах приведены рекомендации по выбору наиболее подходящего варианта.
Каждая представленная реализация находится в отдельном исходном файле (heap_1.c, heap_2.c, heap_3.c, heap_4.c и heap_5.c соответственно), которые расположены в каталоге Source/Portable/MemMang в комплекте поставки. Другие реализации могут быть добавлены по мере необходимости. Ровно один из этих файлов должен быть включён в проект. Куча, определяемая этими функциями уровня переносимости будет использоваться ядром ОС даже если в приложении, использущем ОС, будет использоваться своя собственная реализация кучи.
Далее приведениы описания пяти реализаций из комплекта поставки FreeRTOS:
Это самая простая реализация из всех. В ней нет возможности освобождать память после её выделения. Несмотря на это, heap_1.c подходит для большого числа встраиваемых приложений. Это связано с тем, что в небольших и глубоко встроенных приложениях задачи, очереди, семафоры и прочие объекты, необходимые для работы, создаются во время первоначальной инициализации системы, и затем существуют в течение всего времени работы приложения (до выключения или до перезагрузки). Ничего никогда не удаляется.
Реализация просто подразделяет один массив на более мелкие блоки, когда запрашивается ОЗУ. Полный размер массива (полный размер кучи) устанавливается константой configTOTAL_HEAP_SIZE, которая определяется в файле FreeRTOSConfig.h. Константа configAPPLICATION_ALLOCATED_HEAP в файле FreeRTOSConfig.h позволяет располагать кучу в памяти по определённому адресу.
Функция API xPortGetFreeHeapSize() возвращает полный объём оставшегося свободного места в куче, что позволяет оптимизировать значение константы configTOTAL_HEAP_SIZE.
Реализация heap_1:
Эта схема использует алгоритм наилучшего соответствия и, в отличие от схемы heap_1, позволяет освобождать ранее выделенные блоки ОЗУ. Она не объединяет смежные свободные блоки в один большой блок. Если необходима возможность объединения, смотрите реализацию heap_4.
Полный размер массива (полный размер кучи) устанавливается константой configTOTAL_HEAP_SIZE, которая определяется в файле FreeRTOSConfig.h. Константа configAPPLICATION_ALLOCATED_HEAP в файле FreeRTOSConfig.h позволяет располагать кучу в памяти по определённому адресу.
Функция API xPortGetFreeHeapSize() возвращает полный объём оставшегося свободного места в куче, что позволяет оптимизировать значение константы configTOTAL_HEAP_SIZE. Но информацию о том, как свободная память фрагментирована на более мелкие блоки, с помощью этой функции получить не удастся.
Реализация heap_2:
Перечисленные ситуации могут привести к проблемам, связанным с фрагментацией памяти, если ваше приложение создаёт и удаляет такие объекты, как задачи, очереди, семафоры, мьютексы и т.д., в непредсказуемом порядке. Вообще такая ситуация маловероятна для большей части приложений, но о ней необходимо помнить.
Реализация heap_2.c подходит для большинства небольших систем реального времени, в которых объекты создаются динамически. Также смотрите похожую реализацию heap_4, в которой имеется возможность объединять свободные блоки памяти в один большой блок.
Эта реализация является простой оболочкой для функций malloc() и free() стандартной библиотеки языка C, которые в большинстве случаев будут предоставлены выбранным вами компилятором. Оболочка всего лишь делает вызовы функций malloc() и free() потокобезопасными.
Эта реализация:
Обратите внимание, что константа configTOTAL_HEAP_SIZE в файле FreeRTOSConfig.h ни на что не влияет, если используется реализация heap_3.
Эта схема использует алгоритм наилучшего соответствия и, в отличие от схемы 2, объединяет смежные блоки свободной памяти в один большой блок, используя алгоритм объединения.
Полный размер массива (полный размер кучи) устанавливается константой configTOTAL_HEAP_SIZE, которая определяется в файле FreeRTOSConfig.h. Константа configAPPLICATION_ALLOCATED_HEAP в файле FreeRTOSConfig.h позволяет располагать кучу в памяти по определённому адресу.
Функция API xPortGetFreeHeapSize() возвращает полный объём оставшегося свободного места в куче на момент вызова этой функции. А функция API xPortGetMinimumEverFreeHeapSize() возвращает наименьший размер свободного места в куче, который существовал в системе, загруженной приложением FreeRTOS. Но ни одна из этих функций не предоставляет информации о том, как нераспределённая память фрагментирована на более мелкие блоки.
Эта реализация:
heap_4.c особенно хорошо подходит для приложений, в которых схемы выделения памяти уровня портирования используются непосредственно в коде приложения, а не косвенно вызывая функции pvPortMalloc() и vPortFree() из функций API FreeRTOS. - чтоб я ещё понял, о чём это...
Эта схема использует алгоритм наилучшего соответствия и алгоритм объединения, как в heap_2, и допускает размещение кучи сразу в нескольких не смежных областях памяти.
Heap_5 инициализируется вызовом vPortDefineHeapRegions(), и не может быть использована, пока vPortDefineHeapRegions() не будет выполнена. Создание объектов ОС (задачи, очереди, семафоры и т.д.) будет неявно вызывать функцию pvPortMalloc(), поэтому важно, чтобы при использовании heap_5 функция vPortDefineHeapRegions() вызывалась перед созданием любых таких объектов.
Функция vPortDefineHeapRegions() принимает один параметр. Этот параметр является массивом структур HeapRegion_t. Тип HeapRegion_t определён в файле portable.h следующим образом:
/*----------------------------------------------------------------------------*/
/* Определение типа HeapRegion_t */
typedef struct HeapRegion
{
/* Стартовый адрес блока памяти, который будет частью кучи. */
uint8_t *pucStartAddress;
/* Размер блока памяти. */
size_t xSizeInBytes;
} HeapRegion_t;
Массив завершается определением региона по адресу NULL и с нулевой длинной. Кроме того, регионы памяти, определённые в массиве, должны перечисляться в порядке возрастания адресов. Представленный ниже код показывает пример такой реализации. Демонстрационное приложение MSVC Win32 simulator demo также использует heap_5, поэтому это приложение можно использовать как рекомендацию.
/*----------------------------------------------------------------------------*/
/* Инициализация кучи в реализации heap_5. Куча может быть использована после определения блоков, используемых для кучи. */
/* Размещение двух блоков ОЗУ для использования в качестве кучи. Первый блок соедржит 0x10000 байт, начиная с адреса 0x80000000, а второй блок содержит
0xA0000 байт, начиная с адреса 0x90000000. Блок, начинающийся с адреса 0x80000000 имеет меньший стартовый адрес, поэтому располагается в массиве первым. */
const HeapRegion_t xHeapRegions[] =
{
{ ( uint8_t * ) 0x80000000UL, 0x10000 },
{ ( uint8_t * ) 0x90000000UL, 0xA0000 },
{ NULL, 0 } /* Завершение описания блоков. */
};
/* Передача массива в функцию vPortDefineHeapRegions(). */
vPortDefineHeapRegions( xHeapRegions );
Функция API xPortGetFreeHeapSize() возвращает полный объём оставшегося свободного места в куче на момент вызова этой функции. А функция API xPortGetMinimumEverFreeHeapSize() возвращает наименьший размер свободного места в куче, который существовал в системе, загруженной приложением FreeRTOS. Но ни одна из этих функций не предоставляет информации о том, как нераспределённая память фрагментирована на более мелкие блоки.