Как раз сейчас и решаем схожую задачу, используя RTOS: нужно быстро и часто опрашивать акселерометр, анализировать полученные данные, при этом управлять контроллером электропитания, что-то периодически (хотя бы 4 раза в секунду) обновлять на экранчике и при этом обмениваться с сервером информацией через очень медленную LoRa. Задачи слишком разного масштаба времени. Можно, конечно, самому городить семафоры, очереди и т.п., но если это уже всё сделано во FreeRTOS, то зачем изобретать велосипед?
Тем более, что прерывания тоже никто не отменял. Например, под опрос акселерометра сделать задачу с семафором, а открывать семафор -- в прерывании по окончании чтения.
Спасибо за доступную подачу информации. Пока сижу на AVR, делаю хобби-проекты. Крайний проект, после реализации на AVR, с помощью вашего канала планирую перевести на STM32. Еще раз спасибо и надеюсь что терпения на развитие канала Вам хватит, а в том что сумеете подать актуальную информацию в доступном ключе-у меня сомнений нет.
Хватай на али "stm32f103c8t6 board" + прогер-отлдачик "STLink2" за 100р. Качай CubeMX + Keil5, 2копиасты кода, 5 кликов мышки и проект готов :) А не заработает, врубай пошаговую отладку как белый человек и смотри где ступор
Ну я прямо не знаю сколько тонн лайков надо ставить))) Сам с FreeRTOS уже 5 лет работаю в коммерческих проекта и глубоко убежден, что что-то серьёзное сделать без оной можно но ОЧЕНЬ сложно.... А Вы так доходчиво народу объяснили что да как и по чём)))
@@Wo_Wang есть разница между "не обойтись" и "некомфортно работать". Проще - с операционкой, как минимум протокол общения (поверх стека USB) я бы выделил в отдельный процесс.
Priviet Vladimir, I would say that your videos should be in everyone's who is interested in electronics's playlist. For me, you saved tons of hours with my personal projects. Recently I started working on FreeRTOS. I think you should keep on this topic more because there is a lot of applications where it can be used. Also logic behind RTOS is really suitable for industrial automation field where applications is more time critical. Keep on doing this! It's really helpful! Greeting's from Lithuania.
@@VladimirMedintsev in my opinion all the most informative tutorials are made by Russians. I know Russian language too as we were the part of Russia so for me it is easier to understand. Anyway keep on doing these videos and maybe if you can more on freeRTOS :)
Кстати, Владимир, Ваше видео дало мне повод задуматься, что возможно нижеописанную мною проблему можно реализовать с помощью FreeRTOS. Вы мне дали повод для размышлений и изучения FREERTOS.
Классно 👍👍 спасибо вам за данное видео... Я когда кодил под Ардуино, пытался реализовать что-то подобное. Пытался написать ОС для микропроцессоров, но мои навыки программирования на чистом C не позволили сделать подобную ось (более 3 лет разрабатываю программы на C++/C#), а тут есть готовый велик, как говорится "садись и едь!".
Вставлю свои пять копеек, 1) Там где вы вставили switch case в while(1), и говорили, что нужно долго дожидаться пока Program Counter дойдет до нужной обработки после прерывания, но вы же можете в этом прерывании ставить флаг, который скажет, в какой из кейсов переходить после прерывания и обработка после прерывания будет быстрее. Во freertos же надо придется дожидаться когда PC дойдет до задачи которая должна обработать после прерывания. 2) Для процессоров типа stm32F0 , на мой взгляд, freeRTOS жрет много оперативки, в отличии от тех же конечных автоматов, где 2 байта идут на запоминание состояния где мы были. Спасибо за качественный контент.
Спасибо, я с первого раза понял преимущества ос. Тут получается хороший мултитрединг, каждый таск получает своё время. На интерапты хорошо и сразу можно отреагировать. Заказал себе микро контроллер, попробую...
Примерно к такой же структуре программы я и пришел лет 20 назад, с таймерами и флажками, после 2-х летних изысканий. Задача: упаковочный автомат с 2-3-4 весовыми головками(CAS). Контроллер: fastwel CPU188-5. Правда, RTOS-ов тогда ещё не было... ☹ Гы: зато, ещё был MS-DOS 6.22, на этой плате! 🙂
Не понимаю тех, кто не хочет использовать FREERTOS, даже тогда, когда ситуация позволяет. Например, очередь - это очень крутая вещь. Можно в обработчике прерываний заталкивать туда данные и когда у задачи появится время, она их обработает, извлекая из очереди. Данные можно даже получить из неё не извлекая их из неё. Такое очень даже пригодится, когда на одни и те же данные нужно реагировать нескольким задачам. Еще круче получается с несколькими источниками данных для очереди. Например, одна задача окрашивает кнопки и помещает коды нажатых кнопок в очередь. Задача, отвечающая за работу с GUI получает их и обрабатывает. А теперь нам захотелось управлять GUI с помощью пакетов, приходящих с UART. Создаём задачу, которая принимает эти пакеты, извлекает из них команды и помещает их в эту же очередь. Так вот, сильно не напрягаясь и не затрагивая кода GUI, мы добавили еще один "пульт управления". И таких вот фишек там масса.
Я не хочу :) т.к. нашел куда круче RTOS2 RTX5 - родная ARM ось, ХАЛЯВНО включена в CMSIS2 !!! НЕ ОБРЕЗАННАЯ как все GNU "халявные" как FreeRTOS или ChibiOS хочешь полную и надежную ПЛАТИ! Открытый код!. портирована в IAR и GCC, работает не только в платном Keil5 в CMSIS2 есть шаблоны под потоки, таймера итп, подключается быстрее чем фриртос из куба. И к ней есть EventRecorder классная GUI консоль для отладки в Keil5 (галочки не забудь расставить, а то будет пустой график) Попробуй!
А ещё по прерыванию можно разбудить процесс,выполнить что то и усыпить ) Вообще более правильный вариант использования ос будет в комбинации всех доступных возможностей - ос+прерывания+дма
С freertos вроде все удобней , но вот появилась задача управления шаговыми двигателями и обработкой энкодеров и тут столкнулся с затруднениями генерации импульсов для ШД и обработкой прерываний от энкодеров.
Посыл конечно понятен. Не понятно только, почему по мнению автора есть только 2 альтернативы: последовательный код и freeRTOS(или любая другая RTOS). Для 99% задач которые делают на стмках, хватит банальной event-driven системы, в отдельных случаях вкупе со стейт машиной. И первое и второе пишется за 30 минут и занимает минимум места. RTOS это хорошо, но это чаще всего стрельба из пушки по воробьям. Не надо так.
Я новичок с 12-ти летним стажем...и половину слов не умею реализовывать"event-driven системы, в отдельных случаях вкупе со стейт"... в дальнейшем научусь, но ОС доступный инструмент int_32t, забивать гвозди в int_8t!
Было бы интересно увидеть видео разбора крупной программы, как в ней использовался FREERTOS и какие опасные моменты нужно учитывать. Вроде штука интересная, но как и где ее стоит применять все равно не очень понятно. В маленьких программах ради удобства - притянуто, маленькую программу как ни пиши - проблем нет никаких. В больших - можно кучу не отлавливаемых интересностей словить - стремно использовать. Вообще контент на канале достойный. +++
вот как раз операционная систем и нужна для отлова интересностей. Операционная система имеет средства контроля за работой процессов и имеет средства управления памятью. При использовании ОС есть недостатки - это потеря в скорости реакции и использование большего объема памяти. За это програмист получает возможность управления потоками, профилирование, отладку запущеной системы.
актуально. нужно на практике показать сколько сьедает ОС ресурсов. считаю по умолчанию ОС много сьест. для меня актуальным примером будет приложение электропривода на 4-5 задач на 1-10 кГц. а так конечно ОС будет удобно использовать. а у тена с бочкой воды постоянная времени 20 минут или 1 час. с теном можно и виндос использовать ;)
У меня в usart по дма иногда пропадает посылка на прием при использовании freertos, точно такой самый код, но без операционки, за ночь при тесте модбаса дал всего лишь две ошибки при 256000 кб/с, не знаю, плюс для реализации canopen нужно прерывание 1мс и проц stm32f407vet6 не может обслужить программу где одновременно используется 5 интерфесов и 200 кбайт кода...принял решение отказатся от операционки
Все эти ртосы очень напоминают ардуину. Расточительно, но может пригодиться при унификации подключаемых к проекту модулей: вставили INIT и все остальное модуль запустит. Именно так пишут свои примеры разработчики микроконтроллеров, например, STM. Основной недостаток - все это очень медленно. За время переключения с одной задачи на другую, в моих проектах успевают выполниться все мои задачи. При переключении диспечер сначала обрабатыыает все очереди событий, выбирает задачу, потом собирает чемоданы от текущей задачи и распаковывает для следующей. Я пишу сложные многопроцессорные приложения с обработкой звука в реальном времени, комуникацией, графикой, вложенными прерываниями, распределением приоритета и т.д. Мой опыт работы 27 лет. Применение ртос не оправдалось нигде. Все решается проще.
Насчёт тайминга действительно это просто недопонимание. На то она и “real time” ОСь, что её цель именно выдерживать детерминированный тайминг задач. Нужно только указывать им приоритеты и будет тайминг что надо. На ютубе есть видео с презентацией FreeRTOS от автора - там он отлично это поясняет. Конечно, могут быть какие-то другие причины не использовать RTOS. В каких-то супер-критических и супер-embedded задачах может будет необходим 1 контроллер на 1 задачу (или 1 PLC на задачу, если это совсем что-то суровое). И, конечно, если ваш код не сложен и не предвидится его развитие, то действительно нет смысла заранее заморачиваться с ОСью. Но тайминг это как раз не проблема для RTOS, это её работа 🙂
19:00 Забавный диалог... - При чём тут операционная система, когда нужны жёстко заданные тайминги? - При чём тут жёстко заданные тайминги, когда нужна операционная система???
При рассказе последовательности загрузки МК, Вы еще пропустили что будет с начало вызвана функция, так сказать инициализации языка С, называется она в Вашем случае __main(), а вот она уже затем вызовет пользовательскую функцию main(). На ББ в этой функции "__main()" как правило происходит статическая инициализация данных и инициализация стандартной библиотеки С ...... для МК скорее всего аналогично.
@@VladimirMedintsev нет конечно, просто Вы подробно начали рассказывать про цепочку вызовов, и при виде ассемблеровского вызова функи __main() в Вашем видео, почему то сразу перешли на main(), а мне просто это бросилось в глаза )) и я решил поделится с Вами инфой об этом. Я ни в коем случае не хотел вмешиваться в Ваш рассказ, а просто восполнить для Вас данный пробел. Но если Вы и так знали про это - то и отлично, извините меня за это программистическое занудство ))
@@VladimirMedintsev Влияет непосредственно, если использовать для инициализации статических переменных вызовы каких-либо функций, самое распространённое - при статическом создании объектов С++ вызываются конструкторы классов. Иной раз по невнимательности можно схлопотать HardFault не добравшись до точки входа main(). По-моему инициализация - достаточно важный вопрос, чтобы его упомянуть, хотя бы одним предложением.
@@OlegKotchetov Можете хоть один, ну хоть вшивенький пример инициализации хоть чего-нибудь привести чтобы схлопотать HardFault не долетая до main. Ну хоть какой - нибудь примерчик.
@@VladimirMedintsev Пожалуйста: 1. Слепить класс, у которого в конструкторе присутствует обращение к периферии через HAL, надеясь, что создавать его объекты будут всегда _после_ инициализации HAL. 2. В угаре очередного горящего дедлайна вспомнить, что когда-то был такой отличный класс, который делал то, что нужно, скопировать его в проект и воткнуть статическое создание экземпляра, что-нть типа extern I2C_HandleTypeDef hi2c1; static I2C_SuperSensor sensor = I2C_SuperSensor(&hi2c1); А потом удивлённо смотреть в дебаггере на немедленный HardFault при запуске. Да, разумеется, это адский быдлокод и тот, кто так сделал - сам дурак. Но поверьте, ситуации бывают разные. Иногда приходится сознательно быдлокодить, когда на постройку башни из резной слоновой кости нет времени, задача копеечная и требуется чтобы результат сработал раз-другой и дальше станент не нужен. Да лучше за такое не браться, но иногда и отказать нельзя. Если Вы занимаетесь этим делом на потоке, наверняка сами прекрасно понимаете. А может новичок подобное слепит по неопытности и потом мозг сломает, пытаясь понять, что, блин, происходит :) Вот для последних как раз помянуть про фазу инициализации статики - методически оправдано полностью имхо. А то ведь зачастую смотрят на компилятор, как на чёрный ящик: на входе исходник, на выходе - светодиод моргает, а что там между - черт его знает...
Я сейчас пишу программу, так уж вышло, для AVR архитектуры (Atmega168) и меня эта туева хуча конечных автоматов уже успела достать. На I2C два устройства - делай аатомат. UART - делай автомат. Опрос клавиатуры и генерация событий - делай гребаный автомат. Короче, для всего, что может впустую застопорить главный цикл - нужен автомат. Я настолько упоролся этими автоматами, что даже для записи в EEPROM хотел его слепить, но остановило то, что запись ест немного тактов, а транзакции туда короткие. Погоня за быстродействием быстро сожрала половину ПЗУ. С RTOS все это безобразие было бы гораздо проще.
@@DmitryKandiner Проект уже окончен. В нем обширный GUI. Места, возможно, не хватит. Но можно попробовать. Ибо FreeRTOS туда прямо просится. На I2C шине сидит кучка периферии, активно задействуется UART и GUI хочется без тормозов. Памяти всё это сожрало намеренно (13 КБ ПЗУ и 400 байт ОЗУ), но при этом нет тормозов, камень всё успевает и код пригоден для дальнейших доработок и дополнений (модульный принцип). Остался килобайт на маневры в будущем и ещё два заняты бутлодером. И самое смешное - для оптимизации объема, некоторым функциям пришлось ставить атрибут no_inline. На производительности это не сказалось практически никак, но сэкономило целый килобайт ПЗУ. Чем глубже лезешь, тем больше сюрпризов от компилятора AVR GCC. Даже в таких вещах, как макросы и константные числовве выражения. Они все имеют тип int, который размером 2 байта в AVR. И когда выполняешь операции над переменными int32 и константами, компилятор без предупреждения приводит int32 к int (16), что у неподготовленного адепта Механикус может вызвать чувство вины перед Омниссией. 🤣
@@kardanium рекомендую посмотреть на st. Все что вы описали делается с использованием директ мемори аксесс и вообще не жрет ресурсы. А граф интерф делать на главном камне некашерно даже на неспециальнвх st. Есть же готовые с управлением по usart
Здравствуйте! Мне очень интересны автоматы, я сам на них пишу, но пока очень не опытен в этом деле. Можете ли вы поделиться кодом проекта, чисто в образовательных целях?
Процессор - это часть микроконтроллера, какой тут может быть спор вообще? никто же не спорит как правильно: компьютер или процессор, если процессор - это часть компьютера. микроконтроллер, помимо процессора, включает в себя постоянную память, оперативную память и прочую периферию, если бы он её не включал - был бы просто процессором, а так микроконтроллер. если речь про работу процессора - можно сказать и процессор и микроконтроллер, т.к. он этот самый процессор содержит. а вообще если человек спорит о таком - это говорит о его полной ограниченности, ведь важно не выбранное слово, а суть за ним стоящая, можно хоть хуёвиной его называть - лишь бы было понятно о чём речь!
@@alextiga8166 , конечно, не всегда понятно, потому, и желательно следовать правилам и договорённостям, что бы не было неразберихи, а не называть всё вокруг хуёвинами. Его право называть микроконтроллер как он хочет, моё право, его поправить.
@@Vlad_4572 можно сказать "компьютер выполняет программу", а можно сказать то же самое про процессор. Можно сказать "автомобиль потребляет топливо", а можно сказать то же самое про двигатель. Так в чём проблема с "микроконтроллер/процессор выполняет инструкцию"? И то и то правда, процессор - часть контроллера. Никто не называет микроконтроллер процессором, но когда речь про часть микроконтроллера которая является arm процессором - и так и так правильно. Или я в чём-то ошибаюсь?
@@alextiga8166 , его дело, как и что называть, но автор не очень хорошо отозвался о тех кто его поправляет и привел пример комментария, типа: вот, смотрите написано же, что это процессор! Так никто и не спорит, что ЭТО(cortex-m) процессор/ядро. Но он упоминая устройство, говорит - процессор. Ты разницу понимаешь? В мануале всё чётко написано, что есть что, не пойму, в чём прикол подменять понятия?
Хах, всё то у вас просто получается, как в примерах аля "помигать светодиодом". А не забыли ли вы упомянуть про тонкости синхронизации данных (в которых нужно в принципе иметь хорошие скилы в многопоточном программировании), трудно отлавливаемые дедлоки, тонкости вызова функций ос в контексте прерываний? В небольших проектах freertos никак не оправдан, всегда можно сделать систему событий, софтовые таймеры и практически всегда работать в контексте главного цикла и не заботиться о синхронизации. Вот реально freertos может быть оправдан там где куча долгих синхронный операций, например работа с bsd сокетам (интерфейс которых эмулируется через lwip) - да тут код будет куда короче и стройнее чем работа асинхронно.
Золотые слова, вот и я о том же. Автор видимо никогда многоточечных приложений не писал. А дедлоки это еще и меньшая из бед(ее изобразить сложнее), хоть и очень противная. А вот логика работы, не так как задумал - легко. И не обязательно гонки переменных, просто выполнилось не в той последовательности или данные разрушила, или обратилась к полупустому указателю и так далее. Тут занимался оптимизации одного своего проекта. Нашел ошибку, а суммарный аптайм десятки лет(всех экземпляров), не проявлялось только потому, что ошибка четная, т.е. их 2, вторая маскирует первую... А критическую секцию туда нельзя, слишком "тяжелая" даже для сервачных процов, а тут МК, хи-хи. Весь рак мозга начинается когда нельзя сильно обкладывать в кретические секции, да если все ими обложить - нахрена козе баян(вообще многопоточность)
Правило одно вы должны провести внутри обработчика как можно меньше времени. А это значит не делать задержек, не использовать таймауты. Чем быстрее выйдите из обработчика, тем лучше.
@astrahard Нечаев Вы сами читаете что пишете? Я сказал человеку, что в обработчике прерывания необходимо проводить минимум времени, это является безусловным требованием. Т.к. в любой момент может наступить новое прерывание от любого другого источника. Что в конечном итоге приведет к переполнению стека. Отсюда логично и требование не использовать таймаут и задержки в обработчике прерывания. Более того, это не мое личное придуманное мнение. Ровно то же самое можно прочитать в документации на FreeRTOS и также во всех известных мне учебниках программирования. Более того обработчики прерывания в пределах одного уровня приоритета друг друга не вытесняют. Так что осторожнее с оценками, пожалуйста.
@astrahard Нечаев Прежде всего я опираюсь на написанное в документации по FreeRTOS, а там прямо указано что обработчик должен быть как можно короче по времени, чтобы прерывания не накладывались друг на друга. Тут без разницы у вас микроконтроллер или большой компьютер. Система прерываний она не меняет своего смысла. Во-вторых я руководствуюсь написанным на сайте Cortex это как бы разработчик ядра микроконтроллеров. Ну а в третьих, programming manual на наши микроконтроллеры. Но если все это не заслуживающие внимания документы, то не проблема снимаю шляпу. Вы видимо великий специалист и знаток вопроса. Даже спорить не буду.
Не претендую на истину, а лишь выскажу свое личное мнение. Мне кажется что писать с использованием RTOS можно только при соблюдении некоторых факторов : 1. Вы умеете писать работоспособный код и без нее и поэтому хорошо понимаете плюсы и минусы данного подхода. 2. можно писать с ней если приоритеты прерываний кажутся чем-то маловажным для вас и вы никогда не гуглили ответы на свои вопросы фразами типа "interrupt latency" и не считали такты(да да , в некоторых задачах на 100-180Мгц тоже приходится это делать и не по приколу, а по необходимости). 3. проект чисто домашний и можно смело брать самый "жирный МК" и не думать о его стоимости. Если новички читают это, то просто поймите - RTOS это просто один из подходов к программированию - иногда оправдан, иногда нет, все зависит от ваших задач. Ну а сам ролик нормальный.
Да вы озверели чтоли, новичкам много поточное приложение писать... Со всеми гонками переменных и прочими прелестями асинхронности. Это 90% программистов вообще не умеют. Ибо в 90% случаев не нужно.
@@VitaliyRu ну по моему мнению - в 90-95%(а вообще и больше) использование ОС на МК тоже особо и не нужно. ОС нужно в других устройства, где чуть выше уровень и другие вычислительные возможности. обычно примерно так: система где есть 1) устройство на линуксе + 2) устройство на МК. линукс с ОС для вычислений, МК для связи с датчиками и ИМ. как то так. Новичкам (и не только )лучше RM читать , книжки по Си и Хоровица + практика практика практика. Я уже не совсем новичок, но все равно повторяю по кругу эти действия :) А кто хочет просто побаловаться "миганием лампочкой" и сделать это без особых затрат(умственных и временных) и забыть как пропадет интерес - ардуино будет идеально вариант и все эти ОС нафиг не нужны.
@@tx-rx По мне так тоже. Либо линух, винда и тому подобное. Либо по стараинке в петле с прерываниями(там своей боли хватит :) Их к слово по возможности лучше тоже избегать. В видео описана задача которая прекрасно выполняется последовательно(это не только МК касается, но и той же винды), а ее предлагают сделать асинхронной. Выше я там уже Рихтера цитировал "В общем, мораль этого вступления такова: многопоточность следует использовать разумно. Не создавайте несколько потоков только потому, что это возможно. Многие полезные и мощные программы по-прежнему строятся на основе одного первично го потока, принадлежащего процессу "
@@tx-rx за Хоровица отдельный привет и спасибо, дядька знатный и дай бог ему долгих лет жизни. Я после окончания университета его до сих пор перечитываю и каждый раз нахожу новое!
Согласен. Я на асме пописываю для АВР ок, как попробовал кооперативную РТОС (от di Halt,) так в "суперцикл" и не тянет. В разы проще и в написании и в отладке
Вот такой вопрос. Если представить что у нас есть 2 задачи freertos с одинаковым значением vtaskdelay допустим 100 мс для обоих. То при таком раскраде как эти две задачи будут работать друг относительно друга? Если речь идет о автоматическом распределении процессорного времени то будет вызываться перавая задача а через 50 милисикунд вторая а потом еще через 50 снова первая. Или же как то иначе? Какую логику преоритезации задач несет в себе это "автоматическое распределение процессорного времени"?
vtaskdelay определяет какое время диспетчер задач не должен передавать управление данной задаче. если у вас 2 задачи и они обе через osDelay указали что их не беспокоить 50 миллисекунд, то ближайшие 50 секунд будет выполняться только idle, а потом опять задачи 1 и 2 по очереди.
Да. Почти так. Но еще нужно учитывать что эти задачи будут делать. Если внутри есть полезная нагрузка отличная по тактам от другой, то циклы будут перескакивать. И отдельный вопрос как они были запущены одновременно или например 1 сразу вторая через 50 мс. Если сразу то так и будет t1 0, 100, 200, 300, 400 t2 0,100,200,400. Если с задержкой в 50 мс то t1 0,100,200,300 t2 50,150,250,350. А вот если внутри задачи t1 будет работы на 25 мс, а в t2 на 10мс то будет следующая картина при условии что ос вытесняющая. t1 0-35, 135-160, 260-285 t2 0-20,120-130,230-240 и т.д. Т.е. в тех местах где активная работа обеих потоков задачи выполняются (условно)одновременно но в два раза медленнее по времени. Отсюда вывод. Через какой-то промежуток времени задача 2 сделает на какое-то колличество циклов больше, потому как нагрузки у неё меньше.
Спасибо за доклад. Очень долго заглядываюсь на FreeRTOS. Понимаю, что на вопрос тяжело ответить однозначно из-за весьма размытых границ и всё же. Есть ли у вас какие-то свои критерии по которым вы решаете стоит ставить FreeRTOS или не стоит ? Буду очень благодарен конкретным примерам . Заранее спасибо
Вот сидите вы такой и с философским (обязательное условие) взглядом обращенным на облака обдумываете свою программу. Так вот если она рисуется вами как единая задача, то применять FreeRTOS НЕ НАДО. А вот если у вас в голове вырисовываются несколько процессов или подзадач, то применять FreeRTOS НАДО.
У меня принцип такой: если оперативы в контроллере 8кб и более, значит надо. Если 4кб - может быть. Все равно со временем нагородишь самодельный ее аналог худшего качества.
@@Wo_Wang при разработках важно правильно понимать что ты хочешь сделать и правильно ставить задачу. Мне не нужна многозадачность, мне нужно изолирование друг от друга потоков кода, выполняющих разные задачи в устройстве, мне нужна возможность легко тасовать эти потоки, не нарушая работу всего остального, мне нужно чтобы программа оставалась линейной и простой так долго, как это возможно. ОС дает мне все это. Я уже сталкивался при разработках с ситуациями, когда городил жуткий код чтобы в итоге он сделал тоже самое, что доступно из коробки под freertos. Самый ценный ресурс - время. Мегагерцев и мегабайтов полно, времени, обычно - нет.
Доброго дня. Спасибо Вам большое за познавательные видео. Только начинаю разбираться с Freertos и хотелось бы немного Ваше консультации. Пытаюсь большой проект адаптировать под ОС. Вот подсоединил через куб ОС, раскидал легкие задачи по приоритетам и таймигнам вызова - все очень хорошо, функционал заработал. И вот у меня есть большая функция расчетов, сей кусок кода занимает около 30кБ. Естественно, когда я эту функцию кладу в задачу у меня все вешается. Как мне его положить в Tasks? или вообще что мне делать? Расширять размер стека для данной задачи, как я понимаю? Спасибо.
А эта freeRtos под капотом что-то вроде невытесняющей многозадачности с прерываниями по таймеру реализует, правильно понял? Т.е. если в какой-то таске, например, что-то зависло, вся система зависнет, как оно в мсдос было? Или там как в посикс с fork() / еxec(), таблицей процессов и т.д.?
@@Влад-с7к5й В видео th-cam.com/video/wTK11IDpg7s/w-d-xo.html я рассказываю как определять загрузку процессора задачами, этот алгоритм можно использовать и для определения зависшей задачи. Ну или можно проще. Можно чтобы задача сама обновляла какой-нибудь флаг и тогда уже можно принимать меры к ее перезагрузке или лечению.
На ESP32 хотел изначально использовать или библиотеки Arduino, или напрямую язык Си, но как выяснилось что компания Espressif в своих библиотеках всегда использует FreeRTOS. Так зачем мне изобретать то что уже и так эффективно работает. Тем более что для 2-х ядерного процессора лучше использовать ОС, которая упрощает работу с железом.
@@mvxburov Мне почему-то не удалось его завести на Visual Studio 2019 и опробовать. А так бы сказал что он компилирует, ассемблерные выходные листинги я отлично понимаю.
В целом верно, но только примеры выбраны неудачно. Из-за этого объяснения выглядят не очень убедительно. Нельзя объяснять преимущества многопоточности на примере ввода с "клавиатуры" (а в видео это основной пример), поскольку она реализуется исключительно на прерываниях. Не считая конечно новичков, кому кажется проще опрашивать в цикле :) Лучше бы объяснили на реальном примере. Вот у меня был проект на AtMega128. На дисплей 128x128 выводится информация из нескольких источников: от часов, от барометра, от термометра, от таймера, от "клавиатуры" и нескольких аварийных кнопок и даже от радио. Оказалось, что удобнее всего реализовать посредством эмуляции многопоточности, когда "менеджер задач" поочередно вызывает "потоки" (по одному на каждый источник), а те, выполнив какую-то часть работы, передают управление дальше. Причем, задачи получения данных от датчиков и вывод на экран обработанных данных были разделены. Единственно, что те же кнопки использовали прерывания, запуская "поток", выводящий на дисплей информацию и проигрывая определенный сигнал. Вот где преимущества многопоточности облегчают написание кода, его отладку и читабельность. Думаю и у Вас нашелся бы подходящий пример из жизни.
Пожалуй без разбора примера и указаний достоинств работы с FreeRTOS (например с приемом кода пульта и включением чего нибудь) Было бы лучшим аргументом.
я бы опредил пременимость RTOS так, если декомпозиция задачи укладывается менее чем в десять потоков, то применее RTOS скорее нежелательно и является "Overengineering", в таком случае лучше использовать конечный автомат, а чтобы код непревращался в"лапшу" просто аккуратно офрмлять код, больше использовать шаблонное програмирование, макросы
Был у меня один проект, где было пять почти не связанных друг с другом потоков. Написан был на автоматах, но весь код был тихим ужасом. Там свитчи были на 25-40 кейсов. Один поток работал с кнопками и GUI, второй через один UART работал с одной группой устройств по RS-485, третий через второй UART работал с другой группой устройств по шине K-Line, четвёртый работал с такими же контроллерами по шине CAN и пятый поток, получая все данные с остальных потоков, отрабатывал логику работы устройства. На FreeRTOS это было бы гораздо проще, эффективнее и быстрее. Однако, это был камень AT90CAN128 и порты FreeRTOS под него на тот момент были кривоватыми, а девайс нужен был "еще вчера".
@@acrsofter Ясно, что бывают задачи, где ОС не нужна. Я в таких случаях пишу функции опроса таким образом, что только когда данные будут готовы, функция их вернёт. А иначе возвращает ноль или иной признак неготовности. А задержки используются только неблокирующие, с использованием системного таймера. Часто даже автоматы писать не приходится.
Расскажите о работе прерываний с ОС, они работают асинхронно от нее и используют стек текущей задачи и требуется выполнять дополнительные телодвижения в обработчике прерываний?
Прерывания используются точно так же как и без ОС. Единственное, для управления некоторыми функциями ОС из обработчиков прерываний надо вызывать специальные функции. Но это не сложно.
Здравствуйте! Интересует возможность адаптации примеров из CubeMX по работе с USB (CDC, CDC+MSD) под FreeRtos. Есть ли такие примеры в принципе? Или для примеров CubeMX лучше подходят машины состояний?
Пример не нужно адаптировать. Это не программирование получается а извращение. Пример необходимо изучать с целью научиться работать с технологией или периферией. Библиотеки USB от ST прекрасно работают с FreeRTOS.
Всё пытаюсь понять, как именно происходит переключение контекста подпрограмм. На ум приходит только подмена адреса возврата при выходе из обработчика прерывания (как это делалось некоторыми утилитами в DOS). Т.е во время работы одной программы срабатывает прерывание, диспетчер (в обработчике прерывания) сохраняет контекст и адрес возврата текущей программы, восстанавливает контекст и адрес следующей и "возвращает" управление. При следующем прерывании вторая программа меняется на третью и т.д. Хорошо, если памяти у контролёра хватит, чтобы хранить контексты всех программ.
Наверное причина в том, что вы пытаетесь мыслить категориями привычными для IBM PC совместимых компьютеров. Вы и написали - "программ". По факту же мы имеем дело с небольшими задачами выполняющими те или иные функции. Разумеется памяти им хватит. На канале достаточно роликов по этой операционной системе, даже есть фрагмент где показывается как вывести в консоль реальную загрузку и стека и кучи. Можете посмотреть, взять там несколько строк кода и даже попробовать.
Всем привет ! Уж посмотрел Я и почитал коменты , и вот вопрос ко всем знающим . Если есть PIC . AVR. STM и нужна программа измерять температуру , вкл или выключать пару реле, дисплей , пусть будет . 1 - сколько займет памяти эта прога ? 2 - для таких PIC . AVR. STM задач , есть ли предпочтение , что лучше ? 3 - так что выбрать PIC . AVR. STM ?
Я бы выбрал stm32f042 в корпусе tssop-20. Влезет в 16 кило. (Сейчас делаю что-то анологичное, dht22, вентиялтор на управлении ШИМ, передача данных на nrf24). Все на HAL, весит около 10кб (может чуть больше), с оптимизаций O2. Приемная сторона, экран ST7735+NRF24, влезает в 16 кило(оптимизация по O-size). И ко всему использую stmcubeide
Здравствуйте! Данную задачу можно решить на любом МК и разными способами, так что размер занимаемой памяти оценить сложно. Лучшем будет МК с которым знакомы. Если ни с чем не знакомы, то начните с Arduino. Самой простой под Вашу задачу будет достаточно.
Все яйца обычно в одну корзину не кладут, тот кто говорит надо аппаратную часть жестко вести жестко привязанную ко времени и freertos это неправильный выбор для техпроцессов - используйте свою периферию: ПЛИС, DSP и тд, а stm очень хорошо на FREErtos может дирижировать вашим оркестром при этом отображая данные на дисплей и отправляя/принимая уставки куда нибудь сразу по нескольким каналам ю, при этом можно что-то не критичное ко времени привязать на саму стм что-то вроде температуры, заряда акб и тд, осциллограф из него не сделаешь, дельта-сигма фильтр из него лепить? Один контроллер на функцию? Да это просто кошмар такое предлагать, тогда на устройство надо 5 контроллеров или очень толстый стм. Автор учит как использовать стм, а вот как его использовать с умом тут каждый должен вырасти сам.
Владимир, здравствуйте! Спасибо за видео, пробую работать с ОС в своем проекте. Сразу возник вопрос о определении размера стека для задач. Возможно вопрос новичковый, но было бы круто выделить немного времени в видео о стеке, логике расчета, методах оценки ресурсов МК в отладчике (как с РТОС, так и без нее).
@@VladimirMedintsev Всё пересмотрел по FreeRTOS из плейлиста. Получилось запустить, почитать расход стека, все очень удобно. Эти видео - какой-то праздник! Еще раз спасибо.
Спасибо, очень содержательный комментарий. Но это диспетчер задач и я обещаю вам называть его так и впредь. Спасибо что смотрите. Не забывайте поддерживать канал.
@@VladimirMedintsev наверное, у Вас сложилось впечатление что просто "а Баба-Яга против" (с). Нет, я не злостный противник операционнок на МК (ладно, противник, но это уже другая история). В первую очередь, я противник усложнения там, где не надо, и внедрения лишних точек отказа, где не просили. Пример из практики: на очень похожем проекте, но с крайне жесткими ограничениями по таймингам, один товарищ тоже решил что FreeRTOS - быстрая, а такты - дешевые. Почему у него не получилось докупить оптом тактов в уже выбранные МК, объяснять, думаю, не надо. В итоге, все было выброшено в окно, и переписано на Bare Metal. Вышло 46 строк ассемблерного кода на все про все. Пара часов разработки, пара часов в QA, и готово. Воюй мы с ОС, до сих пор сюрпризы по углам отлавливали бы. Впрочем, я уже лет 6 программатор в руках не держал, может что и изменилось с тех пор. Хотя, что там могло измениться? Частоты чуть подросли, да память еще чуток подешевела? Не тянет на принципиальные изменения.
@@ЕвгенийАвдеев-к7н У меня совсем не сложилось впечатление что "Баба-Яга против", после описанного вами явственное чувство другой пословицы "Дуть на воду, обжегшись на молоке". Вы пришли под учебное видео рассказывающее о том, как можно применить операционную систему и какие преимущества в скорости разработки она дает и рассказываете о случае проекта с жесткими ограничениями по таймингам.... Т.е. ваш товарищ ошибся при выборе подхода к построению скелета программного обеспечения для слишком слабого для решаемой задачи микроконтроллера и теперь из этого следует, что использование операционной системы это плохо и это точка отказа? Ну ладно, я готов смириться с тем фактом что это ваше мнение. Честно говоря это как в известном анекдоте, что микроскоп плохой, плохо консервные банки открывает. Я вашу позицию понял, спорить не буду...
@@VladimirMedintsev использование операционной системы - не плохо. Плохо, когда ее пытаются натянуть туда, где она не нужна. Равно как и плохо, когда изо всех сил пытаются обойтись без нее, когда очевидно, что она нужна. Все верно, для каждой задачи - свой инструмент. Изначальный посыл первого поста был, что в качестве примера как раз приведена крайне простая задача, которая с высокой долей вероятности без ОСи решается быстрее, чем с нею. Впрочем, я Вас понимаю: в учебный ролик трудно уместить сложный пример, с МК, который должен хороводить дюжиной устройств, читать тачскрин, да еще и в эфир шуметь. Тогда любой начинающий разработчик сбежит в панике :-)
Необходим доскональный разбор этой системы, желательно с "подводными камнями"... Понимаю, что учиться на собственных ошибках хорошо, но таким образом уходит слишком много времени.
Пожалуй, содержимое ролика никак не коррелирует с его темой (в заголовке). После прослушивания возникает четкий ответ на вопрос "Почему использование операционной системы оправдано даже в небольших проектах" - да ни почему. Просто так автору кажется. В небольших проектах может быть как раз лучше применить простой дешевый чип с малым объемом памяти, куда FreeRTOS никак не впишется.
Оправдано тем, что код получается чище и понятней - каждая мини-задача в отдельной функции и без лишнего мусора. Такой код проще и быстрее писать, отлаживать и поддерживать. А время сейчас стоит дороже чипов.
так для автора может быть небольшой проект это не помигать светодиодами, а какая-то замороченная херня вот он и говорит, что с виду вроде бы все просто, но есть куча состояний и все они как бы сами по себе должны работать и такое лучше оформить при помощи ртос, а не автоматом больше сожрет памяти, зато меньше писанины если ты бабло получаеш за проект, а не по часам, то в твоих же интересах написать это все как можно быстрее и чтобы через год ты мог понять, что ты там написал и встроить новую плюшку а то бывает так, что новая плюшка потянет переписывание всего кода
@@ЮристЧастнойПракитки Тут ключевое слово "почти". Таки да, именно так. Поэтому нельзя утверждать, что "даже в небольших проектах использование FreeRTOS оправдано". Не все чипы "современные", и ни на все "современные" чипы "влазит" RTOS. Всякий инструмент хорош на своем месте.
Необходимо указать важный момент. Если Вы пишете программу , НАПРИМЕР, передачи по радиоканалу потокового аудио, то FreeRTOS, не справится с подобными задачами и необходимо написать программу в классическом режиме последовательный код с прерывателями ит.п., подсчитывая в дебаггере каждый такт,, чтобы соблюсти точные временные слоты оцифровки и передачи пакета с накопленными сэмплами. . Поясню. Вы указали, что квант времени отводимый FreRTOS 1 ms. Я в программе каждые 125 мкс оцифровываю внутренним АЦП аналоговую речь, попутно накапливаю оцифрованные сэмплы во внутреннем буфере ОЗУ порядка 300 байт, при заполнении буфера я передаю его по SPI в CC1100 (радиопередатчик) . При употреблении FRERTOS у меня все поплывет, особенно в программе приемника , теорема Котельникова нарушится, пакеты с цифровыми сэмплами (речью) будут приходи не в нужные слоты времени, соответственно на ЦАП в каждые 125 мкс не будет поступать очередной сэмпл для декодирования. Так что,FRERTOS не поможет для решения данной задачи. для устройств, которые разрабатываете Вы, и для устройств которые не требуют точного до 1 мкс подсчета выполнения определенных частей программ и промежутков между ними, FREERTOS самое то. Хотя я возможно не совсем прав.
Так. Созрел глупый вопрос: А при переключении на другую задачу, значения переменных и состояние выполняемой сохраняется? Судя по тому, что Вы упомянули отдельный стек, вроде ответ должен быть да. Но можно для деревянных уточнить ))
@@VladimirMedintsev Спасибо, очень помогли понять в каком направлении копать. Столкнулся с такой необходимостью, когда не плохо бы, чтобы одновременно выполнялись несколько задач, параллельно так сказать. Понятно было, что решение где-то есть.. но где... ))
@@VAscetic Каждой задаче под FreeRTOS выделяется собственный стек, одна и таже функция может использоваться для нескольких одинаковых задач (например, для обработки портокола на нескольких последовательных портах одновременно*), и стек у каждой задачи всё равно свой. Статические переменные работают как обычно. * Не совсем одновременно, конечно, а под управлением диспетчера задач.
@@DmitryKandiner Ага, спасибо, я в целом понял концепт. По сути, очень сильно такого плана решение мне требовалось пока 1 раз, и то более менее обошёлся. Когда с ETH учил контроллер работать, для поддержания одновременно нескольких активных соединений TCP по разным портам. А так, в большинстве случаев, достаточно стандартного набора прерываний, тем более если в контроллере есть DMA. Ну или я ещё в сложные задачи не залез :)
@@VAscetic как вариант -- построение веб сервера. Один процесс только принимает новые соединения, и запускает дочерние процессы на каждый запрос. А запросы, в свою очередь, обрабатываются каждый своим экземпляром одного и того же кода (важно не полагаться на статические переменные -- они общие для всех). По окончании обработки процесс закрывает соединение и самоубивается.
А знаете ли Вы, почему появляется потребность вот в таких видео? А потому, что на дисциплине "информатика" операционная система - это системное ПО, задачей которого является управление файлами. Я не шучу. Именно в такой формулировке. А что такое ядро, системные сервисы и даже, банально, механизм прерываний - этого знать не нужно. И ладно ещё общеобразовательный предмет. В ВУЗе дают такие определения! Кому интересно, Тёненбаум, "Современные ОС". Всё понятно и доступно.
Видимо это явление консерватизма. Первые ОС действительно создавались вместе с файловыми системами и предназначались для работы с файлами. MS-DOS тоже зовётся операционной системой, однако многозадачности там нет.
@@kardanium не соглашусь и оспорю. Первые ОС - как раз таки пакетные загрузчики вычислительных задач. Тогда ещё понятия "файловая система" не было. Была перфолента, стопка перфокарт или (в лучшем случае) пара десятков метров магнитной ленты. Задача - последовательный запуск заданий и вывод результатов куда-нибудь (чаще, на печать).
@@mnanorn Ну так, тогда тоже небыло многозадачности, ядра, диспетчера и прочих подобных вещей. Был просто код, который читал перфоленту, заносил ее в ОЗУ и отдавал загруженной программе управление. Позже ленты заменили на диски и следовательно, на файлы. Многозадачность появилась позже, когда вычислительные ресурсы и развитие компьютеров стали это позволять.
@@kardanium Вы считаете прерывания многозадачностью? Уточню вопрос: Вы считаете возможным организовать действительную многозадачность на одном вычислительном ядре?
уважаемый автор,извиняюсь за то,что не по теме,но : у вас есть курс по программированию stm32 для начинающих? или может посоветуете, где на ваш взгляд это доступно изложено.
Тут прям холивар развели! Надо-не надо...Не нравится frtos - пиши свой диспетчер... В любом раскладе задачи быстрее 0,5-1мс придется выполнять, изгаляясь, где-нибудь в прерывании или еще как придумывать... А все диспетчеры и оси нужны для обработки МЕДЛЕННОЙ БИЗНЕС-ЛОГИКИ!!! Когда у тебя дохрена кнопок, дофига светодиодов, датчики, цапы, ацп, и все работает независимо - иди собери все это в кучу! Вот тут и выруливают помогаторы!
Если вам нужны "жестко заданные тайминги" то возьмите таймер и он вам очень точно измерит временные интервалы. Что касается последовательности переключения, то совсем не все задачи так примитивны как вы пытаетесь это представить. Есть весьма сложные алгоритмы. И в этих случаях применение операционной системы экономит много времени как на разработку так и на отладку. Более того, использование FreeRTOS весьма заметно повышает общую живучесть системы в целом.
Все идет к усложнению архитектуры проца.. Уверен появится аппаратный менеджер задач, который например будет включать задачи по таймерам и отводить им сколько нибудь тактов... Потом выяснится, что два таких проца еще лучше чем один, потом защитят память кольцами защиты от вирусов, писАть под stm32(64/128/../2048) без ОС станет невозможно, выдут книги по программированию для ОС ртос.... Уверен мы наблюдаем ускоренную эволюцию от процессоров 8080..i486,...233mmx,....core i3.... и параллельно ms-dos...windows 3.11,...NT...XP....
Пожалуйста, пожалуйста, пожалуйста ответьте на вопрос, а то я не понял: если у нас, например, всего 5 задач в ОС, на каждую проц тратит 1 ms, что происходит на 6-ю ms, он переходит на первую задачу или ждет 995 ms, потом переходит на 1ю задачу?
Если квант времени у ОС 1мс, как быть в случае, когда имеется задача, которую нужо успевать обрабатывать за время от 1мс? Эта функция или реакция на внешнее воздействие, или она в принципе должна вызываться с периодом около 1мс.
@@VladimirMedintsev Т.е. имеется ввиду совмещение двух подходов? Задачи не требовательные к времени отклика - крутим в RTOS а задачи которым нужно обеспечить быстродействие пишем по старинке? Я в своё время писал много вещей у котрых большинство функций не требовательно ко времени, т.е. их можно выполнять с периодом 100мс просто по очереди. Но есть обработка внутренней логики которую нужно успеть за 1mc. Ещё есть фильтры для которых важно тактирование с постоянным периодом. Есть внешние прерывания. Есть UART в который нужно ответить желательно за 1-2мс. Я написал свой диспетчер не требовательных к времени отклика задач, и да, согласен с Вами, написание таких вещей тянет за собою много времени. Но всё равно остаётся ещё много задач, для которых время отклика важно. И всё это крутится в mainloop и да, на pipelined 8051 8МГц loop time получается около 1мс. Меня не отпускает мысль, что при использовании RTOS я бы мог обрабатывать быстрые задачи ещё быстрее... Это возможно?
@@Asmcavr Кэп? Вы ли это? Я в кубеиде делаю коммерческие проекты, за которые деньги получаю именно потому что она бесплатная чтобы не нарушать лицензионное соглашение и законы.
@@VladimirMedintsev Так теперь считай все и делают, точнее пишут в комфорте, в Keil / IAR, а на продажу пересобирают из под CubeIDE ;) Еще бы отладку с программатором в этом CubeIDE допилили, а то здорово подбешивает шиться вне среды
Ну кому что, можно и на операционной системы FreeRTOS делать, но проще и быстрее чтоб работало сделать всё на прерываниях. Сработало прерывание, получили какую то информацию, выставили флаг событие, разбудили основную программу. Программа проснулась всё это обработала и опять в сон.
Если FreeRTOS уже есть в портированном состоянии под данный контроллер, то как раз использовать её много проще, нежели настраивать прерывания. Да и что там портировать...
Во-первых: а если задач больше, чем прерываний? Во-вторых: вы уже сами начали описывать что-то вроде простейшего диспетчера в главном цикле, который флаги проверяет. Добавляем сюда необходимость приоритетного выполнения некоторых задач, софтовые задержки, детерминированное время отклика на событие - и вуаля, у нас страшный франкенштейн (если он работает вообще), поддерживать который сам замучаешься. А уж отлаживать. И куча зависимостей между кусками кода. Поправил одно - отвалилось другое. Добро пожаловать в мир говнософта.
Посмотрел коменты. Прям из крайности в крайность ))) FreeRTOS имеет 3 типа многозадачности, в тч кооперативную и гибридную. Ну т в целом, сражаться за каждый такт процессора смысла нет, тк стоимость такта снижается. К тому же, всегда приятно иметь "коэфициент спокойной ночи" в виде некоторого запаса по ресурсам и перспективам.
Нужно еще одно видео - ибо вообще непонятно как скрестить FreeRTOS с задачей требующей высокого быстродействия. Вот вводные: оптический датчик с 1800 линий на оборот стоит на шпинделе станка, который имеет максимальную скорость 2000 оборотов в минуту - нужно получить данные о положении шпинделя и в зависимости от этого вращать шаговый мотор - логику вы эту в прерывание не засунете - ибо там расчетов много и из этого вы "отодвинете" время срабатывания других прерываний. Засунуть логику обработки в задачу, которая выполняется не чаще 1мСек и имеет время старта "как FreeRTOS решит " - это вообще не вариант. Вот как вы можете решить данную задачу с FreeRTOS ? А если честно - я вообще не понимаю - почему FreeRTOS - это система РЕАЛЬНОГО времени ибо операционка MS-DOS вот это система РЕАЛЬНОГО времени, а та же Windows это уже операционка НЕРЕАЛЬНОГО времени и там тоже тайминги в 1мСек и время старта задачи там тоже "как операционка решит".
Если считать программно каждый тик энкодера - то да, непосильная задача для любого- даже самого быстрого процессора. Но вместо подсчётов тиков энкодера - достаточно опрашивать его аппаратную часть на таймере, через фиксированное количество времени. В этом случае считается не его текущее положение - а изменение за фиксированное время, со сдвигом к нулю. В этом случае доступен весь диапазон таймера работающего на энкодер, и отпадает необходимость как-либо управлять его переполнением. Ведущий мотор может вращаться с низкой скоростью, для того чтобы ловить это состояние - используется дробные числа. Старшая часть повторяет значение аппаратного энкодера, а младшая - дробные числа. Для ведомого шагового двигателя считается положение в которое он должен встать через фиксированное время того-же таймера, что запускает считывание таймера энкодера. Тут тоже дробные числа, и тоже с переходом через ноль. Перемножаем дробное от энкодера - и получаем любое разумное соотношение скоростей вращения. И да, это угловая скорость. Дык вот, считывание и управление происходит в прерывании, или через дма. А обработку можно делать в основном цикле. Потому как на фиксированную задержку в 5-30мс - механика станка (инерция) просто не в состоянии отреагировать. Общая задача достаточно простая, и может целиком выполняться в прерывании (буквально несколько строк). Ос может понадобится для работы с экраном и кнопками. Потому как реакция человека заметно ниже требований к железу, тут +- лапоть к задержкам - вообще никто не заметит.
@@avi-crakhome2524 - я завис на вашей фразе и дальше уже не читал: "Но вместо подсчётов тиков энкодера - достаточно опрашивать его аппаратную часть на таймере, через фиксированное количество времени". Аппаратная часть промышленного оптического энкодера есть фотодиод и как вы его можете опрашивать периодически чтобы узнать положение шпинделя станка - я даже не представляю.
@@НиколайПр-з3в Аппаратный таймер чипа stm32xxx - режим энкодера. Вход две линии от промышленного энкодера, выхлоп - значение счётчика таймера. Вот именно это значение и нужно считывать через фиксированные промежутки времени.
@@НиколайПр-з3в Не через, а совместно. В ос есть таймер, который фиксировано срабатывает каждую 1мс. Если в его прерывание добавить немного кода - система не рухнет. А вот изменение коэффициентов множителей для ускорения/торможения и начальную синхронизацию - можно делать через freeRTOS. Этот код жирнее, и не требует моментальной реакции.
конечно интересно, но вот на столе лежит две конкретные задачи - зарядка LiFePO4 100кГц ШИМ с ПИД-регулятором на stm32f303 и передача спектра звука 32кГц (естественно через fft) с I2S по tcp на комп на stm32f745, ни в одном из случаев freeRTOS ничего не успевает, о каких osDelay или квантах в мс идёт речь, если нужны мкс? в первом случае, кстати даже HAL не успевает, перешёл на LL, приходится писать отсебятину, если речь идёт о чтении кнопки, выводе на дисплей, где сотня миллисекунд вообще ничего не решает - одно дело, если же настоящий real time с квантами в микросекунды, то нужно намного глубже разбираться во freertos, чем в прерываниях и DMA
Для зарядки лития нужна скорость ответа регулятора в 100кГц?) Да, ШИМ может понадобиться в 100кГц, но используйте для этого хардварный таймер. А пид-регклятору и 1кГц overkill.
@@NoName-yp9to . Ну ну. Сравнил шип 1кГц и 100кГц. Там какбы индуктивность (трансформатор) совсем разные по габариту получаются)))) Автор выше прав - если что-то медленное и неответственносое, то freertos рулит. А когда надо выше 1кГц то- сосай мосай
@@vladevro222 а теперь перечитайте то, что я написал выше. Вобще то я предложил шим генерить с частотой 100кГц аппаратным таймером, а с частотой 1кГц - только лишь обеспечивать регуляцию. А уж если нужна какая то быстрая обратная связь (например по току КЗ), то в большинстве стмок есть компаратор.
@@NoName-yp9to зачем страдать если написать напрямую просто проще? Без абстракции ради абстракций. Просто сделать задачу. Единственно зачем там стм вопрос. Там какая нить аттини или пик вполне.
Вы просто не захотели заниматься трассировкой. И не было бизнес-заказчика, который правильно бы подсчитал все свои текущие и будущие затраты. Я подозреваю, что для каждой из Ваших задач есть аппаратные решения. И для заряда аккумулятора, и w5500, и, возможно, какой-то dsp со встроенным fft. Вам останется только взять кракозяблу для управления периферией. Код - минимальный, поддержка - дешевая, конец производства - не приговор, затраты на переписывание управляющего кода - минимальные. FreeRTOS - для правильно организованного проекта.
![[2024/11/13 Сем 10] Работа с видео, Оптический поток (Андрей Стоцкий)](/img/n.gif)
Как раз сейчас и решаем схожую задачу, используя RTOS: нужно быстро и часто опрашивать акселерометр, анализировать полученные данные, при этом управлять контроллером электропитания, что-то периодически (хотя бы 4 раза в секунду) обновлять на экранчике и при этом обмениваться с сервером информацией через очень медленную LoRa. Задачи слишком разного масштаба времени. Можно, конечно, самому городить семафоры, очереди и т.п., но если это уже всё сделано во FreeRTOS, то зачем изобретать велосипед?
Тем более, что прерывания тоже никто не отменял. Например, под опрос акселерометра сделать задачу с семафором, а открывать семафор -- в прерывании по окончании чтения.
Спасибо за доступную подачу информации. Пока сижу на AVR, делаю хобби-проекты. Крайний проект, после реализации на AVR, с помощью вашего канала планирую перевести на STM32. Еще раз спасибо и надеюсь что терпения на развитие канала Вам хватит, а в том что сумеете подать актуальную информацию в доступном ключе-у меня сомнений нет.
Хватай на али "stm32f103c8t6 board" + прогер-отлдачик "STLink2" за 100р. Качай CubeMX + Keil5, 2копиасты кода, 5 кликов мышки и проект готов :)
А не заработает, врубай пошаговую отладку как белый человек и смотри где ступор
Ну я прямо не знаю сколько тонн лайков надо ставить))) Сам с FreeRTOS уже 5 лет работаю в коммерческих проекта и глубоко убежден, что что-то серьёзное сделать без оной можно но ОЧЕНЬ сложно.... А Вы так доходчиво народу объяснили что да как и по чём)))
Пожалуйста поподробнее: 2 таймера с выводом ШИМ и ввод-вывод по USB можно ли считать настолько сложной задачей, что без FreeRTOS не обойтись?
:)
@@Wo_Wang есть разница между "не обойтись" и "некомфортно работать". Проще - с операционкой, как минимум протокол общения (поверх стека USB) я бы выделил в отдельный процесс.
Наконец-то доступно объяснили для чего нужен freertos😁 Спасибо за видео!
Priviet Vladimir, I would say that your videos should be in everyone's who is interested in electronics's playlist. For me, you saved tons of hours with my personal projects. Recently I started working on FreeRTOS. I think you should keep on this topic more because there is a lot of applications where it can be used. Also logic behind RTOS is really suitable for industrial automation field where applications is more time critical. Keep on doing this! It's really helpful!
Greeting's from Lithuania.
It’s a surprise for me that someone is watching these videos in Europe. Good luck to you.
@@VladimirMedintsev in my opinion all the most informative tutorials are made by Russians. I know Russian language too as we were the part of Russia so for me it is easier to understand. Anyway keep on doing these videos and maybe if you can more on freeRTOS :)
Братан! Пиши на русском языке, а то скоро вы его совсем забудете!
Контроллер это устройство состоящее из процессора, ОЗУ, Флеш памяти и прочее. Автор совершенно прав.
Первые 3 минуты изучал пол часа.... магия раскрыта, БлагоДаря Вам!
Кстати, Владимир, Ваше видео дало мне повод задуматься, что возможно нижеописанную мною проблему можно реализовать с помощью FreeRTOS. Вы мне дали повод для размышлений и изучения FREERTOS.
"... код становится не сильно легко читаемым..." - Класс!!!!!
Классно 👍👍 спасибо вам за данное видео... Я когда кодил под Ардуино, пытался реализовать что-то подобное. Пытался написать ОС для микропроцессоров, но мои навыки программирования на чистом C не позволили сделать подобную ось (более 3 лет разрабатываю программы на C++/C#), а тут есть готовый велик, как говорится "садись и едь!".
Спасибо, очень полезную работу делаете, все чётко по полочкам. Не обращайте внимание на этих придурковатых умников, это все на что способен их мозг))
Без условно, использование операционной системы это грамотный подход👍
Спасибо большое за обзор! Очень многое стало яснее...
Отличный обзор. Прошу рассказать особенности работы виртуализации с dma , какие существую подходы для качественной работы
Вставлю свои пять копеек,
1) Там где вы вставили switch case в while(1), и говорили, что нужно долго дожидаться пока Program Counter дойдет до нужной обработки после прерывания, но вы же можете в этом прерывании ставить флаг, который скажет, в какой из кейсов переходить после прерывания и обработка после прерывания будет быстрее. Во freertos же надо придется дожидаться когда PC дойдет до задачи которая должна обработать после прерывания.
2) Для процессоров типа stm32F0 , на мой взгляд, freeRTOS жрет много оперативки, в отличии от тех же конечных автоматов, где 2 байта идут на запоминание состояния где мы были.
Спасибо за качественный контент.
В общем как многопоточное программирование в каком-нибудь дотнете, ясненько, спасибо👍
Десять благодарностей вам :)
Спасибо, я с первого раза понял преимущества ос. Тут получается хороший мултитрединг, каждый таск получает своё время. На интерапты хорошо и сразу можно отреагировать.
Заказал себе микро контроллер, попробую...
Примерно к такой же структуре программы я и пришел лет 20 назад, с таймерами и флажками, после 2-х летних изысканий. Задача: упаковочный автомат с 2-3-4 весовыми головками(CAS). Контроллер: fastwel CPU188-5. Правда, RTOS-ов тогда ещё не было... ☹ Гы: зато, ещё был MS-DOS 6.22, на этой плате! 🙂
Не понимаю тех, кто не хочет использовать FREERTOS, даже тогда, когда ситуация позволяет. Например, очередь - это очень крутая вещь. Можно в обработчике прерываний заталкивать туда данные и когда у задачи появится время, она их обработает, извлекая из очереди. Данные можно даже получить из неё не извлекая их из неё. Такое очень даже пригодится, когда на одни и те же данные нужно реагировать нескольким задачам. Еще круче получается с несколькими источниками данных для очереди. Например, одна задача окрашивает кнопки и помещает коды нажатых кнопок в очередь. Задача, отвечающая за работу с GUI получает их и обрабатывает. А теперь нам захотелось управлять GUI с помощью пакетов, приходящих с UART. Создаём задачу, которая принимает эти пакеты, извлекает из них команды и помещает их в эту же очередь. Так вот, сильно не напрягаясь и не затрагивая кода GUI, мы добавили еще один "пульт управления". И таких вот фишек там масса.
Я не хочу :) т.к. нашел куда круче RTOS2 RTX5 - родная ARM ось, ХАЛЯВНО включена в CMSIS2 !!! НЕ ОБРЕЗАННАЯ как все GNU "халявные" как
FreeRTOS или ChibiOS хочешь полную и надежную ПЛАТИ! Открытый код!. портирована в IAR и GCC, работает не только в платном Keil5
в CMSIS2 есть шаблоны под потоки, таймера итп, подключается быстрее чем фриртос из куба. И к ней есть EventRecorder классная GUI консоль для отладки в Keil5
(галочки не забудь расставить, а то будет пустой график)
Попробуй!
И я не хочу. Хватает TNeo.
На код freertos как ни посмотрю, напоминает древние версии php...
И я не хочу. Дорог каждый байт памяти и каждый такт не лишний.
Андрей Батищев, говорят кольцевой буфер с этим отлично справляется))
@@ЮристЧастнойПракитки Говорят много чего, но более мерзкого (в плане реализации), чем кольцевой буфер, я больше ничего не видел.
А ещё по прерыванию можно разбудить процесс,выполнить что то и усыпить )
Вообще более правильный вариант использования ос будет в комбинации всех доступных возможностей - ос+прерывания+дма
Спасибо, да действительно удобный инструмент
С freertos вроде все удобней , но вот появилась задача управления шаговыми двигателями и обработкой энкодеров и тут столкнулся с затруднениями генерации импульсов для ШД и обработкой прерываний от энкодеров.
Посыл конечно понятен. Не понятно только, почему по мнению автора есть только 2 альтернативы: последовательный код и freeRTOS(или любая другая RTOS). Для 99% задач которые делают на стмках, хватит банальной event-driven системы, в отдельных случаях вкупе со стейт машиной. И первое и второе пишется за 30 минут и занимает минимум места. RTOS это хорошо, но это чаще всего стрельба из пушки по воробьям. Не надо так.
Я новичок с 12-ти летним стажем...и половину слов не умею реализовывать"event-driven системы, в отдельных случаях вкупе со стейт"... в дальнейшем научусь, но ОС доступный инструмент int_32t, забивать гвозди в int_8t!
Спасибо, подчерпнул многое для себя, потихоньку отстраняюсь от ардуины
Спасибо вам , открыл для себя ОС - Ртосс !!
Было бы интересно увидеть видео разбора крупной программы, как в ней использовался FREERTOS и какие опасные моменты нужно учитывать. Вроде штука интересная, но как и где ее стоит применять все равно не очень понятно. В маленьких программах ради удобства - притянуто, маленькую программу как ни пиши - проблем нет никаких. В больших - можно кучу не отлавливаемых интересностей словить - стремно использовать. Вообще контент на канале достойный. +++
вот как раз операционная систем и нужна для отлова интересностей. Операционная система имеет средства контроля за работой процессов и имеет средства управления памятью. При использовании ОС есть недостатки - это потеря в скорости реакции и использование большего объема памяти. За это програмист получает возможность управления потоками, профилирование, отладку запущеной системы.
актуально. нужно на практике показать сколько сьедает ОС ресурсов. считаю по умолчанию ОС много сьест. для меня актуальным примером будет приложение электропривода на 4-5 задач на 1-10 кГц. а так конечно ОС будет удобно использовать. а у тена с бочкой воды постоянная времени 20 минут или 1 час. с теном можно и виндос использовать ;)
FreeRtos ОСРВ? В новой упаковке? Простите, с 90-х этим не занимался. Опять пришлось. Очень полезный канал.
RTOS и переводится как ОСРВ
У меня в usart по дма иногда пропадает посылка на прием при использовании freertos, точно такой самый код, но без операционки, за ночь при тесте модбаса дал всего лишь две ошибки при 256000 кб/с, не знаю, плюс для реализации canopen нужно прерывание 1мс и проц stm32f407vet6 не может обслужить программу где одновременно используется 5 интерфесов и 200 кбайт кода...принял решение отказатся от операционки
Все эти ртосы очень напоминают ардуину. Расточительно, но может пригодиться при унификации подключаемых к проекту модулей: вставили INIT и все остальное модуль запустит. Именно так пишут свои примеры разработчики микроконтроллеров, например, STM.
Основной недостаток - все это очень медленно. За время переключения с одной задачи на другую, в моих проектах успевают выполниться все мои задачи. При переключении диспечер сначала обрабатыыает все очереди событий, выбирает задачу, потом собирает чемоданы от текущей задачи и распаковывает для следующей. Я пишу сложные многопроцессорные приложения с обработкой звука в реальном времени, комуникацией, графикой, вложенными прерываниями, распределением приоритета и т.д. Мой опыт работы 27 лет. Применение ртос не оправдалось нигде. Все решается проще.
14:50 - лучший способ исправления опечаток! 😁👍 Спасибо за отличный урок!
Насчёт тайминга действительно это просто недопонимание. На то она и “real time” ОСь, что её цель именно выдерживать детерминированный тайминг задач. Нужно только указывать им приоритеты и будет тайминг что надо. На ютубе есть видео с презентацией FreeRTOS от автора - там он отлично это поясняет.
Конечно, могут быть какие-то другие причины не использовать RTOS. В каких-то супер-критических и супер-embedded задачах может будет необходим 1 контроллер на 1 задачу (или 1 PLC на задачу, если это совсем что-то суровое). И, конечно, если ваш код не сложен и не предвидится его развитие, то действительно нет смысла заранее заморачиваться с ОСью. Но тайминг это как раз не проблема для RTOS, это её работа 🙂
Контроллеры разные бывают. Для ATmega 8 или 328 такая ОС мне кажется перебор, а вот для ESP32 необходимо использовать ОС.
Спасибо за ваши видео. Могли бы вы дать информацию, где описывается FreeRTOS доступным языком? Хочется узнать по подробнее.
у них на сайте freertos. org
microsin.net/programming/arm/freertos-part1.html
19:00 Забавный диалог...
- При чём тут операционная система, когда нужны жёстко заданные тайминги?
- При чём тут жёстко заданные тайминги, когда нужна операционная система???
Для многих задач и особенно для мелких контроллеров зачастую не нужен RTOS,достаточно Protothread
При рассказе последовательности загрузки МК, Вы еще пропустили что будет с начало вызвана функция, так сказать инициализации языка С, называется она в Вашем случае __main(), а вот она уже затем вызовет пользовательскую функцию main(). На ББ в этой функции "__main()" как правило происходит статическая инициализация данных и инициализация стандартной библиотеки С ...... для МК скорее всего аналогично.
и это как-то влияет на запуск программы? о всех мелочах рассказывать это видео бесконечным получится.
@@VladimirMedintsev нет конечно, просто Вы подробно начали рассказывать про цепочку вызовов, и при виде ассемблеровского вызова функи __main() в Вашем видео, почему то сразу перешли на main(), а мне просто это бросилось в глаза )) и я решил поделится с Вами инфой об этом. Я ни в коем случае не хотел вмешиваться в Ваш рассказ, а просто восполнить для Вас данный пробел. Но если Вы и так знали про это - то и отлично, извините меня за это программистическое занудство ))
@@VladimirMedintsev Влияет непосредственно, если использовать для инициализации статических переменных вызовы каких-либо функций, самое распространённое - при статическом создании объектов С++ вызываются конструкторы классов.
Иной раз по невнимательности можно схлопотать HardFault не добравшись до точки входа main(). По-моему инициализация - достаточно важный вопрос, чтобы его упомянуть, хотя бы одним предложением.
@@OlegKotchetov Можете хоть один, ну хоть вшивенький пример инициализации хоть чего-нибудь привести чтобы схлопотать HardFault не долетая до main. Ну хоть какой - нибудь примерчик.
@@VladimirMedintsev
Пожалуйста:
1. Слепить класс, у которого в конструкторе присутствует обращение к периферии через HAL, надеясь, что создавать его объекты будут всегда _после_ инициализации HAL.
2. В угаре очередного горящего дедлайна вспомнить, что когда-то был такой отличный класс, который делал то, что нужно, скопировать его в проект и воткнуть статическое создание экземпляра, что-нть типа
extern I2C_HandleTypeDef hi2c1;
static I2C_SuperSensor sensor = I2C_SuperSensor(&hi2c1);
А потом удивлённо смотреть в дебаггере на немедленный HardFault при запуске.
Да, разумеется, это адский быдлокод и тот, кто так сделал - сам дурак. Но поверьте, ситуации бывают разные. Иногда приходится сознательно быдлокодить, когда на постройку башни из резной слоновой кости нет времени, задача копеечная и требуется чтобы результат сработал раз-другой и дальше станент не нужен. Да лучше за такое не браться, но иногда и отказать нельзя. Если Вы занимаетесь этим делом на потоке, наверняка сами прекрасно понимаете. А может новичок подобное слепит по неопытности и потом мозг сломает, пытаясь понять, что, блин, происходит :)
Вот для последних как раз помянуть про фазу инициализации статики - методически оправдано полностью имхо. А то ведь зачастую смотрят на компилятор, как на чёрный ящик: на входе исходник, на выходе - светодиод моргает, а что там между - черт его знает...
Спасибо, полезная информация
Спасибо! Это то что надо!
Я сейчас пишу программу, так уж вышло, для AVR архитектуры (Atmega168) и меня эта туева хуча конечных автоматов уже успела достать. На I2C два устройства - делай аатомат. UART - делай автомат. Опрос клавиатуры и генерация событий - делай гребаный автомат. Короче, для всего, что может впустую застопорить главный цикл - нужен автомат. Я настолько упоролся этими автоматами, что даже для записи в EEPROM хотел его слепить, но остановило то, что запись ест немного тактов, а транзакции туда короткие. Погоня за быстродействием быстро сожрала половину ПЗУ. С RTOS все это безобразие было бы гораздо проще.
Есть порт FreeRTOS под AVR, если не ошибаюсь.
@@DmitryKandiner Проект уже окончен. В нем обширный GUI. Места, возможно, не хватит. Но можно попробовать. Ибо FreeRTOS туда прямо просится. На I2C шине сидит кучка периферии, активно задействуется UART и GUI хочется без тормозов. Памяти всё это сожрало намеренно (13 КБ ПЗУ и 400 байт ОЗУ), но при этом нет тормозов, камень всё успевает и код пригоден для дальнейших доработок и дополнений (модульный принцип). Остался килобайт на маневры в будущем и ещё два заняты бутлодером.
И самое смешное - для оптимизации объема, некоторым функциям пришлось ставить атрибут no_inline. На производительности это не сказалось практически никак, но сэкономило целый килобайт ПЗУ. Чем глубже лезешь, тем больше сюрпризов от компилятора AVR GCC. Даже в таких вещах, как макросы и константные числовве выражения. Они все имеют тип int, который размером 2 байта в AVR. И когда выполняешь операции над переменными int32 и константами, компилятор без предупреждения приводит int32 к int (16), что у неподготовленного адепта Механикус может вызвать чувство вины перед Омниссией. 🤣
@@kardanium рекомендую посмотреть на st. Все что вы описали делается с использованием директ мемори аксесс и вообще не жрет ресурсы. А граф интерф делать на главном камне некашерно даже на неспециальнвх st. Есть же готовые с управлением по usart
Здравствуйте! Мне очень интересны автоматы, я сам на них пишу, но пока очень не опытен в этом деле. Можете ли вы поделиться кодом проекта, чисто в образовательных целях?
Процессор - это часть микроконтроллера, какой тут может быть спор вообще?
никто же не спорит как правильно: компьютер или процессор, если процессор - это часть компьютера.
микроконтроллер, помимо процессора, включает в себя постоянную память, оперативную память и прочую периферию, если бы он её не включал - был бы просто процессором, а так микроконтроллер.
если речь про работу процессора - можно сказать и процессор и микроконтроллер, т.к. он этот самый процессор содержит.
а вообще если человек спорит о таком - это говорит о его полной ограниченности, ведь важно не выбранное слово, а суть за ним стоящая, можно хоть хуёвиной его называть - лишь бы было понятно о чём речь!
Ты знаки препинания нахера ставишь? Спорим, что и без них все понятно?!
@@Vlad_4572 вот нет, без них далеко не всегда понятно.
Казнить нельзя помиловать.
@@alextiga8166 , конечно, не всегда понятно, потому, и желательно следовать правилам и договорённостям, что бы не было неразберихи, а не называть всё вокруг хуёвинами. Его право называть микроконтроллер как он хочет, моё право, его поправить.
@@Vlad_4572 можно сказать "компьютер выполняет программу", а можно сказать то же самое про процессор. Можно сказать "автомобиль потребляет топливо", а можно сказать то же самое про двигатель.
Так в чём проблема с "микроконтроллер/процессор выполняет инструкцию"? И то и то правда, процессор - часть контроллера.
Никто не называет микроконтроллер процессором, но когда речь про часть микроконтроллера которая является arm процессором - и так и так правильно.
Или я в чём-то ошибаюсь?
@@alextiga8166 , его дело, как и что называть, но автор не очень хорошо отозвался о тех кто его поправляет и привел пример комментария, типа: вот, смотрите написано же, что это процессор! Так никто и не спорит, что ЭТО(cortex-m) процессор/ядро. Но он упоминая устройство, говорит - процессор. Ты разницу понимаешь? В мануале всё чётко написано, что есть что, не пойму, в чём прикол подменять понятия?
Аплодую, я гадаю користь з того матеріалу новачкам буде велика! Збережу собі, десь в мене армка валялася)))
Хах, всё то у вас просто получается, как в примерах аля "помигать светодиодом". А не забыли ли вы упомянуть про тонкости синхронизации данных (в которых нужно в принципе иметь хорошие скилы в многопоточном программировании), трудно отлавливаемые дедлоки, тонкости вызова функций ос в контексте прерываний? В небольших проектах freertos никак не оправдан, всегда можно сделать систему событий, софтовые таймеры и практически всегда работать в контексте главного цикла и не заботиться о синхронизации. Вот реально freertos может быть оправдан там где куча долгих синхронный операций, например работа с bsd сокетам (интерфейс которых эмулируется через lwip) - да тут код будет куда короче и стройнее чем работа асинхронно.
Золотые слова, вот и я о том же. Автор видимо никогда многоточечных приложений не писал. А дедлоки это еще и меньшая из бед(ее изобразить сложнее), хоть и очень противная. А вот логика работы, не так как задумал - легко. И не обязательно гонки переменных, просто выполнилось не в той последовательности или данные разрушила, или обратилась к полупустому указателю и так далее. Тут занимался оптимизации одного своего проекта. Нашел ошибку, а суммарный аптайм десятки лет(всех экземпляров), не проявлялось только потому, что ошибка четная, т.е. их 2, вторая маскирует первую... А критическую секцию туда нельзя, слишком "тяжелая" даже для сервачных процов, а тут МК, хи-хи. Весь рак мозга начинается когда нельзя сильно обкладывать в кретические секции, да если все ими обложить - нахрена козе баян(вообще многопоточность)
Виталий Алпатов, особенно пример с клавой доставил, да и уарт не лучше. А ведь так хорошо начиналось видео, все в одной задаче))
Подскажите, по поводу объёма кода в обработчике прерываний, какие есть ограничения или правила?
Правило одно вы должны провести внутри обработчика как можно меньше времени. А это значит не делать задержек, не использовать таймауты. Чем быстрее выйдите из обработчика, тем лучше.
@astrahard Нечаев Вы сами читаете что пишете? Я сказал человеку, что в обработчике прерывания необходимо проводить минимум времени, это является безусловным требованием. Т.к. в любой момент может наступить новое прерывание от любого другого источника. Что в конечном итоге приведет к переполнению стека. Отсюда логично и требование не использовать таймаут и задержки в обработчике прерывания. Более того, это не мое личное придуманное мнение. Ровно то же самое можно прочитать в документации на FreeRTOS и также во всех известных мне учебниках программирования. Более того обработчики прерывания в пределах одного уровня приоритета друг друга не вытесняют. Так что осторожнее с оценками, пожалуйста.
@astrahard Нечаев Прежде всего я опираюсь на написанное в документации по FreeRTOS, а там прямо указано что обработчик должен быть как можно короче по времени, чтобы прерывания не накладывались друг на друга. Тут без разницы у вас микроконтроллер или большой компьютер. Система прерываний она не меняет своего смысла. Во-вторых я руководствуюсь написанным на сайте Cortex это как бы разработчик ядра микроконтроллеров. Ну а в третьих, programming manual на наши микроконтроллеры. Но если все это не заслуживающие внимания документы, то не проблема снимаю шляпу. Вы видимо великий специалист и знаток вопроса. Даже спорить не буду.
Не претендую на истину, а лишь выскажу свое личное мнение.
Мне кажется что писать с использованием RTOS можно только при соблюдении некоторых факторов :
1. Вы умеете писать работоспособный код и без нее и поэтому хорошо понимаете плюсы и минусы данного подхода.
2. можно писать с ней если приоритеты прерываний кажутся чем-то маловажным для вас и вы никогда не гуглили ответы на свои вопросы фразами типа "interrupt latency" и не считали такты(да да , в некоторых задачах на 100-180Мгц тоже приходится это делать и не по приколу, а по необходимости).
3. проект чисто домашний и можно смело брать самый "жирный МК" и не думать о его стоимости.
Если новички читают это, то просто поймите - RTOS это просто один из подходов к программированию - иногда оправдан, иногда нет, все зависит от ваших задач.
Ну а сам ролик нормальный.
Да вы озверели чтоли, новичкам много поточное приложение писать... Со всеми гонками переменных и прочими прелестями асинхронности.
Это 90% программистов вообще не умеют. Ибо в 90% случаев не нужно.
@@VitaliyRu ну по моему мнению - в 90-95%(а вообще и больше) использование ОС на МК тоже особо и не нужно. ОС нужно в других устройства, где чуть выше уровень и другие вычислительные возможности. обычно примерно так: система где есть 1) устройство на линуксе + 2) устройство на МК. линукс с ОС для вычислений, МК для связи с датчиками и ИМ.
как то так.
Новичкам (и не только )лучше RM читать , книжки по Си и Хоровица + практика практика практика. Я уже не совсем новичок, но все равно повторяю по кругу эти действия :) А кто хочет просто побаловаться "миганием лампочкой" и сделать это без особых затрат(умственных и временных) и забыть как пропадет интерес - ардуино будет идеально вариант и все эти ОС нафиг не нужны.
@@tx-rx По мне так тоже. Либо линух, винда и тому подобное. Либо по стараинке в петле с прерываниями(там своей боли хватит :) Их к слово по возможности лучше тоже избегать.
В видео описана задача которая прекрасно выполняется последовательно(это не только МК касается, но и той же винды), а ее предлагают сделать асинхронной.
Выше я там уже Рихтера цитировал
"В общем, мораль этого вступления такова: многопоточность следует использовать разумно. Не создавайте несколько потоков только потому, что это возможно. Многие полезные и мощные программы по-прежнему строятся на основе одного первично го потока, принадлежащего процессу "
@@VitaliyRu полностью согласен.
@@tx-rx за Хоровица отдельный привет и спасибо, дядька знатный и дай бог ему долгих лет жизни. Я после окончания университета его до сих пор перечитываю и каждый раз нахожу новое!
Согласен. Я на асме пописываю для АВР ок, как попробовал кооперативную РТОС (от di Halt,) так в "суперцикл" и не тянет. В разы проще и в написании и в отладке
Хорошее видео и объяснение доступное. А есть что-нибудь по работе с видео камерой?
Абсолютно непонятно что такое работа с видеокамерой.
Вот такой вопрос. Если представить что у нас есть 2 задачи freertos с одинаковым значением vtaskdelay допустим 100 мс для обоих. То при таком раскраде как эти две задачи будут работать друг относительно друга? Если речь идет о автоматическом распределении процессорного времени то будет вызываться перавая задача а через 50 милисикунд вторая а потом еще через 50 снова первая. Или же как то иначе? Какую логику преоритезации задач несет в себе это "автоматическое распределение процессорного времени"?
vtaskdelay определяет какое время диспетчер задач не должен передавать управление данной задаче. если у вас 2 задачи и они обе через osDelay указали что их не беспокоить 50 миллисекунд, то ближайшие 50 секунд будет выполняться только idle, а потом опять задачи 1 и 2 по очереди.
Да. Почти так. Но еще нужно учитывать что эти задачи будут делать. Если внутри есть полезная нагрузка отличная по тактам от другой, то циклы будут перескакивать.
И отдельный вопрос как они были запущены одновременно или например 1 сразу вторая через 50 мс. Если сразу то так и будет t1 0, 100, 200, 300, 400 t2 0,100,200,400.
Если с задержкой в 50 мс то t1 0,100,200,300 t2 50,150,250,350. А вот если внутри задачи t1 будет работы на 25 мс, а в t2 на 10мс то будет следующая картина при условии что ос вытесняющая. t1 0-35, 135-160, 260-285 t2 0-20,120-130,230-240 и т.д. Т.е. в тех местах где активная работа обеих потоков задачи выполняются (условно)одновременно но в два раза медленнее по времени. Отсюда вывод. Через какой-то промежуток времени задача 2 сделает на какое-то колличество циклов больше, потому как нагрузки у неё меньше.
Спасибо за доклад. Очень долго заглядываюсь на FreeRTOS. Понимаю, что на вопрос тяжело ответить однозначно из-за весьма размытых границ и всё же. Есть ли у вас какие-то свои критерии по которым вы решаете стоит ставить FreeRTOS или не стоит ? Буду очень благодарен конкретным примерам . Заранее спасибо
Вот сидите вы такой и с философским (обязательное условие) взглядом обращенным на облака обдумываете свою программу. Так вот если она рисуется вами как единая задача, то применять FreeRTOS НЕ НАДО. А вот если у вас в голове вырисовываются несколько процессов или подзадач, то применять FreeRTOS НАДО.
@@VladimirMedintsev Спасибо за ответ )
У меня принцип такой: если оперативы в контроллере 8кб и более, значит надо. Если 4кб - может быть. Все равно со временем нагородишь самодельный ее аналог худшего качества.
Ага, вот и я думаю: а зачем в микроконтроллере нужна многозадачность?
)
@@Wo_Wang при разработках важно правильно понимать что ты хочешь сделать и правильно ставить задачу. Мне не нужна многозадачность, мне нужно изолирование друг от друга потоков кода, выполняющих разные задачи в устройстве, мне нужна возможность легко тасовать эти потоки, не нарушая работу всего остального, мне нужно чтобы программа оставалась линейной и простой так долго, как это возможно. ОС дает мне все это. Я уже сталкивался при разработках с ситуациями, когда городил жуткий код чтобы в итоге он сделал тоже самое, что доступно из коробки под freertos. Самый ценный ресурс - время. Мегагерцев и мегабайтов полно, времени, обычно - нет.
Доброго дня. Спасибо Вам большое за познавательные видео. Только начинаю разбираться с Freertos и хотелось бы немного Ваше консультации. Пытаюсь большой проект адаптировать под ОС. Вот подсоединил через куб ОС, раскидал легкие задачи по приоритетам и таймигнам вызова - все очень хорошо, функционал заработал. И вот у меня есть большая функция расчетов, сей кусок кода занимает около 30кБ. Естественно, когда я эту функцию кладу в задачу у меня все вешается. Как мне его положить в Tasks? или вообще что мне делать? Расширять размер стека для данной задачи, как я понимаю? Спасибо.
На канале ещё будут видеоролики по операционной системе freeRTOS. Я постараюсь частично ответить на эти вопросы.
@@VladimirMedintsev Спасибо Вам большое
Как вы в keil включили всплывающие подсказки? (выпадающие списки в редакторе у курсора)
Та же проблема с авто подстановками!???
А эта freeRtos под капотом что-то вроде невытесняющей многозадачности с прерываниями по таймеру реализует, правильно понял? Т.е. если в какой-то таске, например, что-то зависло, вся система зависнет, как оно в мсдос было? Или там как в посикс с fork() / еxec(), таблицей процессов и т.д.?
зависнет только одна задача. этот факт легко определяется и вы можете ее перезапустить.
@@VladimirMedintsev вау, это круто, учитывая такое небогатое ресурсами окружение.
@@Влад-с7к5й В видео th-cam.com/video/wTK11IDpg7s/w-d-xo.html я рассказываю как определять загрузку процессора задачами, этот алгоритм можно использовать и для определения зависшей задачи. Ну или можно проще. Можно чтобы задача сама обновляла какой-нибудь флаг и тогда уже можно принимать меры к ее перезагрузке или лечению.
В FreeRTOS много разных настроек, в то числе и тип многозадачности. По умолчанию он вытесняющий, ток что зависания всей системы не будет.
Может работать как в вытеснящем, так и в кооперативном режиме, плюс в смешанном режиме.
А разве приоритет прерываний не должен быть меньше приоритета обработчика задач? А вообще прикольно , давайте больше видео про ос!
честно говоря не помню. что-то было на эту тему у них в документации. потом посмотрю.
приоритет прерывания может быть выше чем приоритет обработчика задач, но такое прерывание не может вызывать функции freertos напрямую
На ESP32 хотел изначально использовать или библиотеки Arduino, или напрямую язык Си, но как выяснилось что компания Espressif в своих библиотеках всегда использует FreeRTOS. Так зачем мне изобретать то что уже и так эффективно работает. Тем более что для 2-х ядерного процессора лучше использовать ОС, которая упрощает работу с железом.
есть еще nanoFramework от Майкрософт, он тоже поверх какой-то ОС работает, но программировать можно на C#. Для дотнетчиков это просто песня)
@@mvxburov Мне почему-то не удалось его завести на Visual Studio 2019 и опробовать. А так бы сказал что он компилирует, ассемблерные выходные листинги я отлично понимаю.
В целом верно, но только примеры выбраны неудачно. Из-за этого объяснения выглядят не очень убедительно. Нельзя объяснять преимущества многопоточности на примере ввода с "клавиатуры" (а в видео это основной пример), поскольку она реализуется исключительно на прерываниях. Не считая конечно новичков, кому кажется проще опрашивать в цикле :)
Лучше бы объяснили на реальном примере. Вот у меня был проект на AtMega128. На дисплей 128x128 выводится информация из нескольких источников: от часов, от барометра, от термометра, от таймера, от "клавиатуры" и нескольких аварийных кнопок и даже от радио. Оказалось, что удобнее всего реализовать посредством эмуляции многопоточности, когда "менеджер задач" поочередно вызывает "потоки" (по одному на каждый источник), а те, выполнив какую-то часть работы, передают управление дальше. Причем, задачи получения данных от датчиков и вывод на экран обработанных данных были разделены. Единственно, что те же кнопки использовали прерывания, запуская "поток", выводящий на дисплей информацию и проигрывая определенный сигнал. Вот где преимущества многопоточности облегчают написание кода, его отладку и читабельность. Думаю и у Вас нашелся бы подходящий пример из жизни.
Чудово роз'яснено! Дякую!
Скажите пожалуйста еще про другие ОС например riot-os
А я все искал, кто же меня просил про другие ОС видео сделать. :-) выполнено.
Пожалуй без разбора примера и указаний достоинств работы с FreeRTOS (например с приемом кода пульта и включением чего нибудь) Было бы лучшим аргументом.
я бы опредил пременимость RTOS так, если декомпозиция задачи укладывается менее чем в десять потоков, то применее RTOS скорее нежелательно и является "Overengineering", в таком случае лучше использовать конечный автомат, а чтобы код непревращался в"лапшу" просто аккуратно офрмлять код, больше использовать шаблонное програмирование, макросы
Был у меня один проект, где было пять почти не связанных друг с другом потоков. Написан был на автоматах, но весь код был тихим ужасом. Там свитчи были на 25-40 кейсов. Один поток работал с кнопками и GUI, второй через один UART работал с одной группой устройств по RS-485, третий через второй UART работал с другой группой устройств по шине K-Line, четвёртый работал с такими же контроллерами по шине CAN и пятый поток, получая все данные с остальных потоков, отрабатывал логику работы устройства. На FreeRTOS это было бы гораздо проще, эффективнее и быстрее.
Однако, это был камень AT90CAN128 и порты FreeRTOS под него на тот момент были кривоватыми, а девайс нужен был "еще вчера".
@@kardanium был у меня один проект, на один поток, код был ужасен, на FreeRTOS он бы стал сложнее, тяжелее и тормознее.
@@acrsofter Ясно, что бывают задачи, где ОС не нужна. Я в таких случаях пишу функции опроса таким образом, что только когда данные будут готовы, функция их вернёт. А иначе возвращает ноль или иной признак неготовности. А задержки используются только неблокирующие, с использованием системного таймера. Часто даже автоматы писать не приходится.
@@kardanium да, иногда кооперативной многозадачности вполне достаточно
@@acrsofter это говорит скорее о скиллах разработчика.
Расскажите о работе прерываний с ОС, они работают асинхронно от нее и используют стек текущей задачи и требуется выполнять дополнительные телодвижения в обработчике прерываний?
Прерывания используются точно так же как и без ОС. Единственное, для управления некоторыми функциями ОС из обработчиков прерываний надо вызывать специальные функции. Но это не сложно.
Vladimir Medintsev, про приоритет не сказали..
спасибо
Здравствуйте!
Интересует возможность адаптации примеров из CubeMX по работе с USB (CDC, CDC+MSD) под FreeRtos. Есть ли такие примеры в принципе? Или для примеров CubeMX лучше подходят машины состояний?
Пример не нужно адаптировать. Это не программирование получается а извращение. Пример необходимо изучать с целью научиться работать с технологией или периферией. Библиотеки USB от ST прекрасно работают с FreeRTOS.
Спасибо за обзор.
Спасибо
ув. автор, планируете ли обзор других RTOS систем? Напр. Mbed OS ?
Mbed OS точно не будет. Мы ее не используем внутри своей команды, не рекомендуем, а соответственно и обзора на нее не предвидится.
Всё пытаюсь понять, как именно происходит переключение контекста подпрограмм. На ум приходит только подмена адреса возврата при выходе из обработчика прерывания (как это делалось некоторыми утилитами в DOS).
Т.е во время работы одной программы срабатывает прерывание, диспетчер (в обработчике прерывания) сохраняет контекст и адрес возврата текущей программы, восстанавливает контекст и адрес следующей и "возвращает" управление. При следующем прерывании вторая программа меняется на третью и т.д.
Хорошо, если памяти у контролёра хватит, чтобы хранить контексты всех программ.
Наверное причина в том, что вы пытаетесь мыслить категориями привычными для IBM PC совместимых компьютеров. Вы и написали - "программ". По факту же мы имеем дело с небольшими задачами выполняющими те или иные функции. Разумеется памяти им хватит. На канале достаточно роликов по этой операционной системе, даже есть фрагмент где показывается как вывести в консоль реальную загрузку и стека и кучи. Можете посмотреть, взять там несколько строк кода и даже попробовать.
Всем привет ! Уж посмотрел Я и почитал коменты , и вот вопрос ко всем знающим . Если есть PIC . AVR. STM и нужна программа измерять температуру , вкл или выключать пару реле, дисплей , пусть будет . 1 - сколько займет памяти эта прога ? 2 - для таких PIC . AVR. STM задач , есть ли предпочтение , что лучше ? 3 - так что выбрать PIC . AVR. STM ?
Я бы выбрал stm32f042 в корпусе tssop-20. Влезет в 16 кило.
(Сейчас делаю что-то анологичное, dht22, вентиялтор на управлении ШИМ, передача данных на nrf24). Все на HAL, весит около 10кб (может чуть больше), с оптимизаций O2. Приемная сторона, экран ST7735+NRF24, влезает в 16 кило(оптимизация по O-size). И ко всему использую stmcubeide
Здравствуйте! Данную задачу можно решить на любом МК и разными способами, так что размер занимаемой памяти оценить сложно. Лучшем будет МК с которым знакомы. Если ни с чем не знакомы, то начните с Arduino. Самой простой под Вашу задачу будет достаточно.
Нельзя в прерывания засовывать большие куски кода, а как на счёт работы usb?
Обрабатывать в задаче используя семафоры
! о!; 14минута(прошло час) скелетное программирование, кооперативная многозадачность >>> OS...ОЧЕНЬ ДОХОДЧИВО!
Все яйца обычно в одну корзину не кладут, тот кто говорит надо аппаратную часть жестко вести жестко привязанную ко времени и freertos это неправильный выбор для техпроцессов - используйте свою периферию: ПЛИС, DSP и тд, а stm очень хорошо на FREErtos может дирижировать вашим оркестром при этом отображая данные на дисплей и отправляя/принимая уставки куда нибудь сразу по нескольким каналам ю, при этом можно что-то не критичное ко времени привязать на саму стм что-то вроде температуры, заряда акб и тд, осциллограф из него не сделаешь, дельта-сигма фильтр из него лепить? Один контроллер на функцию? Да это просто кошмар такое предлагать, тогда на устройство надо 5 контроллеров или очень толстый стм. Автор учит как использовать стм, а вот как его использовать с умом тут каждый должен вырасти сам.
Владимир, здравствуйте! Спасибо за видео, пробую работать с ОС в своем проекте. Сразу возник вопрос о определении размера стека для задач. Возможно вопрос новичковый, но было бы круто выделить немного времени в видео о стеке, логике расчета, методах оценки ресурсов МК в отладчике (как с РТОС, так и без нее).
Так вроде же есть видео про стек FreeRTOS. Я там даже на примере показывал как это делать.
@@VladimirMedintsev точно! я как-то проглядел. Спасибо
@@VladimirMedintsev Всё пересмотрел по FreeRTOS из плейлиста. Получилось запустить, почитать расход стека, все очень удобно. Эти видео - какой-то праздник! Еще раз спасибо.
Спасибо, отличный пример задачи для которой и даром не нужна ОСь. И, пожалуйста, не называйте конечный автомат "диспетчером задач".
Спасибо, очень содержательный комментарий. Но это диспетчер задач и я обещаю вам называть его так и впредь. Спасибо что смотрите. Не забывайте поддерживать канал.
@@VladimirMedintsev наверное, у Вас сложилось впечатление что просто "а Баба-Яга против" (с). Нет, я не злостный противник операционнок на МК (ладно, противник, но это уже другая история). В первую очередь, я противник усложнения там, где не надо, и внедрения лишних точек отказа, где не просили. Пример из практики: на очень похожем проекте, но с крайне жесткими ограничениями по таймингам, один товарищ тоже решил что FreeRTOS - быстрая, а такты - дешевые. Почему у него не получилось докупить оптом тактов в уже выбранные МК, объяснять, думаю, не надо. В итоге, все было выброшено в окно, и переписано на Bare Metal. Вышло 46 строк ассемблерного кода на все про все. Пара часов разработки, пара часов в QA, и готово. Воюй мы с ОС, до сих пор сюрпризы по углам отлавливали бы. Впрочем, я уже лет 6 программатор в руках не держал, может что и изменилось с тех пор. Хотя, что там могло измениться? Частоты чуть подросли, да память еще чуток подешевела? Не тянет на принципиальные изменения.
@@ЕвгенийАвдеев-к7н У меня совсем не сложилось впечатление что "Баба-Яга против", после описанного вами явственное чувство другой пословицы "Дуть на воду, обжегшись на молоке". Вы пришли под учебное видео рассказывающее о том, как можно применить операционную систему и какие преимущества в скорости разработки она дает и рассказываете о случае проекта с жесткими ограничениями по таймингам.... Т.е. ваш товарищ ошибся при выборе подхода к построению скелета программного обеспечения для слишком слабого для решаемой задачи микроконтроллера и теперь из этого следует, что использование операционной системы это плохо и это точка отказа? Ну ладно, я готов смириться с тем фактом что это ваше мнение. Честно говоря это как в известном анекдоте, что микроскоп плохой, плохо консервные банки открывает. Я вашу позицию понял, спорить не буду...
@@VladimirMedintsev использование операционной системы - не плохо. Плохо, когда ее пытаются натянуть туда, где она не нужна. Равно как и плохо, когда изо всех сил пытаются обойтись без нее, когда очевидно, что она нужна. Все верно, для каждой задачи - свой инструмент. Изначальный посыл первого поста был, что в качестве примера как раз приведена крайне простая задача, которая с высокой долей вероятности без ОСи решается быстрее, чем с нею. Впрочем, я Вас понимаю: в учебный ролик трудно уместить сложный пример, с МК, который должен хороводить дюжиной устройств, читать тачскрин, да еще и в эфир шуметь. Тогда любой начинающий разработчик сбежит в панике :-)
Необходим доскональный разбор этой системы, желательно с "подводными камнями"... Понимаю, что учиться на собственных ошибках хорошо, но таким образом уходит слишком много времени.
На этом канале уже есть несколько роликов по FreeRTOS.
@@VladimirMedintsev ага... Значит будем рыть😊😊😊!!!
Огромное спасибо!
Как сильно отличаются понятия "сложный код" для контроллеров/процессоров и для высокоуровневых приложений для серверов/десктопов и т.д.
Пожалуй, содержимое ролика никак не коррелирует с его темой (в заголовке). После прослушивания возникает четкий ответ на вопрос "Почему использование операционной системы оправдано даже в небольших проектах" - да ни почему. Просто так автору кажется. В небольших проектах может быть как раз лучше применить простой дешевый чип с малым объемом памяти, куда FreeRTOS никак не впишется.
Оправдано тем, что код получается чище и понятней - каждая мини-задача в отдельной функции и без лишнего мусора. Такой код проще и быстрее писать, отлаживать и поддерживать. А время сейчас стоит дороже чипов.
так для автора может быть небольшой проект это не помигать светодиодами, а какая-то замороченная херня
вот он и говорит, что с виду вроде бы все просто, но есть куча состояний и все они как бы сами по себе должны работать
и такое лучше оформить при помощи ртос, а не автоматом
больше сожрет памяти, зато меньше писанины
если ты бабло получаеш за проект, а не по часам, то в твоих же интересах написать это все как можно быстрее и чтобы через год ты мог понять, что ты там написал и встроить новую плюшку
а то бывает так, что новая плюшка потянет переписывание всего кода
microsin net, на совремнные чипы почти на любой фриртос влазит..
Anatoliy Gavrilov, у автора видео лишь иллюзия этого. Он декларирует эти цели, представленный псевдокод их не реализует.
@@ЮристЧастнойПракитки Тут ключевое слово "почти". Таки да, именно так. Поэтому нельзя утверждать, что "даже в небольших проектах использование FreeRTOS оправдано". Не все чипы "современные", и ни на все "современные" чипы "влазит" RTOS. Всякий инструмент хорош на своем месте.
Необходимо указать важный момент. Если Вы пишете программу , НАПРИМЕР, передачи по радиоканалу потокового аудио, то FreeRTOS, не справится с подобными задачами и необходимо написать программу в классическом режиме последовательный код с прерывателями ит.п., подсчитывая в дебаггере каждый такт,, чтобы соблюсти точные временные слоты оцифровки и передачи пакета с накопленными сэмплами. . Поясню. Вы указали, что квант времени отводимый FreRTOS 1 ms. Я в программе каждые 125 мкс оцифровываю внутренним АЦП аналоговую речь, попутно накапливаю оцифрованные сэмплы во внутреннем буфере ОЗУ порядка 300 байт, при заполнении буфера я передаю его по SPI в CC1100 (радиопередатчик) . При употреблении FRERTOS у меня все поплывет, особенно в программе приемника , теорема Котельникова нарушится, пакеты с цифровыми сэмплами (речью) будут приходи не в нужные слоты времени, соответственно на ЦАП в каждые 125 мкс не будет поступать очередной сэмпл для декодирования. Так что,FRERTOS не поможет для решения данной задачи. для устройств, которые разрабатываете Вы, и для устройств которые не требуют точного до 1 мкс подсчета выполнения определенных частей программ и промежутков между ними, FREERTOS самое то.
Хотя я возможно не совсем прав.
Использование операционной системы никак не влияет на быстрые процессы если они вам необходимы. DMA, таймеры, прерывания, это все никто не отменял.
@@VladimirMedintsev Владимир, будьте добры посоветуйте какую-нибудь литературу по FREERTOS, желательно англоязычную.
freertos. org там все в виде pdf есть. прям много.
Так. Созрел глупый вопрос: А при переключении на другую задачу, значения переменных и состояние выполняемой сохраняется? Судя по тому, что Вы упомянули отдельный стек, вроде ответ должен быть да. Но можно для деревянных уточнить ))
Да, сохраняется.
@@VladimirMedintsev Спасибо, очень помогли понять в каком направлении копать. Столкнулся с такой необходимостью, когда не плохо бы, чтобы одновременно выполнялись несколько задач, параллельно так сказать. Понятно было, что решение где-то есть.. но где... ))
@@VAscetic Каждой задаче под FreeRTOS выделяется собственный стек, одна и таже функция может использоваться для нескольких одинаковых задач (например, для обработки портокола на нескольких последовательных портах одновременно*), и стек у каждой задачи всё равно свой. Статические переменные работают как обычно.
* Не совсем одновременно, конечно, а под управлением диспетчера задач.
@@DmitryKandiner Ага, спасибо, я в целом понял концепт. По сути, очень сильно такого плана решение мне требовалось пока 1 раз, и то более менее обошёлся. Когда с ETH учил контроллер работать, для поддержания одновременно нескольких активных соединений TCP по разным портам. А так, в большинстве случаев, достаточно стандартного набора прерываний, тем более если в контроллере есть DMA. Ну или я ещё в сложные задачи не залез :)
@@VAscetic как вариант -- построение веб сервера. Один процесс только принимает новые соединения, и запускает дочерние процессы на каждый запрос. А запросы, в свою очередь, обрабатываются каждый своим экземпляром одного и того же кода (важно не полагаться на статические переменные -- они общие для всех). По окончании обработки процесс закрывает соединение и самоубивается.
Потому что микроконтроллер СТМ32 имеет в составе процессор Кортекс М4. А кроме него ещё память и много чего.
смотря какая серия
ести и с ARM Cortex М0, М0+ и с М7, М3...
А знаете ли Вы, почему появляется потребность вот в таких видео? А потому, что на дисциплине "информатика" операционная система - это системное ПО, задачей которого является управление файлами. Я не шучу. Именно в такой формулировке. А что такое ядро, системные сервисы и даже, банально, механизм прерываний - этого знать не нужно. И ладно ещё общеобразовательный предмет. В ВУЗе дают такие определения!
Кому интересно, Тёненбаум, "Современные ОС". Всё понятно и доступно.
Видимо это явление консерватизма. Первые ОС действительно создавались вместе с файловыми системами и предназначались для работы с файлами. MS-DOS тоже зовётся операционной системой, однако многозадачности там нет.
@@kardanium не соглашусь и оспорю. Первые ОС - как раз таки пакетные загрузчики вычислительных задач. Тогда ещё понятия "файловая система" не было. Была перфолента, стопка перфокарт или (в лучшем случае) пара десятков метров магнитной ленты. Задача - последовательный запуск заданий и вывод результатов куда-нибудь (чаще, на печать).
@@mnanorn Ну так, тогда тоже небыло многозадачности, ядра, диспетчера и прочих подобных вещей. Был просто код, который читал перфоленту, заносил ее в ОЗУ и отдавал загруженной программе управление. Позже ленты заменили на диски и следовательно, на файлы. Многозадачность появилась позже, когда вычислительные ресурсы и развитие компьютеров стали это позволять.
@@kardanium Вы считаете прерывания многозадачностью? Уточню вопрос: Вы считаете возможным организовать действительную многозадачность на одном вычислительном ядре?
@@kardanium и, да, изначальная тема комментария была "подмена действительной роли операционной системы в образовательном процессе". )
уважаемый автор,извиняюсь за то,что не по теме,но : у вас есть курс по программированию stm32 для начинающих? или может посоветуете, где на ваш взгляд это доступно изложено.
go.redav.online/198c03d37cf84410
Это моя программа обучения.
@@VladimirMedintsevда ,но на курсе не написано stm32,а только ардуино.Так как бы хочется четко понять есть STM 32 курс или нет и сколько занятий?
@@Сергій-ш5б8э вот очень и очень хорошая программа дпо.фркт.рф/sse совместно с МФТИ. И есть диплом
Тут прям холивар развели! Надо-не надо...Не нравится frtos - пиши свой диспетчер... В любом раскладе задачи быстрее 0,5-1мс придется выполнять, изгаляясь, где-нибудь в прерывании или еще как придумывать... А все диспетчеры и оси нужны для обработки МЕДЛЕННОЙ БИЗНЕС-ЛОГИКИ!!! Когда у тебя дохрена кнопок, дофига светодиодов, датчики, цапы, ацп, и все работает независимо - иди собери все это в кучу! Вот тут и выруливают помогаторы!
Контроллер обычно приемняется в адачах с жестко заданными таймингами и последовательностью переключения,а тут совершенно непонятно что и как работает
Если вам нужны "жестко заданные тайминги" то возьмите таймер и он вам очень точно измерит временные интервалы. Что касается последовательности переключения, то совсем не все задачи так примитивны как вы пытаетесь это представить. Есть весьма сложные алгоритмы. И в этих случаях применение операционной системы экономит много времени как на разработку так и на отладку. Более того, использование FreeRTOS весьма заметно повышает общую живучесть системы в целом.
И все же, это микроконтроллер! За видео спасибо.
На самом деле это однокристальная микро ЭВМ , но так никто не говорит потому что язык сломаешь.
@@2Aleksk соглашусь, что это может быть одним из адекватных вариантов обозначения
А почему бесконечные циклы в задачах выполнены через for? В этом есть какой-то сакральный смысл?
Нет. Это дань моде. По сути одно и тоже, что и while
Все идет к усложнению архитектуры проца.. Уверен появится аппаратный менеджер задач, который например будет включать задачи по таймерам и отводить им сколько нибудь тактов... Потом выяснится, что два таких проца еще лучше чем один, потом защитят память кольцами защиты от вирусов, писАть под stm32(64/128/../2048) без ОС станет невозможно, выдут книги по программированию для ОС ртос.... Уверен мы наблюдаем ускоренную эволюцию от процессоров 8080..i486,...233mmx,....core i3.... и параллельно ms-dos...windows 3.11,...NT...XP....
На самых крупных микроконтроллерах STM32 уже запускается Linux. А в простых это не нужно.
Классная ос.
Пожалуйста, пожалуйста, пожалуйста ответьте на вопрос, а то я не понял: если у нас, например, всего 5 задач в ОС, на каждую проц тратит 1 ms, что происходит на 6-ю ms, он переходит на первую задачу или ждет 995 ms, потом переходит на 1ю задачу?
на первую задачу, если она не в простое. подробно тут - th-cam.com/video/wx3-oESwx_M/w-d-xo.html
Никого не слушайте. Хэйтеры хэйтят, тролли тролят. Ничего нового.
Просто не тратьте свое психическое здоровье на них.
А дзюберы дзюбят)
У меня это видео и первая часть трилогии FreeRTOS испорчено.
Проверил на 5 (пяти) разных компьютерах. Все работает. Авторы роликов заливают их на ютуб, дальнейшее от нас не зависит.
Да, согласен, только на одном из 5 глючит. Извините что не исправил.
В где вы читаете лекции про freeRTOS, если не секрет?
Да нет не секрет. Я частным образом организую группы и с ними занимаюсь.
@@VladimirMedintsev Новому подписчику не хватает данных о локации в Вашем ответе ;)
Если квант времени у ОС 1мс, как быть в случае, когда имеется задача, которую нужо успевать обрабатывать за время от 1мс? Эта функция или реакция на внешнее воздействие, или она в принципе должна вызываться с периодом около 1мс.
дык таймеры и прерывания.
@@VladimirMedintsev Т.е. имеется ввиду совмещение двух подходов? Задачи не требовательные к времени отклика - крутим в RTOS а задачи которым нужно обеспечить быстродействие пишем по старинке? Я в своё время писал много вещей у котрых большинство функций не требовательно ко времени, т.е. их можно выполнять с периодом 100мс просто по очереди. Но есть обработка внутренней логики которую нужно успеть за 1mc. Ещё есть фильтры для которых важно тактирование с постоянным периодом. Есть внешние прерывания. Есть UART в который нужно ответить желательно за 1-2мс. Я написал свой диспетчер не требовательных к времени отклика задач, и да, согласен с Вами, написание таких вещей тянет за собою много времени. Но всё равно остаётся ещё много задач, для которых время отклика важно. И всё это крутится в mainloop и да, на pipelined 8051 8МГц loop time получается около 1мс. Меня не отпускает мысль, что при использовании RTOS я бы мог обрабатывать быстрые задачи ещё быстрее... Это возможно?
@@Siliverst Из прерывания можно переключать контекст на более приоритетный процесс.
Так и не "пересели" на CubeIDE?
Я говорил что учебные штуки останутся на Keil. Он более распространен. В кубиде только коммерческие за денежку.
@@VladimirMedintsev она вроде бесплатная
@@Asmcavr Кэп? Вы ли это? Я в кубеиде делаю коммерческие проекты, за которые деньги получаю именно потому что она бесплатная чтобы не нарушать лицензионное соглашение и законы.
@@VladimirMedintsev Сорян, я неправильно вас понял).
@@VladimirMedintsev Так теперь считай все и делают, точнее пишут в комфорте, в Keil / IAR, а на продажу пересобирают из под CubeIDE ;)
Еще бы отладку с программатором в этом CubeIDE допилили, а то здорово подбешивает шиться вне среды
Алгоритм который вы описали можно реализовать и без применения FreeRTOS
, будет работать надёжнее но читаться хуже
Да , и это будет AiRTOS )))
Ну кому что, можно и на операционной системы FreeRTOS делать, но проще и быстрее чтоб работало сделать всё на прерываниях. Сработало прерывание, получили какую то информацию, выставили флаг событие, разбудили основную программу. Программа проснулась всё это обработала и опять в сон.
Если FreeRTOS уже есть в портированном состоянии под данный контроллер, то как раз использовать её много проще, нежели настраивать прерывания. Да и что там портировать...
Во-первых: а если задач больше, чем прерываний? Во-вторых: вы уже сами начали описывать что-то вроде простейшего диспетчера в главном цикле, который флаги проверяет. Добавляем сюда необходимость приоритетного выполнения некоторых задач, софтовые задержки, детерминированное время отклика на событие - и вуаля, у нас страшный франкенштейн (если он работает вообще), поддерживать который сам замучаешься. А уж отлаживать. И куча зависимостей между кусками кода. Поправил одно - отвалилось другое. Добро пожаловать в мир говнософта.
Роман Роман, предложенный автором способ, тоже не решит описанную вами проблему. Но в целом ОС полезна, если использовать где и как надо.
Посмотрел коменты. Прям из крайности в крайность ))) FreeRTOS имеет 3 типа многозадачности, в тч кооперативную и гибридную. Ну т в целом, сражаться за каждый такт процессора смысла нет, тк стоимость такта снижается. К тому же, всегда приятно иметь "коэфициент спокойной ночи" в виде некоторого запаса по ресурсам и перспективам.
Нужно еще одно видео - ибо вообще непонятно как скрестить FreeRTOS с задачей требующей высокого быстродействия. Вот вводные: оптический датчик с 1800 линий на оборот стоит на шпинделе станка, который имеет максимальную скорость 2000 оборотов в минуту - нужно получить данные о положении шпинделя и в зависимости от этого вращать шаговый мотор - логику вы эту в прерывание не засунете - ибо там расчетов много и из этого вы "отодвинете" время срабатывания других прерываний. Засунуть логику обработки в задачу, которая выполняется не чаще 1мСек и имеет время старта "как FreeRTOS решит " - это вообще не вариант. Вот как вы можете решить данную задачу с FreeRTOS ?
А если честно - я вообще не понимаю - почему FreeRTOS - это система РЕАЛЬНОГО времени ибо операционка MS-DOS вот это система РЕАЛЬНОГО времени, а та же Windows это уже операционка НЕРЕАЛЬНОГО времени и там тоже тайминги в 1мСек и время старта задачи там тоже "как операционка решит".
Если считать программно каждый тик энкодера - то да, непосильная задача для любого- даже самого быстрого процессора.
Но вместо подсчётов тиков энкодера - достаточно опрашивать его аппаратную часть на таймере, через фиксированное количество времени. В этом случае считается не его текущее положение - а изменение за фиксированное время, со сдвигом к нулю. В этом случае доступен весь диапазон таймера работающего на энкодер, и отпадает необходимость как-либо управлять его переполнением.
Ведущий мотор может вращаться с низкой скоростью, для того чтобы ловить это состояние - используется дробные числа. Старшая часть повторяет значение аппаратного энкодера, а младшая - дробные числа.
Для ведомого шагового двигателя считается положение в которое он должен встать через фиксированное время того-же таймера, что запускает считывание таймера энкодера. Тут тоже дробные числа, и тоже с переходом через ноль. Перемножаем дробное от энкодера - и получаем любое разумное соотношение скоростей вращения. И да, это угловая скорость.
Дык вот, считывание и управление происходит в прерывании, или через дма. А обработку можно делать в основном цикле. Потому как на фиксированную задержку в 5-30мс - механика станка (инерция) просто не в состоянии отреагировать.
Общая задача достаточно простая, и может целиком выполняться в прерывании (буквально несколько строк).
Ос может понадобится для работы с экраном и кнопками. Потому как реакция человека заметно ниже требований к железу, тут +- лапоть к задержкам - вообще никто не заметит.
@@avi-crakhome2524 - я завис на вашей фразе и дальше уже не читал: "Но вместо подсчётов тиков энкодера - достаточно опрашивать его аппаратную часть на таймере, через фиксированное количество времени". Аппаратная часть промышленного оптического энкодера есть фотодиод и как вы его можете опрашивать периодически чтобы узнать положение шпинделя станка - я даже не представляю.
@@НиколайПр-з3в Аппаратный таймер чипа stm32xxx - режим энкодера. Вход две линии от промышленного энкодера, выхлоп - значение счётчика таймера. Вот именно это значение и нужно считывать через фиксированные промежутки времени.
@@avi-crakhome2524 спасибо - посмотрю данный вариант - но "фиксированные промежутки времени" через freeRTOS в 1мСек???
@@НиколайПр-з3в Не через, а совместно. В ос есть таймер, который фиксировано срабатывает каждую 1мс. Если в его прерывание добавить немного кода - система не рухнет.
А вот изменение коэффициентов множителей для ускорения/торможения и начальную синхронизацию - можно делать через freeRTOS. Этот код жирнее, и не требует моментальной реакции.
*_Что за программа или компилятор?, пожалуйста, напишите название таймкод _**_2:02_*
Это Keil uvision
@@VladimirMedintsev Большое спасибо)
Riot OS пробовали использовать?
Пробовали, для наших проектов она не подходит.
конечно интересно, но вот на столе лежит две конкретные задачи - зарядка LiFePO4 100кГц ШИМ с ПИД-регулятором на stm32f303 и передача спектра звука 32кГц (естественно через fft) с I2S по tcp на комп на stm32f745, ни в одном из случаев freeRTOS ничего не успевает, о каких osDelay или квантах в мс идёт речь, если нужны мкс? в первом случае, кстати даже HAL не успевает, перешёл на LL, приходится писать отсебятину, если речь идёт о чтении кнопки, выводе на дисплей, где сотня миллисекунд вообще ничего не решает - одно дело, если же настоящий real time с квантами в микросекунды, то нужно намного глубже разбираться во freertos, чем в прерываниях и DMA
Для зарядки лития нужна скорость ответа регулятора в 100кГц?) Да, ШИМ может понадобиться в 100кГц, но используйте для этого хардварный таймер. А пид-регклятору и 1кГц overkill.
@@NoName-yp9to . Ну ну. Сравнил шип 1кГц и 100кГц. Там какбы индуктивность (трансформатор) совсем разные по габариту получаются)))) Автор выше прав - если что-то медленное и неответственносое, то freertos рулит. А когда надо выше 1кГц то- сосай мосай
@@vladevro222 а теперь перечитайте то, что я написал выше. Вобще то я предложил шим генерить с частотой 100кГц аппаратным таймером, а с частотой 1кГц - только лишь обеспечивать регуляцию. А уж если нужна какая то быстрая обратная связь (например по току КЗ), то в большинстве стмок есть компаратор.
@@NoName-yp9to зачем страдать если написать напрямую просто проще? Без абстракции ради абстракций. Просто сделать задачу. Единственно зачем там стм вопрос. Там какая нить аттини или пик вполне.
Вы просто не захотели заниматься трассировкой. И не было бизнес-заказчика, который правильно бы подсчитал все свои текущие и будущие затраты. Я подозреваю, что для каждой из Ваших задач есть аппаратные решения. И для заряда аккумулятора, и w5500, и, возможно, какой-то dsp со встроенным fft. Вам останется только взять кракозяблу для управления периферией. Код - минимальный, поддержка - дешевая, конец производства - не приговор, затраты на переписывание управляющего кода - минимальные. FreeRTOS - для правильно организованного проекта.