Электроника для всех
Блог о электронике
FreeRTOS для чайников. Краткое описание.
Бытует мнение, что RTOS это некий хардкор для избранных. Что там все сложно, замудрено и новичкам туда соваться бестолку. Отчасти тут есть доля истины, такие системы крайне сложны в отладке, но и то лишь тогда, когда вы забиваете контроллер под завязку и работаете на пределе оперативной памяти и быстродействия. Тогда да, словить какой-нибудь dead lock или пробой стека можно на раз. И попробуй найти где это случилось в этой асинхронной системе. Но простые задачи на RTOS реализуются еще проще и с меньшим количеством мозга.
В цикле своих статей посвященных архитектуре программ я уже расписывал немного по этой теме, а также выкладывал рабочий проект своего диспетчера ОС, который я планировал превратить в постепенно в полноценную RTOS со всеми свистоперделками, но потом решил не изобретать велосипед и оставил его как есть, как легкое простое решение для совсем мелких МК.
▌FreeRTOS?
Почему именно она? Она популярна, она Free и она портирована на огромное количество архитектур, под нее существуют плагины для Keil и IAR и всякие примочки для PC. При этом она довольно легкая и функциональная.
Я не буду вам сейчас тут расписывать все эти прототипы функций, порядок записи, технические тонкости и прочее. Это все есть в технической документации и в замечательном цикле статей Андрей Курница, что был в журнале Компоненты и Технологии в 2011 году. PDF статьи вы найдете в конце.
Я лишь на пальцах и псевдокоде быстро распишу те инструменты которыми владеет FreeRTOS, чтобы когда вы будете читать более подробную документацию за деревьями не потеряли лес 🙂
Ну и все сказанное тут справедливо и для большинства других RTOS. Т.к. механизмы в целом все одни и те же и никто ничего нового еще не придумал.
▌Системный тик
Один из таймеров микроконтроллера, самый ненужный, настраивают на генерацию системных тиков. Один тик делается, обычно, раз в 1мс, но можно и чаще или реже. В зависимости от того какая реакция и дискретность системы нам нужна.
Каждый тик это вызов прерывания таймера, в котором вызывается диспетчер, чьими усилиями проворачиваются шестеренки ОС. Это время еще называют квантом, говоря, что задаче выделяется квант времени.
▌Задача
Краеугольным камнем любой RTOS является задача. Задача выглядит как функция которая крутит бесконечный цикл делающий какую-либо относительно простую процедуру. Представьте, что вы сделали на микроконтроллере программу которая только опрашивает кнопки и ничего больше не делает.
Ее код будет выглядеть примерно так:
Если в классическом стиле программирования бесконечные циклы были зло которое могло затупить всю программу, то в случае RTOS (она должна быть вытесняющей) это нормально. Так и должно быть. Можно даже быдлокодить и делать тупые задержки на циклах. Например так:
49 thoughts on “FreeRTOS для чайников. Краткое описание.”
Спасибо, замечательная статья, давно присматриваюсь к FreeRTOS. Но в данный момент экспериментирую с комактным диспетчером Рона Креймборга — случайно увидел ссылку в комментариях одной из статей.
Вопрос, собственно, такой — как делать задержки МЕНЬШЕ системного тика — ну например для шины 1 Wire? Сама шина дикий трэш для временных задержек — от микросекунд до секунд.
Если не повышать частоту системных тиков, то нужно выделять отдельный таймер, который взводится на нужный интервал и по прерыванию дает семафор задаче, при этом также нужно вручную вызвать диспетчер при помощи taskYIELD.
Как-то я интересовался этой темой. Согласен с bigdigital .Тут, похоже, нужно все-таки переходить от уровня FreeRTOS на уровень системных таймеров, далее семафорами и taskYIELD решать вопрос.
Повысить частоту за пределы 1KHz тяжеловато — нужно перелопачивать код (у меня STM32F4, 168 MHz — замучался! Остановился на вышеуказанном решении)
>как делать задержки МЕНЬШЕ системного тика
Использовать аппаратные ресурсы — те же никсы и окна имеют частоту системного таймера 100-1000 Гц, но это не мешает им работать с езернетами и прочим гигагерцовыми шинами.
1-wire хорошо реализуется через UART например.
То был мой, видимо, комментарий.
Из личного практического опыта хочу предупредить, что такой диспетчер можно с успехом использовать только для проектов небольшой сложности. Главные его недостатки, ИМХО:
— невозможность удаления задачи (это можно дописать самостоятельно, но при удалении задачи придется два раза шерстить всю очередь и пересчитывать задержки каждой из следующих задач). Из-за этого приходится опять изобретать велосипеды с флагами или сообщениями по которым одна задача сигнализирует другой о том, что она должна себя удалить при следующем выполнении.
— так как это не кооперативка, и никакой контекст не сохраняется — задача будет каждый раз выполняться с самого начала, т.о. любое ожидание события приводит к вынужденному дроблении одной задачи на кучу более мелких. На читаемости кода это сказывается не лучшим образом. Выходом может быть, также, ввести для задач состояния и построить на этой основе конечные автоматы. Но когда их много и они большие, то это опять превращается в спагетти из флагов и состояний.
Посмотрите еще в сторону protothreads. Они дают определенный уровень абстракции, который позволяет писать задачи подобно тому, как это делается в кооперативке, но с мизерным overhead-ом.
Я сделал себе небольшую такую оболочку на С++ для FreeRTOS — вышло очень удобно! Ну вот, например, прерывание по нажатию на кнопку выдает в очередь длительность, дергает семафор:
extern «C» void EXTI0_IRQHandler (void)
<
static const dword delWith = 100;
static const dword delWithout = 1000;
QueueISR _del (del); // подключились к очереди из прерывания с типом dword (unsigned long)
SemaphoreISR _sem (btnClicked); // подключились из прерывания к семафору
Объявляю задачу: Task2 l3 (Led, 2, «Led 3», 60); 2 параметра, имя функции Led, приоритет 2, имя «Led 3», глубина стека 60 (последние 3 параметра есть по умолчанию).
Реализую задачу:
void Led (Pin *pin, dword start_del)
<
Pin &led = *pin;
dword cur_delay = start_del;
dword max_stack = Task::getCurrentTask().maxStack ();
bool to_on = true;
while (1)
<
if (to_on)
++led;
else
—led;
to_on = !to_on;
del.wait (cur_delay);
if (del)
del >> cur_delay;
>
>
Создаю задачу: l3.init (&LedBlue, 1000);
Думаю написать пост для ценителей С++…
Особенно радует статическое выделение памяти в куче под стеки всех задач. И хуки — на TickHook очень удобно опросы кнопок вешать. Поделитесь кто на чем использовал FreeRTOS — у меня на 8 меге завелась:3
А какой конфиг был? Что выбросил?
Да почти все, мне только очереди нужны были.
configMINIMAL_STACK_SIZE 100 байт,
Как я понял, каждая функция хSomethingCreate жрет по 100 байт и еще на шедулер 100 уходит.
Спасибо, статья очень в тему. Опишите, пожалуйста, подробно процесс добавления и настройки FreeRTOS, для STM32 на вашей плате например.
Чем и занимаюсь сейчас.
Важное уточнение для [***]FromISR() функций. Любое прерывание, которое использует подобную функцию, должно иметь численное значение приоритета такое же или выше (а логически — такое же или ниже), чем значение configMAX_SYSCALL_INTERRUPT_PRIORITY.
Например:
NVIC_SetPriority(USART1_IRQn, configMAX_SYSCALL_INTERRUPT_PRIORITY>>4);
Также необходимо задать группировку приоритетов до запуска шедулера так:
NVIC_SetPriorityGrouping(3); // Это для тех, кто не юзает StdPeriphLib
или так:
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4); // Это для тех, кто юзает StdPeriphLib
Более подробно на буржуйском: http://www.freertos.org/RTOS-Cortex-M3-M4.html. Не зная этих особенностей можно словить трудновыцепляемые грабли.
Кстати, кто-нибудь пользуется возможностями трассировки? Есть библиотека FreeRTOS+Trace, но она платная. Может быть кто знает бесплатный аналог?
Да, спасибо. Замечание не лишнее. Подробно это у Курница расписано, но, думаю, тут не лишним будет упомянуть.
Тока два момента:
Нафига сдвигать вправо на 4? Ведь configMAX_SYSCALL_INTERRUPT_PRIORITY итак указан полным байтом.
И зачем определять группы если их не используешь?
В данном случае 4, потому что используется контроллер с 4 битами приоритета.
На самом деле я думаю правильней было бы задавать приоритет так NVIC_SetPriority(USART1_IRQn, (configMAX_SYSCALL_INTERRUPT_PRIORITY >> (8 — __NVIC_PRIO_BITS))+0, или какоето число если нужно чтобы прерывания обрабатывались системой);
Ось устроена так что она не работает с подприоритетами, поэтому контроллер настраивается на 4 группу приоритетов, где есть только 16 приоритетов и нет подприоритетов прерываний
Здесь Scorpion_ak47 http://forum.easyelectronics.ru/viewtopic.php?f=49&t=13911, хорошо расписал работу особенности настройки приоритетов Cortex M3 для FreeRTOS
Не, тут дело в том, что это на SPL, а эти клоуны приоритет задают числом от 0 до 15, а изначальный параметр записан как надо, в целый байт. И чтобы подвести его к формату SPL его надо сдвинуть, чтобы SPL его сдвинула обратно.
Разобрался. Верно, группы в общем случае задавать не надо (читай нельзя), т.к. после ресета группировка равна 0b000, что для STM32 эквивалентно 0b011. Как уже написал bigdigital, ось работает без подприоритетов, все прерывания должны быть вытесняющими, иначе что-то может пойти не так.
А как дела с этим всем на AVR будут обстоять? Функции те же будут?
Да, везде все одно и то же. Разница только в инициализации и устновке ОС. Ну и конфигах ее. Т.к. прерывания разные для шедулера, модель памяти и кучи и так далее.
То есть, чтобы разобраться достаточно будет твоего примера для stm32 и любого работающего примера на avr
Download FreeRTOS
Next Steps
The development activity for FreeRTOS has migrated from SVN to GitHub and can now be found directly on our Github organization. Download a previous release of the FreeRTOS kernel from GitHub as a standard zip (.zip) or self-extracting zip file (.exe). Unzip the source code while making sure to maintain the folder structure. Please read the documentation referenced below to understand the directory structure and get started quickly!
Getting started with the FreeRTOS kernel
Choose, compile, and build a FreeRTOS kernel demo
Getting started with an AWS Reference Integration
AWS Reference Integrations are pre-integrated FreeRTOS projects ported to microcontroller-based evaluation boards that demonstrate end to end connectivity to the cloud. AWS Reference Integrations help save months of development effort and accelerate time to market.
Getting started with FreeRTOS Plus Libraries
FreeRTOS provides a collection of MIT licensed libraries available for use in resource-constrained devices across all industries. FreeRTOS libraries are tested and optimized for use with the FreeRTOS kernel.
Getting started with FreeRTOS IoT Libraries
The FreeRTOS IoT libraries provide connectivity, security, and over-the-air update functionality suitable for building microcontroller-based IoT devices. It includes AWS reference integrations, and roadmap for an upcoming long-term-support (LTS) release.
Interact with and get support from the FreeRTOS community and Amazon Web Services (AWS)
Frequently Asked Questions
Issues List
Known Issues with the Current Release
Bug #175 is present in Kernel version 10.4.0. It has been fixed in version 10.4.1
Legacy Issues
Coldfire V2 CodeWarrior port
Coldfire V1 CodeWarrior port
The Coldfire V1 CodeWarrior projects will not automatically update to later CodeWarrior versions unless all unnecessary files are deleted from the FreeRTOS/Source directory first. See this support thread for more information.
MSP430 CrossWorks and GCC demos
The CrossWorks demo has not yet been updated to use CrossWorks V2.0 or later. The GCC demo has not yet been updated to use the latest MSPGCC compiler version.
AVR32 demos
The IAR Embedded Workbench demos for the AVR32 will not currently build if you are using a later version of the IAR tool chain. The issue is caused by changes to macro names within the compiler header files.
Silicon Labs SDCC ports
Unfortunately these will not work with the latest compiler versions. The compiler version used to generate the port is now rather old, but is stated on the port documentation page.
Эмулятор freertos для windows
An implementation of POSIX based FreeRTOS with the combination of SDL2 graphics. Aimed at providing an x86 emulation solution for teaching FreeRTOS to students without the need of embedded hardware. Used at the Technical University of Munich in the teaching of the «Embedded Systems Programming Lab». Please excuse any references to «students» or «course» if you’re not one of my students.
Based on the FreeRTOS (V5.X) simulator developed by William Davy. Updated to use FreeRTOS V9.0.0.
Checkout the Wiki page for a detailed Documentation!
Doxygen documentation can also be found on the GitHub Pages page.
The simulator uses the SDL2 graphics libraries.
Assuming that you have some basic utilities like make , cmake and git already installed, execute:
Additional requirements for development:
Additional requirements for development:
(Have a look at the Remote Toolchain wiki section)
For those requiring an IDE run
to generate the appropriate project files to allow for the emulator to be imported into Eclipse.
Doxygen documentation, found in the docs folder, can be generated from cmake/make by passing the variable DOCS=on and making the target docs .
In test.cmake a number of extra targets are provided to help with linting.
Checks for whitespaces and empty lines.
Invokes the Astyle formatter.
Warning: The default version of CMake which is installed f.e. on Ubuntu 16.04 will throw an arror when running make to setup the bin/astyle binary. Please upgrade to a newrer version manually if required:
Uses clang tidy to find style violations, interface misuse of bugs found via static analysis.
To generate a list of warnings/errors use the build target tidy_list and then view the file tidy.fixes .
Code analysis with CppCheck, focusing on undefined behaviour bugs.
Each sanitizer must be run stand alone, thus you cannot run them together.
Undefined behaviour sanitizer
The target make all_checks
will perform all checks
The binary will be created inside a bin folder. The emulator should be run from this folder becuase at the moment the Gfx libraries rely on hardcoded resource paths for things such as fonts. As such to run perform the following.
The emulator uses the signals SIGUSR1 and SIG34 and as such GDB needs to be told to ignore the signal. An appropriate .gdbinit is in the bin directory. Copy the .gdbinit into your home directory or make sure to debug from the bin directory. Such that GDB does not get interrupted by the POSIX signals used by the emulator for IPC.
If using an IDE, make sure to configure your debug to load the gdbinit file.
Note: this is experiemental and proves to be unstable with the AIO libraries, it was used during development of the emulator and provides a novel function for small experiements, it should not be used for serious debugging of the entire emulator as this will cause errors.
Tracing, found in lib/tracer is instrumented using GCC’s function instrumentation.
will include the constructor, destructor and the needed __cyg_profile_func_xxx functions that are called upon entry and exit of any functions called during the execution of the program. These callback functions are implemented to log the function, caller and timestamp of each function calls, written to a file named trace.out . As the values written out are memory offsets and, as such, are not human readable the trace dump must be processed by the script readtracelog.sh which uses addr2line to convert the memory offsets into human readable function calls, done using the memory map of the compiled executable.
Adding something like
To your code and then compiling and running the executable, after passing -DTRACE_FUNCTIONS=ON to cmake of course, you will be presented with an output similar to
After processing using the provided script sorcery, running something such as
You will see a human readable output that logs the function entries and exit made in the program
Note that the ?? visible in the output above are the result of the function instrumentation only being able to map to functions compiled using the -finstrument-functions compile flag. Extenal libraries etc are only linked against and not compiled using this flag, therefore they cannot be instrumented.
About
POSIX based FreeRTOS emulator with SDL2 graphics interface and multiple async communications interfaces, aiming to make it possible to teach FreeRTOS without embedded hardware using similar processes