что такое freertos stm32
STM32 + FreeRTOS
Про использование FreeRTOS есть достаточно много материалов, подробно описывающих работу с задачами, семафорами и очередями. Поскольку у нас блог посвящен STM32, то расскажу про минимально необходимые телодвижения, чтобы запустить эту ОС.
Пункт ноль — окружение.
Я сторонник GCC, поэтому среда разработки — Eclipse, компилятор — Sourcery G++ Lite, отладчик — GDB.
Процессор STM32F103ZET, в принципе заработает на любом STM32F103.
Отладочная плата HY Redbull v3, от нее используются только светодиоды. Пойдет любая.
Пункт первый — стандартные библиотеки CMSIS и SPL (Standard Peripherals Library).
Проверяем, чтобы в файле stm32f10x_conf.h (который мы скопировали в наш проект) были раскомментированы
Не забываем прописать путь к заголовкам библиотеки и включить исходники библиотеки в проект (или скопировать все что нам нужно в каталог проекта, что в принципе не рекомендуется, но поначалу все так делают).
Пункт второй — настройка FreeRTOS
Тут тоже достаточно просто — подключаем файл FreeRTOSConfig.h с минимальной настройкой параметров:
Главное настроить следующие параметры:
configCPU_CLOCK_HZ — частота процессора
configTICK_RATE_HZ — частота тика ОС
INCLUDE_vTaskDelay — разрешить использование функции vTaskDelay
По этому поводу первые грабли: ключи начинающиеся на INCLUDE сделаны для того, чтобы исключить неиспользуемые функции из билда, поэтому без них использовать соответствующие функции не получится — будет ошибка.
Остальное — как придется. Особо не важно.
В папке с FreeRTOS находим нужный нам порт (процессорозависимая часть) и забираем оттуда файлики (или подключаем нужную папку). Для нашего процессора порты находятся в папке:
\Source\portable\GCC\ARM_CM3\
Там два файла, забираем оба.
Также, из папочки \Source\portable\MemMang\ надо утащить один из файлов. Это менеджеры памяти, подробности — на сайте FreeRTOS. Утаскиваем heap_2.c
Пункт три — настройки основного проекта
Для правильной работы FreeRTOS нужны обработчики трех прерываний:
В исходниках FreeRTOS они описаны соответственно (файл port.c):
Чтобы линкер увидел эти описания и правильно собрал таблицу прерываний, надо слегка изменить файл стартапа. Делаем просто — везде, где нашли SVC_Handler меняем его на vPortSVCHandler и так далее.
Второй вариант, менее деструктивный, подсказал Bass: добавляем в файл FreeRTOSConfig.h следующие строки:
Поскольку у нас своих прерываний нет, то файлы stm32f10x_it.h и stm32f10x_it.c можно не использовать. Обычно там уже есть шаблоны обработчиков прерываний, поэтому как только надо будет куда-то подцепиться — смотрим сначала туда. Конечно, никто не запретит сунуть обработчики в любой другой файл, но как-то неаккуратненько будет.
В файле main.c подключаем все до кучи:
В принципе все. Файл stm32f10x_it.h я не подключаю по вышеописанным причинам.
Пункт четыре — запуск
Дальше запускаем две задачи:
и после этого пинаем шедуллер, чтобы он крутил эти задачи:
Да, надо жеж написать собственно код задач, чтобы было что крутить. Выше функции main(), чтобы не ругался компилятор, описываем две функции:
Тут, по-моему, классический пример самодокументированного кода 🙂
В первой функции мигаем светодиодом на PF6 с периодом 1000мс, во второй — с периодом 642мс. Это чтобы светодиоды мигали вразнобой и создавали полное ощущение асинхронности. Значение задержки задается в тиках системного таймера. У нас тик совершенно случайно равен 1 мс.
Компилим, заливаем, опаньки — все мигает.
Пункт пять — выводы
Объем скомпилированного кода получился чуть больше 5 килобайт:
Огромный объем bss – это heap, который отожрал FreeRTOS под свои нужды (стек задач, переключение контекста). Естественно, настраивается.
Пункт шесть — «а теперь — слайды» (с).
PS. перезалил архив — теперь используется FreeRTOS 7.1.0
Комментарии ( 92 )
С чего вы взяли что эти функции и структуры — это CMSIS? Это вообще то в первую очередь SPL (Standart Periphery Library). Некоторые склонны отождествлять эти вещи, но это не совсем верно.
FreeRTOS: введение
Зачем все это? Или введение в многозадачные системы, от создателей FreeRTOS.
К ОСРВ жесткого типа, как раз относят ОСРВ во встраиваемых устройствах. В чем-то они похоже на ОСРВ на дестопах(многопоточное выполнение на одном процессоре), но и имеют главное отличие — каждая задача должна выполняться за отведенный квант времени, не выполнение данного условия ведет к краху все системы.
А все таки зачем?
Если у Вас есть устройство с нетривиальной логикой синхронизации обмена данными между набором сенсоров, если Вам действительно нужно гарантировать время отклика, и наконец-то если Вы думаете, что система может разростись, но не знаете насколько, то РТОС Ваш выбор.
Не стоит применять РТОС, для применения РТОС т.е. не нужно применять РТОС в слишком тривиальных задачах(получить данные с 1 сенсора, и отправить дальше, обработать нажатие 1 кнопки и т.д) т.к. это приведет к ненужной избыточности, как полученного кода, так и решения самой задачи.
Работа с тасками(или задачами, процессами).
Для начала приведу несколько определений, для того чтобы внести ясность в дальнейшие рассуждения:
«Операционные системы реального времени (ОСРВ(RTOS)) предназначены для обеспечения интерфейса к ресурсам критических по времени систем реального времени. Основной задачей в таких системах является своевременность (timeliness) выполнения обработки данных».
«FreeRTOS — многозадачная операционная система реального времени (ОСРВ) для встраиваемых систем. Портирована на несколько микропроцессорных архитектур.
От хабраюзера andrewsh, по поводу лицензии: разрешено не публиковать текст приложения, которое использует FreeRTOS, несмотря на то, что OS линкуется с ним. Исходники самой же RTOS должны всегда прикладываться, изменения, внесённые в неё — тоже.».
FreeRTOS написана на Си с небольшим количеством ассемблерного кода(логика переключения контекста) и ее ядро представлено всего 3-мя C файлами. Более подробно о поддерживаемых платформах можно почитать на официальном сайте.
Перейдем к делу.
Любой таск представляет собой Си функцию со следующим прототипом:
Каждый таск – это по сути мини подпрограмма, которая имеет свою точку входу, и исполняется внутри бесконечного цикла и обычно не должна выходить из него, а также имеет собственный стэк. Одно определение таска может использоваться для создания нескольких тасков, которые будут выполняться независимо и также иметь собственный стэк.
Тело таска не должно содержать явных return; конструкций, и в случае если таск больше не нужен, его можно удалить с помощью вызова API функции. Следующий листинг, демонстрирует типичный скелет таска:
Для создания таска, и добавления ее в планировщик используется специальная API функция со следующим прототипом:
pvTaskCode – так как таск – это просто Си функция, то первым параметром идет ее значение.
pcName – имя таска. По сути это нигде не используется, и полезно только при отладке с соответствующими плагинами для IDE.
usStackDepth – так как каждый таск – это мини подпрограмма, со своим стэком, то данный параметр отвечает за его глубину. При скачивании RTOS и разворачивания системы для своей платформы, вы получаете файл FreeRTOSConfig.h настройкой которого можно конфигурировать поведение самой ОС. В данном файле также объявлена константная величина configMINIMAL_STACK_SIZE, которую и стоит передавать в качестве usStackDepth с соответствующим множителем, если это необходимо.
pvParameters – при создании, каждый таск может принимать некоторые параметры, значения, или ещё что-то что может понадобиться внутри тела самого таска. С точки зрения инкапсуляции, этот подход наиболее безопасный, и в качестве pvParameters стоит передавать, например, некоторую структуру, или NULL, если ничего передавать не нужно.
uxPriority – каждый таск имеет свой собственный приоритет, от 0(min) до (configMAX_PRIORITIES – 1). Так как, по сути, нет верхнего предела для данного значения, то рекомендуется использовать как можно меньше значений, чтобы не было дополнительно расхода RAM на данную логику.
pxCreatedTask — хэндл созданного таска. При создании таска, опционально можно передать указатель на хэндл будующего таска, для последующего управления работой самого таска. Например, для удаления определенного таска.
Данная функция возвращает pdTRUE, в случае успешного создания таска, или errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY, в случае если размер стэка был указан слишком большим, т.е. недостаточно размера хипа для хранения стэка таска, и самого таска.
На следующем листинге я привел, короткий пример законченной программы, которая создает 2 таска, каждый из которых мигает светодиодом:
В следующем посте я планирую написать о взаимодействии между тасками, и работе с прерываниями.
STM32 и FreeRTOS. 1. Развлечение с потоками
Данный цикл из 5 статей рассчитан на тех, кому стало мало возможностей привычных «тинек» и ардуинок, но все попытки перейти на более мощные контроллеры оканчивались неудачей или не приносили столько удовольствия, сколько могли бы. Все ниженаписанное проговаривалось мной много раз на «ликбезе» программистов нашей студии (которые часто сознавались, что переход с «тинек» на «стмки» открывает столько возможностей, что попадаешь в ступор, не зная за что хвататься), поэтому смею надеяться, что польза будет всем. При прочтении подразумевается, что читающий — человек любопытный и сам смог найти и поставить Keil, STM32Cube и понажимать кнопки «ОК». Для практики я использую оценочную плату STM32F3DISCOVERY, ибо она дешевая, на ней стоит мощный процессор и есть куча светодиодиков.
Каждая статья рассчитана на «повторение» и «осмысление» где-то на один околовечерний час, ибо дом, семья или отдых…
Очень часто (да что там часто, практически всегда) микроконтроллеры применяют в условиях, когда необходимо отслеживать сразу несколько параметров. Или наоборот, управлять одновременно несколькими устройствами.
Вот задача для примера: у нас есть 4 выхода, на которых необходимо выводить импульсы разной длительности с разными паузами. Все, что у нас есть – это системный таймер, который считает в миллисекундах.
Усложняем задачу в духе “сам себя замучаю на ардуино”. Таймеры заняты другим, PWM не подходит, ибо не на всех ножках он работает, да и не загонишь его на нужные режимы обычно. Немного подумав, садимся и пишем примерно такой код
И так или примерно так для всех 4 портов. Получается приличная портянка на несколько экранов, но эта портянка работает и работает довольно быстро, что для микроконтроллера важно.
Потом внезапно программист замечает, что при каждом цикле дергается порт, даже если его состояние не меняется. Правит всю портянку. Потом число портов с такими же потребностями увеличивается в два раза. Программист плюет и переписывает все в одну функцию типа PortBlink(int port num).
Почти наступило счастье, но внезапно потребовалось что бы на каком-то порту вместе с управлением “на выход” что-то предварительно считывалось и уже на основе этого считанного управлялся порт. Программист снова матерится и делает еще одну функцию, специально под порт.
Счастье? А вот фигу. Заказчик что-то этакое прицепил и это считанное может легко тормознуть процесс на секунды … Начинается стенания, программисты правят в очередной раз код, окончательно превращая его в нечитаемый треш, менеджеры выкатывают дикие прайсы заказчику за добавление функционала, заказчик матерится и решает больше никогда не связываться со встроенными решениями.
(типа реклама и восхваление) А все почему? Потому что изначально было принято неправильное решение о платформе. Если есть возможность, мы предлагаем навороченную платформу даже для примитивных задач. По опыту стоимость разработки и поддержки потом оказываются гораздо ниже. Вот и сейчас для управления 8мю выходами я возьму STM32F3, который может работать на 72МГц. (шепотом) На самом деле просто у меня под рукой демоплата с ним (смаил). Была еще с L1, но мы ее нечаянно использовали в одном из проектов.
Открываем STM32Cube, выбираем плату, включаем галочку около FreeRTOS и собираем проект как обычно. Нам ничего этакого не надо, поэтому оставляем все по умолчанию.
Что такое FreeRTOS? Это операционная система почти реального времени для микроконтроллеров. То есть все, что вы слышали про операционные системы типа многозадачности, семафоров и прочих мутексов. Почему FreeRTOS? Просто ее поддерживает STM32Cube ;-). Есть куча других подобных систем – та же ChibiOS. По своей сути они все одинаковые, только различаются командами и их форматом. Тут я не собираюсь переписывать гору книг и инструкций по работе с операционными системами, просто пробегусь широкими мазками по наиболее интересным вещам, которые очень сильно помогают программистам в их нелегкой работе.
Ладно, буду считать что прочитали в интернете и прониклись. Смотрим, что поменялось
Где-то в начале main.c
и после всех инициализаций
И пустая StartThread с одним бесконечным циклом и osDelay(1);
Удивлены? А между тем перед вами практически 90% функционала, которые вы будете использовать. Первые две строки создают поток с нормальными приоритетом, а последняя строка запускает в работу планировщик задач. И все это великолепие укладывается в 6 килобайт флеша.
Но нам надо проверить работу. Меняем osDelay на следующий код
Компилируем и заливаем. Если все сделано правильно, то у нас должен замигать синий светодиодик (на STM32F3Discovery на PE8-PE15 распаяна кучка светодиодов, поэтому если у вас другая плата, то смените код)
А теперь возьмем и растиражируем полученную функцию для каждого светодиода.
Добавим поток для каждого светодиода
И перенесем туда код для зажигания светодиода
В общем все однотипно.
Компилируем, заливаем … и получаем фигу. Полную. Ни один светодиод не мигает.
Путем страшной отладки методом комментирования выясняем, что 3 потока работают, а 4 – уже нет. В чем проблема? Проблема в выделенной памяти для шедулера и стека.
Смотрим в FreeRTOSConfig.h
3000 байт на все и каждой задаче 128 байт. Плюс еще где-то надо хранить информацию о задаче и прочем полезном. Вот поэтому, если ничего не делать, планировщик при нехватке памяти даже не стартует.
Судя по факам, если включить полную оптимизацию, то сам FreeRTOS возьмет 250 байт. Плюс на каждую задачу по 128 байт для стека, 64 для внутреннего списка и 16 для имени задачи. Считаем: 250+3*(128+64+16)=874. Даже до килобайта не дотягивает. А у нас 3 …
В чем проблема? Поставляемая с STM32Cube версия FreeRTOS слишком старая (7.6.0), что бы заиметь vTaskInfo, поэтому я захожу сбоку:
Перед и после создания потока я поставил следующее (fre – это обычный size_t)
Втыкаем брекпоинты и получаем следующие цифры: перед созданием задачи было 2376 свободных байт, а после 1768. То есть на одну задачу уходит 608 байт. Проверяем еще. Получаем цифры 2992-2376-1768-1160. Цифра совпадает. Путем простых логических умозаключений понимаем, что те цифры из фака взяты для какого-нибудь дохлого процессора, со включенными оптимизациями и выключенными всякими модулями. Смотрим дальше и понимаем, что старт шедулера отьедает еще примерно 580 байт.
В общем, принимаем для расчетов 610 байт на задачу с минимальным стеком и еще 580 байт для самой ОС. Итого в TOTAL_HEAP_SIZE надо записать 610*9+580=6070. Округлим и отдадим 6100 байт – пусть жирует.
Компилируем, заливаем и наблюдаем, как мигают все светодиоды разом. Пробуем уменьшить стек до 6050 – опять ничего не работает. Значит, мы подсчитали правильно 🙂
Теперь можно побаловаться и позадавать для каждого светодиодика свои промежутки “импульса” и “паузы”. В принципе, если обновить FreeRTOS или поколдовать в коде, то легко дать точность на уровне 0,01мс (по умолчанию 1 тик – 1мс).
Согласитесь, работать с 8ю задачами поодиночке гораздо приятней, чем в одной с 8ю одновременно? В реальности у нас в проектах обычно крутится по 30-40 потоков. Сколько было бы смертей программистов, если всю их обработку запихать в одну функцию я даже подсчитать боюсь 🙂
Следующим шагом нам необходимо разобраться с приоритетами. Как и в реальной жизни, некоторые задачи “равнее” остальных и им необходимо больше ресурсов. Для начала заменим одну мигалку мигалкой же, но сделанной неправильно, когда пауза делается не средствами ОС, а простым циклом.
То есть вместо osDelay() вставляется вот такой вот ужас.
Число циклов обычно подбирается экспериментально (ибо если таких задержек несколько, то куча головной боли в расчетах обеспечено). Эстеты могут подчитать время выполнения команд.
Заменяем, компилируем, запускаем. Светодиодики мигают по прежнему, но как-то вяло. Просмотр осциллографом дает понять, что вместо ровных границ (типа 50мс горим и 50мс не горим), границы стали плавать на 1-2мс (глаз, как ни странно, это замечает). Почему? Потому что FreeRTOS не система реального времени и может позволить себе такие вольности.
А теперь давайте поднимем приоритет этой задаче на один шажок, до osPriorityAboveNormal. Запустим и увидим одиноко мигающий светодиод. Почему?
Потому что планировщик распределяет задачи по приоритетам. Что он видит? Что задача с высоким приоритетом постоянно требует процессор. Что в результате? Остальным задачам времени на работу не остается.
А теперь понизим приоритет на один шаг от нормального, до osPriorityBelowNormal. В результате планировщик, дав поработать нормальным задачам, отдает оставшиеся ресурсы «плохой».
Отсюда можно легко вывести первое правило программиста: если функции нечего делать, то отдай управление планировщику.
В FreeRTOS есть два варианта «подожди»
Первый вариант «просто подожди N тиков». Обычная пауза, без каких либо изысков: сколько сказали подождать, столько и ждем. Это vTaskDelay (osDelay просто синоним). Если посмотреть на время во время выполнения, то будет примерно следующее (примем что полезная задача выполняется 24мс):
… [0ms] — передача управления — работа [24ms] пауза в 100мс [124ms] — передача управления — работа [148ms] пауза в 100мс [248ms]…
Легко увидеть, что из-за времени, требуемой на работу, передача управления происходит не каждые 100мс, как изначально можно было бы предположить. Для таких случаев есть vTaskDelayUntil. С ней временная линия будет выглядеть вот так
… [0ms] — передача управления — работа [24ms] пауза в 76мс [100ms] — передача управления — работа [124ms] пауза в 76мс [200ms]…
Как видно, задача получает управление в четко обозначенные временные промежутки, что нам и требовалось. Для проверки точности планировщика в одном из потоков я попросил делать паузы по 1мс. На картинке можете оценить точность работы с 9ю потоками (про StartThread не забываем)
На этом я обычно заканчиваю, ибо народ настолько погружается в игру с приоритетами и выяснением «когда оно сломается», что проще замолчать и дать поразвлекаться.
STM32F1xx — Инструменты разработчика и FreeRTOS
Железо
Традиционно начнем с железа.
В прошлых статьях ядром системы была плата STM32VLDISCOVERY.
Плата, безусловно, хороша, и подкупает тем, что ее цена всего 300 рублей. В принципе, хороший инструмент для того, чтобы начать знакомиться с этим семейством микроконтроллеров. Но.
Дело в том, что при выборе отладочной платы, всегда хочется соблюсти баланс количества и качества, то есть с одной стороны, иметь все необходимое для работы, с другой – не хочется чтобы плата превращалась в огромного и дорогого монстра. У STM32VLDISCOVERY баланс смещен в сторону дешевизны и минимализма.
Полазив по e-bay, я нашел для себя более удобную, на мой взгляд, плату, которую и представляю вашему вниманию. Вот она:
Mini-STM32
Теперь то, что касается IDE. Изначально я выбрал Keil uVision, так как когда-то уже работал с ней.
Ну, что я могу сказать – я проработал в кейле достаточно, и в принципе с ним можно примириться. Но, положа руку на сердце – ИДЕ там ужасна. Также ужасна как и ИДЕ IAR’a, на мой взгляд.
IAR и Keil – признанные лидеры в разработке компиллеров, этого у них не отнять, но я до сих пор не могу понять, почему, имея такие компиллеры, они продолжают тянуть свои IDE, застрявшие по удобству на уровне 2002 года. Как пример могу привести Texas Instruments – у них раньше тоже была своя IDE, в довесок к компиллеру. Потом им это надоело, они взяли Eclipse, допилили его, прикрутили к своим компиллеру и профайлеру, и получили отличный продукт. Почему так не поступят Keil и IAR для меня остается загадкой, но на мой взгляд их IDE не такие удобные, как могли бы быть. Раздражает не очень удобная подсветка синтаксиса, полное отсутствие code-completion’а, не самая удобная навигация по коду. Плюс, uVision частенько у меня падала, но это можно списать на драйвер программатора.
Как бы то ни было, я стал искать альтернативу и нашел ее в виде CooCox IDE.
Это бесплатная среда разработки на базе эклипса, которая призвана работать, разумеется, с GCC.
Из плюсов отмечу все достоинства эклипса – удобная навигация, есть автозавершение кода и т.п.
Кроме того прикручен удобный просмотрщик периферии процессора, мне понравился больше чем Кейловский. Очень удобно наличие репозитория компонентов – говоря по-простому, при старте проекта мы как в визарде выбираем нужный нам процессор из списка, после чего отмечаем галочками те из модулей Standard Peripheral Library, которые хотели бы использовать, и они автоматически подключаются к проекту (Об этом чуть подробнее в следующем разделе статьи). Также сразу же можно просмотреть примеры, идущие в комплекте с этим модулем SPL и справку по его функциям.
Минусы CooCox IDE вобрала также из Eclipse, к коим относится тяжеловесность – у меня она потребляет около 180 метров оперативной памяти, занимая на диске 800 мегабайт.
Еще одним минусом является ее работа с этим самым J-Link-ком. Отладка происходит через приложение от создателей J-Link’a, предоставляющее стандартный gdb-шный интерфейс, но почему-то среда при каждом дебаге это приложение перезапускает, в отличие от того же кейла (который вообще работает через свои дллки).
Поэтому старт отладки в Кейле начинается через секунду, в CooCox же – через секунд 20. Возможно, это можно как-нибудь исправить настройками, но я пока таких настроек не видел, поэтому буду благодарен, если кто подскажет.
Тем не менее, я все таки остановился на CooCox — если вас тоже не устраивает IDE от Keil или IAR, или вы не хотите пользоваться ломанным ПО и предпочитаете опенсорс – качайте не задумываясь.
CooCox и FreeRTOS
Об операционной системе FreeRTOS было сказано много, в частности, на хабре (вот, например, одна из статей: FreeRTOS: введение)
Я решил тоже приобщиться к этой технологии и расширить свой арсенал инструментов, тем более, что FreeRTOS не навязывает никакого HAL (Hardware Abstraction Layer, слой абстракции от оборудования, драйверы то бишь), и предоставляет только средства работы с задачами, синхронизацию и меж-процессное взаимодействие, поэтому во многих случаях будет очень удобна.
Рассмотрим поподробнее, что же нам необходимо, чтобы использовать FreeRTOS вместе с CooCox IDE на нашей плате Mini-STM32.
На самом деле, все очень просто. Архитектурное портирование (портирование кода, требуемого шедулером под архитектуру Cortex M3) уже давно выполнено, и нам нужно, по сути, просто правильно составить проект для CooCox.
Начинаем с того, что скачиваем исходники FreeRTOS с их официального сайта.
Вот прямая ссылка: http://sourceforge.net/projects/freertos/files/.
Тем временем создаем новый проект в CooCox, я назвал его FreeRTOS-Mini.
Выбираем в визарде производителя ST, в списке чипов – чип, на котором построена отладочная плата, STM32F103VE.
После этого перед нами открывается уже упомянутое окошечко репозитория компонентов, представляющих собой части SPL.
Теперь начинаем править файлы проекта. Начнем с настроек ядра. Оттуда нам нужно будет убрать только пару строчек, связанных со старым проектом – левый, ненужный нам инклуд.
Все остальное можно оставить без изменений, а можно прочитать статью о настройке ядра FreeRTOS и поменять опции по необходимости, этим мы сейчас заниматься не будем.
Теперь идем в стартап код (cmsis_boot\startup\startup_stm32f10x_hd.c) и делаем следующее: находим строки:
У меня это строки 114-122, и добавляем после них такой код:
Это обработчики прерываний из ядра ОС, которые объявлены в файле port.c. Теперь нам нужно запихнуть их в вектор прерываний, который идет ниже (строки 129-209):
Соответственно, меняем вектор так, как написано в вышеизложенном коде, заменив строки, отмеченные SVCall Handler, PendSV Handler, SysTick Handler на vPortSVCHandler, xPortPendSVHandler и xPortSysTickHandler соответственно.
UPD:
В комментариях мне подсказали более изящный вариант, чем ковыряние стартового файла. Достаточно просто переопределить обработчики следующими дефайнами:
После открываем в дереве проекта папку Source\MemMang, и выбираем ту реализацию мемори менеджмента, которая нам подходит. Подробнее об этом написано тут: FreeRTOS Memory Management.
Если коротко – файл номер 1 это упрощенная реализация с выделением памяти, но без освобождения, файл номер 2 – более продвинутая реализация, позволяющая освобождение памяти, и номер 3 – реализация, которая потребует от вас библиотеки с реализованными malloc и free. Я выбрал вторую реализацию, оставшиеся два файла исключаем из компиляции, кликнув правой кнопкой на имя файла в дереве проекта и выбрав пункт Exclude from build.
Осталось совсем чуть-чуть – открываем файл main.c, добавляем туда нужные нам инклуды от SPL:
Инклуды от FreeRTOS:
После объявляем функцию, которая будет вызвана до старта шедулера, в соответствии с рекомендациями в таком виде:
И функцию, которая будет исполнять роль нашего тестового таска, вот так:
Реализация функций выглядит так:
В тестовых целях ничего полезного не написал, задача просто зажигает светодиод на плате.
Осталась сама функция main(), которая стартанет задачу и шедулер:
Вот в принципе и все. Осталось настроить дебаг – для этого жмем «Debug configuration», во вкладке Debugger выбираем наш программатор (J-Link) и порт JTAG.
Ставим галочку Run To Main, чтобы не барахтаться в стартап-коде, в строке GDBServer cmdline tool указываем путь к экзешнику, идущему с программатором (скачать можно с сайта Segger), у меня это C:\SEGGER\JLinkARM_V440b\JLinkGDBServerCL.exe
После жмем Apply и Close.
Теперь компиллим наш проект и жмем на дебаг – если все получилось, после аплода и выполнения, должен загореться светодиод.
Заключение
Правильный выбор инструментов разработчика, безусловно, обеспечит наиболее быстрое и комфортное освоение новых технологий. Я надеюсь, что, осветив в данной статье отладочную плату Mini-STM32 и CooCox IDE, я помог разработчикам приглядеться к новому инструменту. Что касается операционной системы FreeRTOS – это бесспорно очень мощное средство, и, на мой взгляд, хорошая ступень, для перехода от программирования прошивок «в лоб» к использованию эмбеддед операционных систем.