FreeRTOS Приоритизация и алгоритмы управления диспетчером задач. Вытесняющий и кооперативный режимы.
Vložit
- čas přidán 4. 05. 2020
- В ролике рассказывается о алгоритмах управления диспетчером задач в операционной системе реального времени FreeRTOS для микроконтроллеров STM32. Особенности конфигурирования вытесняющей и кооперативной многозадачности.
Вышла книга по операционной системе FreeRTOS.
Видео о книге "FreeRTOS. Операционные системы микроконтроллеров" - • Книга "FreeRTOS. Опера...
Бумажная версия книги - electronics-krd.ru/magazin/pr...
Электронная версия книги - electronics-krd.ru/magazin/pr...
Оглавление книги - disk.yandex.ru/i/3ZKwKQTgQnlHoQ
Пример страниц - disk.yandex.ru/i/WCeD_CA3aMbiOQ
Группа в телеграмм - t.me/vladimir_medintsev
Код примеров из книги - disk.yandex.ru/d/Bqa2adpEZ3Mo6w
По вопросам сотрудничества - vmedintsev@yandex.ru - Věda a technologie
Желаю Вышим рукам как можно скорей дойти до экономии электропитания
Спасибо за годный материал.
Спасибо за познавательное видео. С нетерпением ждем видео по энергопотреблению.
Владимир, спасибо за очень подробные рассказы.
На ESP32 столкнулся с проблемой в RTOS, которой, теоретически, не может быть.
В Setup() создаются две задачи: одна - для считывания показаний акселерометра, вторая - для обработки данных для дисплеся. Данные с акселерометра должны считываться часто и регулярно - с частотой 100 Гц, т.е. каждые 10 мс. Дисплейная задача - не критична, к тому же она выполняется дольше.
Чтобы исключить влияние дисплейной задачи на время считывание данных с акселерометра, задачам поставлен разный приоритет: дисплейной - 1, акселерометру - 2. Обе задачи циклически стартуют по собственным таймерам; таймер для запуска дисплейной задачи выставлен на 250 мс. И в логах чётко видна ситуация, когда при запущенной, но не завершенной задаче считывания данных акселерометра, имеющей вроде бы как повышенный приоритет, всё-таки начинает выполняться дисплейная задача, сбивая время выполнения первой. Так такое может быть? Ведь по идеологии FreeRTOS, если выполняется задача повышенного приоритета, вышедшая по таймеру из блокировки задача с пониженным приоритетом должна просто ждать, пока не завершиться первая. Разве не так?
В какую сторону копать, нет идеи? Спасибо.
Ну на самом деле я бы делал совершенно другую логику. Я завел бы аппаратный таймер и заставил бы его дергать данные с акселерометра полученные данные собирать в буфер. Детали не так важны, можно DMA, можно банально выделить буфер. Многие акселерометры и сами умеют генерировать прерывание при готовности данных. А уже когда данные готовы и лежат в буфере можно использовать задачи FreeRTOS для их обработки и визуализации. При этом уже можно будет использовать и семафоры для исключения запуска нежелательного процесса и очереди если это будет оправдано.
@@VladimirMedintsev, спасибо что ответили. Но речь не про реализацию конкретного решения, а про очень странный баг FreeRTOS: задача, которой выставлен более низкий приоритет, стартует во время выполнения задачи с более высоким приоритетом и сбивает последней все тайминги.
Есть идеи, как такое может быть? Где смотреть и где копать?
Если бы во FreeRTOS остались такие баги ее никто не использовал бы. А она даже сертифицирована. Я не могу это обьяснить. Могу предположить, что все-таки ответ может содержаться вот в этой вашей фразе "обе задачи циклически стартуют по собственным таймерам" что-то в таком роде было в вашем первом сообщении. Это не совсем соответствует нормальной логике того, как надо использовать ОС. Возможно это и есть причина проблем. Я даже уверен в этом по этому и предложил свой алгоритм реализации задачи.
@@VladimirMedintsev, я согласен с Вами, что это уж какой-то совсем нереальный косяк получается. Но он есть. Пробуем разобраться.
В каком случае разблокированная низкоприоритетная (НП)задача получит время, если выполняется высокоприоритетная (ВП)? Только в том случае, если ВП-задача сама заблокируется, ожидая мютекса (а мютексы у нас там есть, это правда), например. Но ведь при этом, если ВП--задача разблокируется по мьютексу, она должна тут же забрать назад процессорное время у НП. А мы видим по логам, что пока перехватившая время НП-задача не завершит свою работу, ВП-задача выполнение не продолжает.
Настоящий детектив.
Спасибо за годный материал и отличное видео. А может вообще снять ролик о портировании FreeRTOS на контроллер? Зачем использовать, то что где-то уже кто-то "поковырялся"?
спасибо.
Енергозбереження актуально взагалі: вибір між декілька елементами 18650 чи автомобільним акумулятором очевидний.
@@dmitrysnegiryov Он пишет что энергосбережение актуально и выбор между несколькими 18650 или автомобильным аккумулятором очевиден. Большая просьба, давайте не будем цепляться к языку.
Спасибо за ролик. Но пока малопонятно.
Хотелось бы понять в чем особенность различий между кооперативной, вытесняющей и гибридной многозадачностями, может как табличка рядом.
Кооперативная поток (thread) сам отдает управление ОС (вызовом определенных функций) и в это время ОС переключает потоки. В случае если такой поток завис, другие потоки никогда не получат управления. Вытесняющая: ОС по таймеру (прерыванию системного таймера) либо по прерыванию от устройства сама отбирает у текущего потока время и передает его другому потоку (по приоритету). Зависший поток не влияет на другие потоки.
@@drone_tales Спасибо!
Интересно, ваш контент на русскоязычном ютубе уникальный. А есть общий обзор FreeRTOS?
На канале много роликов по этой ОС. Плейлист посмотрите и наверняка найдете, мне просто не удобно с телефона ссылки давать.
Спасибо за познавательное видео. Интересно было бы узнать использовали ли Вы FreeRTOS в своих рабочих проектах и с какими проблемами сталкивались? От себя скажу, что был опыт создания достаточно большого проекта с использованием ОСРВ FreeRTOS и было выявлено много подводных камней, о которых мало кто рассказывает. Например таких, как выбор оптимальной схемы выделения памяти, а их к слову штук пять, определение необходимого размера стека памяти под каждую из задач, определение оптимального времени переключения планировщика задач. Решение всех этих на первый взгляд простых, а на самом деле нетривиальных задач, не самое простое занятие, если конечно речь идет об оптимизированной системе, где важна скорость ее работы, потребление и производительность. Это я к тому, что Вы достаточно много рассказали о преимуществах использования FreeRTOS, но не в одном из видео не упомянули о недостатках, а они все же есть.
В принципе в самом начале использования были не подводные камни, а скорее наше недопонимание логики работы данной конкретной ОС. После того как мы капнули поглубже стало легче. Одна проблема ушла с переходом на 10ю версию простым обновлением поверх старой. А так я уже делал видео где рассказал и о том как стек контролировать и загрузку процессора измерять. Этого в принципе хватает для адекватной отладки.
Сейчас CubeMX активно навязывает cmsis-rtos, это обёртка вокруг rtos, хотелось бы про нее услышать мнение. Есть ещё Keil RTX5 и набирает популярность, как я понимаю, основанная на ней arm mbed, может стоит на них посмотреть, обозреть. Если первая, это что-то похожее на FreeRTOS, то вторая, прямо монстр, всё настолько обернуто, что писать легче чем для Ардуино, извините:) Плата за это, очевидна, объем кода.
Не могли бы снять видео, о там как написать свой переключатель контекста на f4?
Что такое переключатель контекста?
@@VladimirMedintsev это механизм сохранения регистров, при переключение задач, для вытесняющего планировщика, например.
Теперь понятно, не понятно зачем его писать. Есть же FreeRTOS или штук 10 других операционных систем. Я к тому, в чем будет смысл этого видео?
Просто если кому такой планировщик нужен надо взять файл из FreeRTOS и его код оттуда вырезать. Там не много и комментарии хорошие.
@@VladimirMedintsev смысл видео будет в том, чтобы показать, что имеено делает ос, при переключении потоков, что у мк есть свое собственное прерывание(аппаратное) для ос, как организовать стэк, как пользоваться MSP и PSP регистрами, что у f4 например есть 2 режима работы, thread и hande. Просто информации об этом в интернете очень мало, пару статей на Хабре, а вопросов много.
Важные моменты законспектировал. Но так не понял чем достигается снижение потребления. Тем что в фоновом режиме мы можем заблокировать фоновую задачу?
Тем что во время простоя мы можем отправить микроконтроллер в режим низкого энергопотребления (грубо говоря в сон). Или мы можем снизить его тактовую частоту. Я же сказал что в видео о энергопотреблении ничего нет, оно о многозадачности и не более.
Тем что вместо циклов с поллингом флага - ожидание события. А это уже можно реализовать аппаратно (без затрат на выполнение кода).
@@vitalypuzrin Я понял. Так как процесс idle нам не доступен, то вместо него фоновым становится процесс пользователя. В котором мы можем настроить stm.
@@user-le7cf1qk8l Не совсем так. Шедюлер не будет дергать ни один таск, пока эвент не прилетит. То есть когда все таски не активны, будет standby. На idle я бы вешался наоборот, чтобы не морозиться - для уменьшения бросков тока.
Пытаясь изучать по нескольким публикациям, как первый пример всегда дается непрерывная задача, где задержка выполненна в виде цикла FOR. Создается 2 задачи, одна выводит "Task 1" вторая "Task 2". И потом рисунок, терминал в котором чередуються task1 task2 и комментарий смотрите, 2 задачи с одинаковыми приоритетами выполняються по очереди.
Еще ни разу не получилось добиться результата как в примере, разве что задача запущенная первой, и редко проскакивает запущенная второй. Приоритет у задач установлен одинаковый, пробовал настройки кооперативной и вытесняющей многозадачности.
Может сообщения не успевают выводиться в терминал ?
Владимир, Вы не ответили на вопрос, который Вам задали в видео "Пару слов об обеспечении надёжности", поэтому я позволю себе Вас спросить ещё и здесь. Подскажите, пожалуйста, книгу или книги по современной схемотехнике для начинающих. А то Вы там раскритиковали книгу, которую предложил один из Ваших зрителей, сказав что автор застрял в 80-х, а свой вариант не предложили. Заранее, спасибо. Извините, что не в тему.
Я наверное сейчас буду выглядеть старпером. Но есть книги авторы которых стараются много лет идти в ногу со временем. Если нужны хорошие знания, то я предложил бы книгу "Искусство схемотехники" Хоровиц Пауль, Хилл Уинфилд. К сожалению из-за крейне низкого спроса на русскоязычную техническую литературу а также из-за того, что нашему государству в принципе абсолютно наплевать на уровень подготовки инженерных кадров последние издания этой книги на русский язык так и не переведены. Это экономически не выгодно без государственной поддержки. По этой причине последние издания, в частности Х-часть с рассказами о цифровой электронике на русском языке не доступно.
Ровно по этой же причине я и не ответил на данный вопрос ранее. Хорошие, современные книги на русский язык не переводятся т.к. это не окупается.
Однако вы можете начать чтение и изучение предмета с любого доступного вам издания данной книги. Там хорошо изложены все моменты. Это хорошая - классическая книга. Она правильно ставит мозги на место.
ИМХО: Без старых схем, не возможно понять современную схемотехнику, поэтому для начала 1000 и 1 схема (оба тома).
Далее на сайте TI есть учебные пособия (правда на английском), по разработке современных схем. Кстати, там есть очень интересные решения.
Так же можно посмотреть аналогичную инфу на аналоге.
FreeRTOS: добавил 6 задач равного приоритета к графике - и скорость прорисовки экрана упала в 7 раз.
EmbOS: добавил 6 задач - и всё летает как прежде, а функционала больше.
Ос основанная на приоритетах - требует выполнения кода здесь и сейчас, до упора.
Ос основанная на потоках - требует готовности данных к назначенному сроку.
Вся разница в задержке реакции на внешнее событие. В приоритетной ос эту задержку колбасит по любому поводу. В потоковой ос - критическая задержка рассчитана заранее. Система обрабатывает данные когда может, но к моменту когда они будут нужны - расчёт уже закончен.
Разница в способах обработки данных накладывает отпечаток на требования к мощности оборудования. Для приоритетной ос требуется более мощный мк.
А она же платная.
AVI-crak Home без понимания того что вы делаете никогда не получится нужный результат. Никто никогда не говорил что rtos должна работать быстрее - обычно как раз наоборот. Разница лишь в том, что RTOS может гарантировать именно максимальное время(верхнюю границу) выполнения задачи и не больше. Это имеет смысл если вы работаете с критичными по времени выполнения задачами(манипуляторы, звук, самолеты и пр.). Если вам не нужна гарантия максимальной задержки то и смысла особого нет. Яркий пример это ядро линукса - если посмотреть гистограмму времени выполнения всех потоков, то в среднем они пролетают всего за несколько тиков, но есть хвост в котором ядро застревает на сотни. При применении рт патча среднее время выполнения на той же гистограмме вырастает, но хвосты , которых ядро может долго находиться, пропадают.
Следует помнить, что слово поток в русском языке иногда сбивает с толку - это и stream и thread. Не просто так в среде rtos потоки(threads) называются задачами
@@MihailDenisov Да бесплатная (вроде). Но закрытый код тут. Неужели настолько плохо, что приходится закрытый вход в контроллер пихать??
@@projectlotus5815 Разница в том на что упоминается явно. В потоковой ос все активные задачи выполняются последовательно, прямым перебором, каждая получает свой квант времени. То-есть ос это простой переключатель задач. Приоритет - это время которое задача будет выполняться. При этом одного таймера уже недостаточно, нужен дополнительный - который будет отчитывать ровные 1мс для задержки.
Пустые циклы ожидания флага (или события) в такой ос недопустимы, задача должна проверить своё состояние - и отдать управление если ей больше нечего делать. Такие проверки намного дешевле в программной и смысловой части, проверяется тут и сейчас - а не там где-то далеко.
Таким образом получается что мк постоянно выполняет полезный код со 100% нагрузкой.
А вот если ничего полезного не набирается между вызовами системной задачи - то последняя уводит в сон ядро на полное время, без ускоренного переключения. То-есть, если мк нечего делать - то экономия энергии всё-же случается.
Если для такой ос делать полное логирование - то затраты на сам лог могут превысить полезную нагрузку. Потому как там нет красивых кубиков с ровными краями, график будет похож на мелко нарезанную лапшу.
Подскажите пожалуйста, а если мы хотим, чтоб задача выполнилась полностью операционкой (например получение данных) и мы не хотим уходить в диспетчер задач, пока не выполним ее. Есть такая функция?
Заборонити переривання?
Конечно. Есть функция обозначающая критически важные фрагменты кода. Вы можете обозначить какие участки нельзя прерывать.
vTaskSuspendAll();
"Приостановка (или, иначе говоря, блокировка) шедулера
Критические секции могут быть также созданы приостановкой шедулера. Приостановка шедулера иногда также известна как 'блокировка' шедулера.
Обычно критические секции защищают область кода от доступа со стороны других задач и прерываний. Критическая секция, реализованная путем приостановки шедулера, защищает область кода только от доступа других задач, прерывания при этом останутся разрешенными.
Критическая секция, которая слишком длинная для реализации путем запрета прерываний, может вместо этого быть реализована путем приостановки шедулера, однако возобновление (отмена приостановки) шедулера может быть потенциально относительно долгой операцией, так что для каждого случая нужно тщательно проанализировать, какой метод лучше использовать."
microsin.net/programming/arm/freertos-part4.html
DS88579 Спасибо большое за ответ и ссылку! Прочитаю все части этой статьи
Пожалуйста,скорее вернитесь к FREE RTOS.
Основные темы по FreeRTOS уже есть на канале. Просто посмотрите соответствующий плейлист.Видео на эту тему более чем достаточно. Не раскрыта только тема семафоров, но в повседневной жизни они по сути не нужны.
@@VladimirMedintsev Все посмотрел залпом! все очень понятно и доходчиво. Интересна специфика и лайфхаки) Также с приоритезацией можно ещё немного с примерами рассказать. Там сложновато.