STM32 + FreeRTOS или Почему использование операционной системы оправдано даже в небольших проектах.
HTML-код
- Опубликовано: 8 мар 2020
- В ролике рассказывается о различных подходах к программированию и реализации переключения задач на примере операционной системы FreeRTOS. Ролик является компиляцией из лекций прочитанных за последний год и рассказывает о том, как использование операционной системы упрощает устаревший подход к программированию.
Вышла книга по операционной системе FreeRTOS.
Видео о книге "FreeRTOS. Операционные системы микроконтроллеров" - • Книга "FreeRTOS. Опера...
Бумажная версия книги - electronics-krd.ru/magazin/pr...
Электронная версия книги - electronics-krd.ru/magazin/pr...
Оглавление книги - disk.yandex.ru/i/3ZKwKQTgQnlHoQ
Пример страниц - disk.yandex.ru/i/WCeD_CA3aMbiOQ
Группа в телеграмм - t.me/vladimir_medintsev
Код примеров из книги - disk.yandex.ru/d/Bqa2adpEZ3Mo6w
По вопросам сотрудничества - vmedintsev@yandex.ru 
Наука
Как раз сейчас и решаем схожую задачу, используя RTOS: нужно быстро и часто опрашивать акселерометр, анализировать полученные данные, при этом управлять контроллером электропитания, что-то периодически (хотя бы 4 раза в секунду) обновлять на экранчике и при этом обмениваться с сервером информацией через очень медленную LoRa. Задачи слишком разного масштаба времени. Можно, конечно, самому городить семафоры, очереди и т.п., но если это уже всё сделано во FreeRTOS, то зачем изобретать велосипед?
Тем более, что прерывания тоже никто не отменял. Например, под опрос акселерометра сделать задачу с семафором, а открывать семафор -- в прерывании по окончании чтения.
Спасибо большое за обзор! Очень многое стало яснее...
Владимир, спасибо огромное за ваши видео и цикл о freeRTOS особенно. А что ж Вы запись лекций по МК не публикуете?!
это же будет скука скучная. То, что хорошо на лекции для видео полный ужас. Представляете час про одно и то же. Я стараюсь делать видео не утомительными по длине.
Ну не знаю... Отдельным плейлистом... Воду отрезать или другой канал организовать...
Поддерживаю, очень хотелось бы посмотреть лекции по контроллерам
Спасибо! Наипонятнейшее обоснование пользы использования ОС
Наконец-то доступно объяснили для чего нужен freertos😁 Спасибо за видео!
Посыл конечно понятен. Не понятно только, почему по мнению автора есть только 2 альтернативы: последовательный код и freeRTOS(или любая другая RTOS). Для 99% задач которые делают на стмках, хватит банальной event-driven системы, в отдельных случаях вкупе со стейт машиной. И первое и второе пишется за 30 минут и занимает минимум места. RTOS это хорошо, но это чаще всего стрельба из пушки по воробьям. Не надо так.
Я новичок с 12-ти летним стажем...и половину слов не умею реализовывать"event-driven системы, в отдельных случаях вкупе со стейт"... в дальнейшем научусь, но ОС доступный инструмент int_32t, забивать гвозди в int_8t!
Десять благодарностей вам :)
Спасибо за доступную подачу информации. Пока сижу на AVR, делаю хобби-проекты. Крайний проект, после реализации на AVR, с помощью вашего канала планирую перевести на STM32. Еще раз спасибо и надеюсь что терпения на развитие канала Вам хватит, а в том что сумеете подать актуальную информацию в доступном ключе-у меня сомнений нет.
Хватай на али "stm32f103c8t6 board" + прогер-отлдачик "STLink2" за 100р. Качай CubeMX + Keil5, 2копиасты кода, 5 кликов мышки и проект готов :)
А не заработает, врубай пошаговую отладку как белый человек и смотри где ступор
Первые 3 минуты изучал пол часа.... магия раскрыта, БлагоДаря Вам!
Ну я прямо не знаю сколько тонн лайков надо ставить))) Сам с FreeRTOS уже 5 лет работаю в коммерческих проекта и глубоко убежден, что что-то серьёзное сделать без оной можно но ОЧЕНЬ сложно.... А Вы так доходчиво народу объяснили что да как и по чём)))
Пожалуйста поподробнее: 2 таймера с выводом ШИМ и ввод-вывод по USB можно ли считать настолько сложной задачей, что без FreeRTOS не обойтись?
:)
@@Wo_Wang есть разница между "не обойтись" и "некомфортно работать". Проще - с операционкой, как минимум протокол общения (поверх стека USB) я бы выделил в отдельный процесс.
Спасибо, полезная информация
Здравствуйте!
Интересует возможность адаптации примеров из CubeMX по работе с USB (CDC, CDC+MSD) под FreeRtos. Есть ли такие примеры в принципе? Или для примеров CubeMX лучше подходят машины состояний?
Пример не нужно адаптировать. Это не программирование получается а извращение. Пример необходимо изучать с целью научиться работать с технологией или периферией. Библиотеки USB от ST прекрасно работают с FreeRTOS.
Спасибо, да действительно удобный инструмент
Спасибо вам , открыл для себя ОС - Ртосс !!
"... код становится не сильно легко читаемым..." - Класс!!!!!
Спасибо, подчерпнул многое для себя, потихоньку отстраняюсь от ардуины
Спасибо! Это то что надо!
Классно 👍👍 спасибо вам за данное видео... Я когда кодил под Ардуино, пытался реализовать что-то подобное. Пытался написать ОС для микропроцессоров, но мои навыки программирования на чистом C не позволили сделать подобную ось (более 3 лет разрабатываю программы на C++/C#), а тут есть готовый велик, как говорится "садись и едь!".
Отличный обзор. Прошу рассказать особенности работы виртуализации с dma , какие существую подходы для качественной работы
Доброго дня. Спасибо Вам большое за познавательные видео. Только начинаю разбираться с Freertos и хотелось бы немного Ваше консультации. Пытаюсь большой проект адаптировать под ОС. Вот подсоединил через куб ОС, раскидал легкие задачи по приоритетам и таймигнам вызова - все очень хорошо, функционал заработал. И вот у меня есть большая функция расчетов, сей кусок кода занимает около 30кБ. Естественно, когда я эту функцию кладу в задачу у меня все вешается. Как мне его положить в Tasks? или вообще что мне делать? Расширять размер стека для данной задачи, как я понимаю? Спасибо.
На канале ещё будут видеоролики по операционной системе freeRTOS. Я постараюсь частично ответить на эти вопросы.
@@VladimirMedintsev Спасибо Вам большое
У меня в usart по дма иногда пропадает посылка на прием при использовании freertos, точно такой самый код, но без операционки, за ночь при тесте модбаса дал всего лишь две ошибки при 256000 кб/с, не знаю, плюс для реализации canopen нужно прерывание 1мс и проц stm32f407vet6 не может обслужить программу где одновременно используется 5 интерфесов и 200 кбайт кода...принял решение отказатся от операционки
Хах, всё то у вас просто получается, как в примерах аля "помигать светодиодом". А не забыли ли вы упомянуть про тонкости синхронизации данных (в которых нужно в принципе иметь хорошие скилы в многопоточном программировании), трудно отлавливаемые дедлоки, тонкости вызова функций ос в контексте прерываний? В небольших проектах freertos никак не оправдан, всегда можно сделать систему событий, софтовые таймеры и практически всегда работать в контексте главного цикла и не заботиться о синхронизации. Вот реально freertos может быть оправдан там где куча долгих синхронный операций, например работа с bsd сокетам (интерфейс которых эмулируется через lwip) - да тут код будет куда короче и стройнее чем работа асинхронно.
Золотые слова, вот и я о том же. Автор видимо никогда многоточечных приложений не писал. А дедлоки это еще и меньшая из бед(ее изобразить сложнее), хоть и очень противная. А вот логика работы, не так как задумал - легко. И не обязательно гонки переменных, просто выполнилось не в той последовательности или данные разрушила, или обратилась к полупустому указателю и так далее. Тут занимался оптимизации одного своего проекта. Нашел ошибку, а суммарный аптайм десятки лет(всех экземпляров), не проявлялось только потому, что ошибка четная, т.е. их 2, вторая маскирует первую... А критическую секцию туда нельзя, слишком "тяжелая" даже для сервачных процов, а тут МК, хи-хи. Весь рак мозга начинается когда нельзя сильно обкладывать в кретические секции, да если все ими обложить - нахрена козе баян(вообще многопоточность)
Виталий Алпатов, особенно пример с клавой доставил, да и уарт не лучше. А ведь так хорошо начиналось видео, все в одной задаче))
Кстати, Владимир, Ваше видео дало мне повод задуматься, что возможно нижеописанную мною проблему можно реализовать с помощью FreeRTOS. Вы мне дали повод для размышлений и изучения FREERTOS.
Как вы в keil включили всплывающие подсказки? (выпадающие списки в редакторе у курсора)
Та же проблема с авто подстановками!???
А эта freeRtos под капотом что-то вроде невытесняющей многозадачности с прерываниями по таймеру реализует, правильно понял? Т.е. если в какой-то таске, например, что-то зависло, вся система зависнет, как оно в мсдос было? Или там как в посикс с fork() / еxec(), таблицей процессов и т.д.?
зависнет только одна задача. этот факт легко определяется и вы можете ее перезапустить.
@@VladimirMedintsev вау, это круто, учитывая такое небогатое ресурсами окружение.
@@user-hm8yh7mz8u В видео ruclips.net/video/wTK11IDpg7s/видео.html я рассказываю как определять загрузку процессора задачами, этот алгоритм можно использовать и для определения зависшей задачи. Ну или можно проще. Можно чтобы задача сама обновляла какой-нибудь флаг и тогда уже можно принимать меры к ее перезагрузке или лечению.
В FreeRTOS много разных настроек, в то числе и тип многозадачности. По умолчанию он вытесняющий, ток что зависания всей системы не будет.
Может работать как в вытеснящем, так и в кооперативном режиме, плюс в смешанном режиме.
уважаемый автор,извиняюсь за то,что не по теме,но : у вас есть курс по программированию stm32 для начинающих? или может посоветуете, где на ваш взгляд это доступно изложено.
go.redav.online/198c03d37cf84410
Это моя программа обучения.
@@VladimirMedintsevда ,но на курсе не написано stm32,а только ардуино.Так как бы хочется четко понять есть STM 32 курс или нет и сколько занятий?
@@user-xs6mu8bc9q вот очень и очень хорошая программа дпо.фркт.рф/sse совместно с МФТИ. И есть диплом
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 :)
Братан! Пиши на русском языке, а то скоро вы его совсем забудете!
Вот такой вопрос. Если представить что у нас есть 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 сделает на какое-то колличество циклов больше, потому как нагрузки у неё меньше.
Пожалуйста, пожалуйста, пожалуйста ответьте на вопрос, а то я не понял: если у нас, например, всего 5 задач в ОС, на каждую проц тратит 1 ms, что происходит на 6-ю ms, он переходит на первую задачу или ждет 995 ms, потом переходит на 1ю задачу?
на первую задачу, если она не в простое. подробно тут - ruclips.net/video/wx3-oESwx_M/видео.html
Спасибо за обзор.
Спасибо за ваши видео. Могли бы вы дать информацию, где описывается FreeRTOS доступным языком? Хочется узнать по подробнее.
у них на сайте freertos. org
microsin.net/programming/arm/freertos-part1.html
Как сильно отличаются понятия "сложный код" для контроллеров/процессоров и для высокоуровневых приложений для серверов/десктопов и т.д.
Расскажите о работе прерываний с ОС, они работают асинхронно от нее и используют стек текущей задачи и требуется выполнять дополнительные телодвижения в обработчике прерываний?
Прерывания используются точно так же как и без ОС. Единственное, для управления некоторыми функциями ОС из обработчиков прерываний надо вызывать специальные функции. Но это не сложно.
Vladimir Medintsev, про приоритет не сказали..
ув. автор, планируете ли обзор других RTOS систем? Напр. Mbed OS ?
Mbed OS точно не будет. Мы ее не используем внутри своей команды, не рекомендуем, а соответственно и обзора на нее не предвидится.
Спасибо, я с первого раза понял преимущества ос. Тут получается хороший мултитрединг, каждый таск получает своё время. На интерапты хорошо и сразу можно отреагировать.
Заказал себе микро контроллер, попробую...
Подскажите, по поводу объёма кода в обработчике прерываний, какие есть ограничения или правила?
Правило одно вы должны провести внутри обработчика как можно меньше времени. А это значит не делать задержек, не использовать таймауты. Чем быстрее выйдите из обработчика, тем лучше.
@astrahard Нечаев Вы сами читаете что пишете? Я сказал человеку, что в обработчике прерывания необходимо проводить минимум времени, это является безусловным требованием. Т.к. в любой момент может наступить новое прерывание от любого другого источника. Что в конечном итоге приведет к переполнению стека. Отсюда логично и требование не использовать таймаут и задержки в обработчике прерывания. Более того, это не мое личное придуманное мнение. Ровно то же самое можно прочитать в документации на FreeRTOS и также во всех известных мне учебниках программирования. Более того обработчики прерывания в пределах одного уровня приоритета друг друга не вытесняют. Так что осторожнее с оценками, пожалуйста.
@astrahard Нечаев Прежде всего я опираюсь на написанное в документации по FreeRTOS, а там прямо указано что обработчик должен быть как можно короче по времени, чтобы прерывания не накладывались друг на друга. Тут без разницы у вас микроконтроллер или большой компьютер. Система прерываний она не меняет своего смысла. Во-вторых я руководствуюсь написанным на сайте Cortex это как бы разработчик ядра микроконтроллеров. Ну а в третьих, programming manual на наши микроконтроллеры. Но если все это не заслуживающие внимания документы, то не проблема снимаю шляпу. Вы видимо великий специалист и знаток вопроса. Даже спорить не буду.
Огромное спасибо!
В общем как многопоточное программирование в каком-нибудь дотнете, ясненько, спасибо👍
Спасибо за доклад. Очень долго заглядываюсь на FreeRTOS. Понимаю, что на вопрос тяжело ответить однозначно из-за весьма размытых границ и всё же. Есть ли у вас какие-то свои критерии по которым вы решаете стоит ставить FreeRTOS или не стоит ? Буду очень благодарен конкретным примерам . Заранее спасибо
Вот сидите вы такой и с философским (обязательное условие) взглядом обращенным на облака обдумываете свою программу. Так вот если она рисуется вами как единая задача, то применять FreeRTOS НЕ НАДО. А вот если у вас в голове вырисовываются несколько процессов или подзадач, то применять FreeRTOS НАДО.
@@VladimirMedintsev Спасибо за ответ )
У меня принцип такой: если оперативы в контроллере 8кб и более, значит надо. Если 4кб - может быть. Все равно со временем нагородишь самодельный ее аналог худшего качества.
Ага, вот и я думаю: а зачем в микроконтроллере нужна многозадачность?
)
@@Wo_Wang при разработках важно правильно понимать что ты хочешь сделать и правильно ставить задачу. Мне не нужна многозадачность, мне нужно изолирование друг от друга потоков кода, выполняющих разные задачи в устройстве, мне нужна возможность легко тасовать эти потоки, не нарушая работу всего остального, мне нужно чтобы программа оставалась линейной и простой так долго, как это возможно. ОС дает мне все это. Я уже сталкивался при разработках с ситуациями, когда городил жуткий код чтобы в итоге он сделал тоже самое, что доступно из коробки под freertos. Самый ценный ресурс - время. Мегагерцев и мегабайтов полно, времени, обычно - нет.
Нельзя в прерывания засовывать большие куски кода, а как на счёт работы usb?
Обрабатывать в задаче используя семафоры
Хорошее видео и объяснение доступное. А есть что-нибудь по работе с видео камерой?
Абсолютно непонятно что такое работа с видеокамерой.
19:00 Забавный диалог...
- При чём тут операционная система, когда нужны жёстко заданные тайминги?
- При чём тут жёстко заданные тайминги, когда нужна операционная система???
А ещё по прерыванию можно разбудить процесс,выполнить что то и усыпить )
Вообще более правильный вариант использования ос будет в комбинации всех доступных возможностей - ос+прерывания+дма
Для многих задач и особенно для мелких контроллеров зачастую не нужен RTOS,достаточно Protothread
Без условно, использование операционной системы это грамотный подход👍
Не понимаю тех, кто не хочет использовать FREERTOS, даже тогда, когда ситуация позволяет. Например, очередь - это очень крутая вещь. Можно в обработчике прерываний заталкивать туда данные и когда у задачи появится время, она их обработает, извлекая из очереди. Данные можно даже получить из неё не извлекая их из неё. Такое очень даже пригодится, когда на одни и те же данные нужно реагировать нескольким задачам. Еще круче получается с несколькими источниками данных для очереди. Например, одна задача окрашивает кнопки и помещает коды нажатых кнопок в очередь. Задача, отвечающая за работу с GUI получает их и обрабатывает. А теперь нам захотелось управлять GUI с помощью пакетов, приходящих с UART. Создаём задачу, которая принимает эти пакеты, извлекает из них команды и помещает их в эту же очередь. Так вот, сильно не напрягаясь и не затрагивая кода GUI, мы добавили еще один "пульт управления". И таких вот фишек там масса.
Я не хочу :) т.к. нашел куда круче RTOS2 RTX5 - родная ARM ось, ХАЛЯВНО включена в CMSIS2 !!! НЕ ОБРЕЗАННАЯ как все GNU "халявные" как
FreeRTOS или ChibiOS хочешь полную и надежную ПЛАТИ! Открытый код!. портирована в IAR и GCC, работает не только в платном Keil5
в CMSIS2 есть шаблоны под потоки, таймера итп, подключается быстрее чем фриртос из куба. И к ней есть EventRecorder классная GUI консоль для отладки в Keil5
(галочки не забудь расставить, а то будет пустой график)
Попробуй!
И я не хочу. Хватает TNeo.
На код freertos как ни посмотрю, напоминает древние версии php...
И я не хочу. Дорог каждый байт памяти и каждый такт не лишний.
Андрей Батищев, говорят кольцевой буфер с этим отлично справляется))
@@user-bc7tm8vw9g Говорят много чего, но более мерзкого (в плане реализации), чем кольцевой буфер, я больше ничего не видел.
Если квант времени у ОС 1мс, как быть в случае, когда имеется задача, которую нужо успевать обрабатывать за время от 1мс? Эта функция или реакция на внешнее воздействие, или она в принципе должна вызываться с периодом около 1мс.
дык таймеры и прерывания.
@@VladimirMedintsev Т.е. имеется ввиду совмещение двух подходов? Задачи не требовательные к времени отклика - крутим в RTOS а задачи которым нужно обеспечить быстродействие пишем по старинке? Я в своё время писал много вещей у котрых большинство функций не требовательно ко времени, т.е. их можно выполнять с периодом 100мс просто по очереди. Но есть обработка внутренней логики которую нужно успеть за 1mc. Ещё есть фильтры для которых важно тактирование с постоянным периодом. Есть внешние прерывания. Есть UART в который нужно ответить желательно за 1-2мс. Я написал свой диспетчер не требовательных к времени отклика задач, и да, согласен с Вами, написание таких вещей тянет за собою много времени. Но всё равно остаётся ещё много задач, для которых время отклика важно. И всё это крутится в mainloop и да, на pipelined 8051 8МГц loop time получается около 1мс. Меня не отпускает мысль, что при использовании RTOS я бы мог обрабатывать быстрые задачи ещё быстрее... Это возможно?
@@Siliverst Из прерывания можно переключать контекст на более приоритетный процесс.
Всем привет ! Уж посмотрел Я и почитал коменты , и вот вопрос ко всем знающим . Если есть 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. Самой простой под Вашу задачу будет достаточно.
Примерно к такой же структуре программы я и пришел лет 20 назад, с таймерами и флажками, после 2-х летних изысканий. Задача: упаковочный автомат с 2-3-4 весовыми головками(CAS). Контроллер: fastwel CPU188-5. Правда, RTOS-ов тогда ещё не было... ☹ Гы: зато, ещё был MS-DOS 6.22, на этой плате! 🙂
Спасибо
Контроллер это устройство состоящее из процессора, ОЗУ, Флеш памяти и прочее. Автор совершенно прав.
Так. Созрел глупый вопрос: А при переключении на другую задачу, значения переменных и состояние выполняемой сохраняется? Судя по тому, что Вы упомянули отдельный стек, вроде ответ должен быть да. Но можно для деревянных уточнить ))
Да, сохраняется.
@@VladimirMedintsev Спасибо, очень помогли понять в каком направлении копать. Столкнулся с такой необходимостью, когда не плохо бы, чтобы одновременно выполнялись несколько задач, параллельно так сказать. Понятно было, что решение где-то есть.. но где... ))
@@VAscetic Каждой задаче под FreeRTOS выделяется собственный стек, одна и таже функция может использоваться для нескольких одинаковых задач (например, для обработки портокола на нескольких последовательных портах одновременно*), и стек у каждой задачи всё равно свой. Статические переменные работают как обычно.
* Не совсем одновременно, конечно, а под управлением диспетчера задач.
@@DmitryKandiner Ага, спасибо, я в целом понял концепт. По сути, очень сильно такого плана решение мне требовалось пока 1 раз, и то более менее обошёлся. Когда с ETH учил контроллер работать, для поддержания одновременно нескольких активных соединений TCP по разным портам. А так, в большинстве случаев, достаточно стандартного набора прерываний, тем более если в контроллере есть DMA. Ну или я ещё в сложные задачи не залез :)
@@VAscetic как вариант -- построение веб сервера. Один процесс только принимает новые соединения, и запускает дочерние процессы на каждый запрос. А запросы, в свою очередь, обрабатываются каждый своим экземпляром одного и того же кода (важно не полагаться на статические переменные -- они общие для всех). По окончании обработки процесс закрывает соединение и самоубивается.
актуально. нужно на практике показать сколько сьедает ОС ресурсов. считаю по умолчанию ОС много сьест. для меня актуальным примером будет приложение электропривода на 4-5 задач на 1-10 кГц. а так конечно ОС будет удобно использовать. а у тена с бочкой воды постоянная времени 20 минут или 1 час. с теном можно и виндос использовать ;)
Скажите пожалуйста еще про другие ОС например riot-os
А я все искал, кто же меня просил про другие ОС видео сделать. :-) выполнено.
*_Что за программа или компилятор?, пожалуйста, напишите название таймкод _**_2:02_*
Это Keil uvision
@@VladimirMedintsev Большое спасибо)
Спасибо, очень полезную работу делаете, все чётко по полочкам. Не обращайте внимание на этих придурковатых умников, это все на что способен их мозг))
Владимир, здравствуйте! Спасибо за видео, пробую работать с ОС в своем проекте. Сразу возник вопрос о определении размера стека для задач. Возможно вопрос новичковый, но было бы круто выделить немного времени в видео о стеке, логике расчета, методах оценки ресурсов МК в отладчике (как с РТОС, так и без нее).
Так вроде же есть видео про стек FreeRTOS. Я там даже на примере показывал как это делать.
@@VladimirMedintsev точно! я как-то проглядел. Спасибо
@@VladimirMedintsev Всё пересмотрел по FreeRTOS из плейлиста. Получилось запустить, почитать расход стека, все очень удобно. Эти видео - какой-то праздник! Еще раз спасибо.
спасибо
Всё пытаюсь понять, как именно происходит переключение контекста подпрограмм. На ум приходит только подмена адреса возврата при выходе из обработчика прерывания (как это делалось некоторыми утилитами в DOS).
Т.е во время работы одной программы срабатывает прерывание, диспетчер (в обработчике прерывания) сохраняет контекст и адрес возврата текущей программы, восстанавливает контекст и адрес следующей и "возвращает" управление. При следующем прерывании вторая программа меняется на третью и т.д.
Хорошо, если памяти у контролёра хватит, чтобы хранить контексты всех программ.
Наверное причина в том, что вы пытаетесь мыслить категориями привычными для IBM PC совместимых компьютеров. Вы и написали - "программ". По факту же мы имеем дело с небольшими задачами выполняющими те или иные функции. Разумеется памяти им хватит. На канале достаточно роликов по этой операционной системе, даже есть фрагмент где показывается как вывести в консоль реальную загрузку и стека и кучи. Можете посмотреть, взять там несколько строк кода и даже попробовать.
Процессор - это часть микроконтроллера, какой тут может быть спор вообще?
никто же не спорит как правильно: компьютер или процессор, если процессор - это часть компьютера.
микроконтроллер, помимо процессора, включает в себя постоянную память, оперативную память и прочую периферию, если бы он её не включал - был бы просто процессором, а так микроконтроллер.
если речь про работу процессора - можно сказать и процессор и микроконтроллер, т.к. он этот самый процессор содержит.
а вообще если человек спорит о таком - это говорит о его полной ограниченности, ведь важно не выбранное слово, а суть за ним стоящая, можно хоть хуёвиной его называть - лишь бы было понятно о чём речь!
Ты знаки препинания нахера ставишь? Спорим, что и без них все понятно?!
@@Vlad_4572 вот нет, без них далеко не всегда понятно.
Казнить нельзя помиловать.
@@alextiga8166 , конечно, не всегда понятно, потому, и желательно следовать правилам и договорённостям, что бы не было неразберихи, а не называть всё вокруг хуёвинами. Его право называть микроконтроллер как он хочет, моё право, его поправить.
@@Vlad_4572 можно сказать "компьютер выполняет программу", а можно сказать то же самое про процессор. Можно сказать "автомобиль потребляет топливо", а можно сказать то же самое про двигатель.
Так в чём проблема с "микроконтроллер/процессор выполняет инструкцию"? И то и то правда, процессор - часть контроллера.
Никто не называет микроконтроллер процессором, но когда речь про часть микроконтроллера которая является arm процессором - и так и так правильно.
Или я в чём-то ошибаюсь?
@@alextiga8166 , его дело, как и что называть, но автор не очень хорошо отозвался о тех кто его поправляет и привел пример комментария, типа: вот, смотрите написано же, что это процессор! Так никто и не спорит, что ЭТО(cortex-m) процессор/ядро. Но он упоминая устройство, говорит - процессор. Ты разницу понимаешь? В мануале всё чётко написано, что есть что, не пойму, в чём прикол подменять понятия?
В где вы читаете лекции про freeRTOS, если не секрет?
Да нет не секрет. Я частным образом организую группы и с ними занимаюсь.
@@VladimirMedintsev Новому подписчику не хватает данных о локации в Вашем ответе ;)
Riot OS пробовали использовать?
Пробовали, для наших проектов она не подходит.
Здравствуйте Владимир! У меня такой вопрос: заказал один проект,его мне выполнили и я все оплатил.Все работало нормально,но прошло не много времени и программа в каком то месте перестала выполняться. Исходный код или hex файл при заливке никаких результатов не дал. Кстати сказать там тоже была операционка FREERTOS. Так вот собственно вопрос: мог ли программист сделать так,что бы программа спустя какое то время перестала частично работать? Если да,то можно ли устранить данный прикол? Тот программист перестал выходить на связь. Спасибо.
напишите мне по электронной почте vmedintsev@yandex.ru и обсудим
если это стм32, то могу предположить, что там есть функция-подлянка, которая перезаписывает память в области памяти программ
в этих контроллерах нет епром как в авр и часть общего флеша можно использовать как память для хранения каких-то данных
т.е. можно из своей же проги перезаписывать любые области памяти
и вот работает твой контроллер, функция перезаписывает байт и изнашивает ячейку
через какое-то время ячейка перестает читаться правильно и прога глючит
если это авр, то там может загрузчик есть и он при каждом старте тоже перезаписывает байт во флеше
либо таймбомба, когда в ячейку епром пишется число и при каждом старте оно увеличивается на 1
при достижении какого-то числа прога больше не выполняется и перепрошивка не поможет, только стереть нужную ячейку в епроме программатором
@@kalobyte Вот за это спасибо! Не знал, но возможно где то мысля такая побегала. Проц stm32f103c8t6. А как стирать ячейку не подскажите?
@@ilhitindustries7499
я не углублялся в такие дебри
просто знаю, что можно писать во флеш прямо из проги, а не только программатором или загрузчиком
вот я загуглил
www.devcoons.com/how-to-write-data-to-the-internal-flash-memory-of-an-stm32/
основная функция
HAL_FLASH_Program
А почему бесконечные циклы в задачах выполнены через for? В этом есть какой-то сакральный смысл?
Нет. Это дань моде. По сути одно и тоже, что и while
Контроллер обычно приемняется в адачах с жестко заданными таймингами и последовательностью переключения,а тут совершенно непонятно что и как работает
Если вам нужны "жестко заданные тайминги" то возьмите таймер и он вам очень точно измерит временные интервалы. Что касается последовательности переключения, то совсем не все задачи так примитивны как вы пытаетесь это представить. Есть весьма сложные алгоритмы. И в этих случаях применение операционной системы экономит много времени как на разработку так и на отладку. Более того, использование FreeRTOS весьма заметно повышает общую живучесть системы в целом.
В целом верно, но только примеры выбраны неудачно. Из-за этого объяснения выглядят не очень убедительно. Нельзя объяснять преимущества многопоточности на примере ввода с "клавиатуры" (а в видео это основной пример), поскольку она реализуется исключительно на прерываниях. Не считая конечно новичков, кому кажется проще опрашивать в цикле :)
Лучше бы объяснили на реальном примере. Вот у меня был проект на AtMega128. На дисплей 128x128 выводится информация из нескольких источников: от часов, от барометра, от термометра, от таймера, от "клавиатуры" и нескольких аварийных кнопок и даже от радио. Оказалось, что удобнее всего реализовать посредством эмуляции многопоточности, когда "менеджер задач" поочередно вызывает "потоки" (по одному на каждый источник), а те, выполнив какую-то часть работы, передают управление дальше. Причем, задачи получения данных от датчиков и вывод на экран обработанных данных были разделены. Единственно, что те же кнопки использовали прерывания, запуская "поток", выводящий на дисплей информацию и проигрывая определенный сигнал. Вот где преимущества многопоточности облегчают написание кода, его отладку и читабельность. Думаю и у Вас нашелся бы подходящий пример из жизни.
Порекомендуйте с чего начать в программировании на STM? В AVR есть понимания, а вот к STM не знаю как подойти. Боюсь пойти не по тому пути.
1.купите или изготовьте программатор st-link
2. купите или изготовьте платку с микроконтроллером выбранного вами семейства.
3. скачайте с сайта st.com последнюю версию STM32CubeIDE. Установите.
4. в примерах найдите мигалку лампочкой. мигните и убедитесь что все работает.
5. изучайте reference manual и все ОК.
@@VladimirMedintsev А есть что-то что сначало немного проще, типо как ардуино дает быстрый старт. (Только не ардуино под стм). Первые 2 пункта уже давно пылятся (купил на пробу, но так и не решился так как на тот момент информации было не так много как по авр), а 3 пункт вызывает вопрос с того ли стоит начинать или с другого.
Вы просили совет - я его дал. Следовать ему или нет, это ваше дело. Среда разработки (пункт 3) значения никакого не имеет, это просто инструмент. Что еще проще - платы nucleo. это как ардуино но stm.
@@VladimirMedintsev а вот эти все cmsys, freertos, hal я вот в этом запутолся.
@@ShaneAMC если нет хороших навыков программирования, то стм32 будет даваться долго и муторно... если конечно вы планируете делать сложные проекты в будущем.. для основ АВР хватает за глаза, а если взять софт flowcode, то и знаний программирования на первое время не понадобится..
С freertos вроде все удобней , но вот появилась задача управления шаговыми двигателями и обработкой энкодеров и тут столкнулся с затруднениями генерации импульсов для ШД и обработкой прерываний от энкодеров.
При рассказе последовательности загрузки МК, Вы еще пропустили что будет с начало вызвана функция, так сказать инициализации языка С, называется она в Вашем случае __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 при запуске.
Да, разумеется, это адский быдлокод и тот, кто так сделал - сам дурак. Но поверьте, ситуации бывают разные. Иногда приходится сознательно быдлокодить, когда на постройку башни из резной слоновой кости нет времени, задача копеечная и требуется чтобы результат сработал раз-другой и дальше станент не нужен. Да лучше за такое не браться, но иногда и отказать нельзя. Если Вы занимаетесь этим делом на потоке, наверняка сами прекрасно понимаете. А может новичок подобное слепит по неопытности и потом мозг сломает, пытаясь понять, что, блин, происходит :)
Вот для последних как раз помянуть про фазу инициализации статики - методически оправдано полностью имхо. А то ведь зачастую смотрят на компилятор, как на чёрный ящик: на входе исходник, на выходе - светодиод моргает, а что там между - черт его знает...
Необходимо указать важный момент. Если Вы пишете программу , НАПРИМЕР, передачи по радиоканалу потокового аудио, то FreeRTOS, не справится с подобными задачами и необходимо написать программу в классическом режиме последовательный код с прерывателями ит.п., подсчитывая в дебаггере каждый такт,, чтобы соблюсти точные временные слоты оцифровки и передачи пакета с накопленными сэмплами. . Поясню. Вы указали, что квант времени отводимый FreRTOS 1 ms. Я в программе каждые 125 мкс оцифровываю внутренним АЦП аналоговую речь, попутно накапливаю оцифрованные сэмплы во внутреннем буфере ОЗУ порядка 300 байт, при заполнении буфера я передаю его по SPI в CC1100 (радиопередатчик) . При употреблении FRERTOS у меня все поплывет, особенно в программе приемника , теорема Котельникова нарушится, пакеты с цифровыми сэмплами (речью) будут приходи не в нужные слоты времени, соответственно на ЦАП в каждые 125 мкс не будет поступать очередной сэмпл для декодирования. Так что,FRERTOS не поможет для решения данной задачи. для устройств, которые разрабатываете Вы, и для устройств которые не требуют точного до 1 мкс подсчета выполнения определенных частей программ и промежутков между ними, FREERTOS самое то.
Хотя я возможно не совсем прав.
Использование операционной системы никак не влияет на быстрые процессы если они вам необходимы. DMA, таймеры, прерывания, это все никто не отменял.
@@VladimirMedintsev Владимир, будьте добры посоветуйте какую-нибудь литературу по FREERTOS, желательно англоязычную.
freertos. org там все в виде pdf есть. прям много.
Было бы интересно увидеть видео разбора крупной программы, как в ней использовался FREERTOS и какие опасные моменты нужно учитывать. Вроде штука интересная, но как и где ее стоит применять все равно не очень понятно. В маленьких программах ради удобства - притянуто, маленькую программу как ни пиши - проблем нет никаких. В больших - можно кучу не отлавливаемых интересностей словить - стремно использовать. Вообще контент на канале достойный. +++
вот как раз операционная систем и нужна для отлова интересностей. Операционная система имеет средства контроля за работой процессов и имеет средства управления памятью. При использовании ОС есть недостатки - это потеря в скорости реакции и использование большего объема памяти. За это програмист получает возможность управления потоками, профилирование, отладку запущеной системы.
Вы с RIOT работали? Что думаете?
Мне не подходит.
FreeRtos ОСРВ? В новой упаковке? Простите, с 90-х этим не занимался. Опять пришлось. Очень полезный канал.
RTOS и переводится как ОСРВ
Насчёт тайминга действительно это просто недопонимание. На то она и “real time” ОСь, что её цель именно выдерживать детерминированный тайминг задач. Нужно только указывать им приоритеты и будет тайминг что надо. На ютубе есть видео с презентацией FreeRTOS от автора - там он отлично это поясняет.
Конечно, могут быть какие-то другие причины не использовать RTOS. В каких-то супер-критических и супер-embedded задачах может будет необходим 1 контроллер на 1 задачу (или 1 PLC на задачу, если это совсем что-то суровое). И, конечно, если ваш код не сложен и не предвидится его развитие, то действительно нет смысла заранее заморачиваться с ОСью. Но тайминг это как раз не проблема для RTOS, это её работа 🙂
Контроллеры разные бывают. Для ATmega 8 или 328 такая ОС мне кажется перебор, а вот для ESP32 необходимо использовать ОС.
На ESP32 хотел изначально использовать или библиотеки Arduino, или напрямую язык Си, но как выяснилось что компания Espressif в своих библиотеках всегда использует FreeRTOS. Так зачем мне изобретать то что уже и так эффективно работает. Тем более что для 2-х ядерного процессора лучше использовать ОС, которая упрощает работу с железом.
есть еще nanoFramework от Майкрософт, он тоже поверх какой-то ОС работает, но программировать можно на C#. Для дотнетчиков это просто песня)
@@mvxburov Мне почему-то не удалось его завести на Visual Studio 2019 и опробовать. А так бы сказал что он компилирует, ассемблерные выходные листинги я отлично понимаю.
Согласен. Я на асме пописываю для АВР ок, как попробовал кооперативную РТОС (от di Halt,) так в "суперцикл" и не тянет. В разы проще и в написании и в отладке
Не понимаю откуда такие вопросы в комментариях про прерывания и быстродействие. Ну если вам нужно последовательно что-то считать используйте ДМА. Да и с чего вы взяли что ОС это замена прерываниям. Это как что лучше мясо или мел?
1.Объясните логику приоритетов как за один квантОС обрабатывается несколько задач, и что происходит с прерванной задачей... не вложившейся в квант.... и после неё!
2. Почину for ? a не while... какаето ассемблер оптимизация? По моему совсем на оборот!
3.А ещё по прерыванию можно разбудить процесс,выполнить что то и усыпить )
Есть на канале видео, где про задачи и логику их переключения все подробно рассказано.
Что касается while или for то с точки зрения ассемблера разницы нет, for ведь без параметров и на нем прекрасно отыгрывает оптимизация. Ну и если понаблюдаете за библиотеками nxp или ti то обнаружение массу такого рода примеров.
Спасибо. И с Днём ВАРЕНЬЯ!
Классная ос.
14:50 - лучший способ исправления опечаток! 😁👍 Спасибо за отличный урок!
Я сейчас пишу программу, так уж вышло, для 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
Здравствуйте! Мне очень интересны автоматы, я сам на них пишу, но пока очень не опытен в этом деле. Можете ли вы поделиться кодом проекта, чисто в образовательных целях?
Чуваки, не подскажите как с расходомера с датчиком холла нормально сигнал обработать?
Вот мой вопрос в коммунити ST:
community.st.com/s/question/0D53W000000adkCSAQ/how-to-get-signal-from-hall-flow-sensor-hlfm3012-stm32f103c8t6-board
@@kokotmkokot4926 по тарелочкам + охота.
Попробуйте убрать конденсатор С1.
конечно интересно, но вот на столе лежит две конкретные задачи - зарядка 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 - для правильно организованного проекта.
Нужно еще одно видео - ибо вообще непонятно как скрестить FreeRTOS с задачей требующей высокого быстродействия. Вот вводные: оптический датчик с 1800 линий на оборот стоит на шпинделе станка, который имеет максимальную скорость 2000 оборотов в минуту - нужно получить данные о положении шпинделя и в зависимости от этого вращать шаговый мотор - логику вы эту в прерывание не засунете - ибо там расчетов много и из этого вы "отодвинете" время срабатывания других прерываний. Засунуть логику обработки в задачу, которая выполняется не чаще 1мСек и имеет время старта "как FreeRTOS решит " - это вообще не вариант. Вот как вы можете решить данную задачу с FreeRTOS ?
А если честно - я вообще не понимаю - почему FreeRTOS - это система РЕАЛЬНОГО времени ибо операционка MS-DOS вот это система РЕАЛЬНОГО времени, а та же Windows это уже операционка НЕРЕАЛЬНОГО времени и там тоже тайминги в 1мСек и время старта задачи там тоже "как операционка решит".
Если считать программно каждый тик энкодера - то да, непосильная задача для любого- даже самого быстрого процессора.
Но вместо подсчётов тиков энкодера - достаточно опрашивать его аппаратную часть на таймере, через фиксированное количество времени. В этом случае считается не его текущее положение - а изменение за фиксированное время, со сдвигом к нулю. В этом случае доступен весь диапазон таймера работающего на энкодер, и отпадает необходимость как-либо управлять его переполнением.
Ведущий мотор может вращаться с низкой скоростью, для того чтобы ловить это состояние - используется дробные числа. Старшая часть повторяет значение аппаратного энкодера, а младшая - дробные числа.
Для ведомого шагового двигателя считается положение в которое он должен встать через фиксированное время того-же таймера, что запускает считывание таймера энкодера. Тут тоже дробные числа, и тоже с переходом через ноль. Перемножаем дробное от энкодера - и получаем любое разумное соотношение скоростей вращения. И да, это угловая скорость.
Дык вот, считывание и управление происходит в прерывании, или через дма. А обработку можно делать в основном цикле. Потому как на фиксированную задержку в 5-30мс - механика станка (инерция) просто не в состоянии отреагировать.
Общая задача достаточно простая, и может целиком выполняться в прерывании (буквально несколько строк).
Ос может понадобится для работы с экраном и кнопками. Потому как реакция человека заметно ниже требований к железу, тут +- лапоть к задержкам - вообще никто не заметит.
@@avi-crakhome2524 - я завис на вашей фразе и дальше уже не читал: "Но вместо подсчётов тиков энкодера - достаточно опрашивать его аппаратную часть на таймере, через фиксированное количество времени". Аппаратная часть промышленного оптического энкодера есть фотодиод и как вы его можете опрашивать периодически чтобы узнать положение шпинделя станка - я даже не представляю.
@@user-rx4rp5yb5j Аппаратный таймер чипа stm32xxx - режим энкодера. Вход две линии от промышленного энкодера, выхлоп - значение счётчика таймера. Вот именно это значение и нужно считывать через фиксированные промежутки времени.
@@avi-crakhome2524 спасибо - посмотрю данный вариант - но "фиксированные промежутки времени" через freeRTOS в 1мСек???
@@user-rx4rp5yb5j Не через, а совместно. В ос есть таймер, который фиксировано срабатывает каждую 1мс. Если в его прерывание добавить немного кода - система не рухнет.
А вот изменение коэффициентов множителей для ускорения/торможения и начальную синхронизацию - можно делать через freeRTOS. Этот код жирнее, и не требует моментальной реакции.
я бы опредил пременимость RTOS так, если декомпозиция задачи укладывается менее чем в десять потоков, то применее RTOS скорее нежелательно и является "Overengineering", в таком случае лучше использовать конечный автомат, а чтобы код непревращался в"лапшу" просто аккуратно офрмлять код, больше использовать шаблонное програмирование, макросы
Был у меня один проект, где было пять почти не связанных друг с другом потоков. Написан был на автоматах, но весь код был тихим ужасом. Там свитчи были на 25-40 кейсов. Один поток работал с кнопками и GUI, второй через один UART работал с одной группой устройств по RS-485, третий через второй UART работал с другой группой устройств по шине K-Line, четвёртый работал с такими же контроллерами по шине CAN и пятый поток, получая все данные с остальных потоков, отрабатывал логику работы устройства. На FreeRTOS это было бы гораздо проще, эффективнее и быстрее.
Однако, это был камень AT90CAN128 и порты FreeRTOS под него на тот момент были кривоватыми, а девайс нужен был "еще вчера".
@@kardanium был у меня один проект, на один поток, код был ужасен, на FreeRTOS он бы стал сложнее, тяжелее и тормознее.
@@acrsofter Ясно, что бывают задачи, где ОС не нужна. Я в таких случаях пишу функции опроса таким образом, что только когда данные будут готовы, функция их вернёт. А иначе возвращает ноль или иной признак неготовности. А задержки используются только неблокирующие, с использованием системного таймера. Часто даже автоматы писать не приходится.
@@kardanium да, иногда кооперативной многозадачности вполне достаточно
@@acrsofter это говорит скорее о скиллах разработчика.
! о!; 14минута(прошло час) скелетное программирование, кооперативная многозадачность >>> OS...ОЧЕНЬ ДОХОДЧИВО!
Пожалуй, содержимое ролика никак не коррелирует с его темой (в заголовке). После прослушивания возникает четкий ответ на вопрос "Почему использование операционной системы оправдано даже в небольших проектах" - да ни почему. Просто так автору кажется. В небольших проектах может быть как раз лучше применить простой дешевый чип с малым объемом памяти, куда FreeRTOS никак не впишется.
Оправдано тем, что код получается чище и понятней - каждая мини-задача в отдельной функции и без лишнего мусора. Такой код проще и быстрее писать, отлаживать и поддерживать. А время сейчас стоит дороже чипов.
так для автора может быть небольшой проект это не помигать светодиодами, а какая-то замороченная херня
вот он и говорит, что с виду вроде бы все просто, но есть куча состояний и все они как бы сами по себе должны работать
и такое лучше оформить при помощи ртос, а не автоматом
больше сожрет памяти, зато меньше писанины
если ты бабло получаеш за проект, а не по часам, то в твоих же интересах написать это все как можно быстрее и чтобы через год ты мог понять, что ты там написал и встроить новую плюшку
а то бывает так, что новая плюшка потянет переписывание всего кода
microsin net, на совремнные чипы почти на любой фриртос влазит..
Anatoliy Gavrilov, у автора видео лишь иллюзия этого. Он декларирует эти цели, представленный псевдокод их не реализует.
@@user-bc7tm8vw9g Тут ключевое слово "почти". Таки да, именно так. Поэтому нельзя утверждать, что "даже в небольших проектах использование FreeRTOS оправдано". Не все чипы "современные", и ни на все "современные" чипы "влазит" RTOS. Всякий инструмент хорош на своем месте.
Все яйца обычно в одну корзину не кладут, тот кто говорит надо аппаратную часть жестко вести жестко привязанную ко времени и freertos это неправильный выбор для техпроцессов - используйте свою периферию: ПЛИС, DSP и тд, а stm очень хорошо на FREErtos может дирижировать вашим оркестром при этом отображая данные на дисплей и отправляя/принимая уставки куда нибудь сразу по нескольким каналам ю, при этом можно что-то не критичное ко времени привязать на саму стм что-то вроде температуры, заряда акб и тд, осциллограф из него не сделаешь, дельта-сигма фильтр из него лепить? Один контроллер на функцию? Да это просто кошмар такое предлагать, тогда на устройство надо 5 контроллеров или очень толстый стм. Автор учит как использовать стм, а вот как его использовать с умом тут каждый должен вырасти сам.
А разве приоритет прерываний не должен быть меньше приоритета обработчика задач? А вообще прикольно , давайте больше видео про ос!
честно говоря не помню. что-то было на эту тему у них в документации. потом посмотрю.
приоритет прерывания может быть выше чем приоритет обработчика задач, но такое прерывание не может вызывать функции freertos напрямую
Ну так ОС позволяет выполнять несколько потоков, в этом суть видео?
Чтобы выполнять потоки нужны ядра, в нашем случае ядро одно. Задачи. ОС позволяет облегчить программирование и ускорить цикл разработки.
@@VladimirMedintsev просто в этом месте терминология Embedded мира и мира "больших компов" расходится :(
По идее, потоки исполнения - это как раз та единица обработки, с которой работает операционная система. Будут ли они выполняться параллельно на нескольких ядрах или с мультиплексированием - это забота железа и планировщика ОС, поэтому то, что FreeRTOS называет "задачами", по сути, является именно потоками (впрочем, технически это и вовсе корутины/сопрограммы).
А задачей в общем случае обычно называют некое не всегда быстрое, но конечное действие, не влияющее на глобальное состояние программы например - "прочитать файл с URL, вернуть массив байт", "вычислить БПФ, записать в указанный массив", "записать файл на диск", и эта абстракция более высокоуровневая, чем поток, иногда со взаимными зависимостями "после завершения запустить ещё это и это". Как именно разложить задачи на потоки - дело библиотеки.
@@allcreater_ к чему эти объяснения я не понял. Есть документация на FreeRTOS в ней английским по белому написано слово TASK. Это слово переводится как задача. Все, дальше не надо что-то фантазировать.
@@VladimirMedintsev это к тому, что слово "Task" во FreeRTOS - синоним более однозначного термина thread, что переводится как "поток"...
@@allcreater_ Я видимо упустил, не подскажете где написано что thread и task это синонимы?
Так и не "пересели" на CubeIDE?
Я говорил что учебные штуки останутся на Keil. Он более распространен. В кубиде только коммерческие за денежку.
@@VladimirMedintsev она вроде бесплатная
@@Asmcavr Кэп? Вы ли это? Я в кубеиде делаю коммерческие проекты, за которые деньги получаю именно потому что она бесплатная чтобы не нарушать лицензионное соглашение и законы.
@@VladimirMedintsev Сорян, я неправильно вас понял).
@@VladimirMedintsev Так теперь считай все и делают, точнее пишут в комфорте, в Keil / IAR, а на продажу пересобирают из под CubeIDE ;)
Еще бы отладку с программатором в этом CubeIDE допилили, а то здорово подбешивает шиться вне среды
Все эти ртосы очень напоминают ардуину. Расточительно, но может пригодиться при унификации подключаемых к проекту модулей: вставили INIT и все остальное модуль запустит. Именно так пишут свои примеры разработчики микроконтроллеров, например, STM.
Основной недостаток - все это очень медленно. За время переключения с одной задачи на другую, в моих проектах успевают выполниться все мои задачи. При переключении диспечер сначала обрабатыыает все очереди событий, выбирает задачу, потом собирает чемоданы от текущей задачи и распаковывает для следующей. Я пишу сложные многопроцессорные приложения с обработкой звука в реальном времени, комуникацией, графикой, вложенными прерываниями, распределением приоритета и т.д. Мой опыт работы 27 лет. Применение ртос не оправдалось нигде. Все решается проще.
Необходим доскональный разбор этой системы, желательно с "подводными камнями"... Понимаю, что учиться на собственных ошибках хорошо, но таким образом уходит слишком много времени.
На этом канале уже есть несколько роликов по FreeRTOS.
@@VladimirMedintsev ага... Значит будем рыть😊😊😊!!!
Пример для описания многопоточности не самый логичный. Многопоточность имеет смысл, если управляется несколько устройств с одного МК. К примеру (если рассуждать про тен как в примере) - если мы хотим его переключать один раз за 100 тактов системного таймера, нет никакого резона чаще опрашивать датчики температуры. Проводить расчеты/вычисления чаще, чем поступают новые данные тоже не логично. Т.е. в примере с теном все действия должны выполняться на одной частоте. И если позволяют ресурсы МК, то почему бы не делать это максимально часто, т.е. просто оставив код в бесконечном цикле. Единственное что логично вынести в отдельный поток это вывод на дисплей, его нет смысла обновлять чаще чем 50-200 мс.
Так многопоточности или все-таки многозадачности?
@@VladimirMedintsev а как не назови сути не меняет) так же как процессор или микроконтроллер. если устройством нужно управлять 1 раз за 100 тактов, то не имеет смысла опрашивать датчики и проводить вычисления чаще или реже этого
Не, я просто уточнил.
@@ufers1027 еще как имеет! Например, если реализовано управление PID, то тенденции изменений можно отслеживать с бОльшим разрешением, чем выдавать команды на управление.
@@DmitryKandiner Данные на выходе PID будут одни и те же т.к. не изменяется показания датчиков (обратных связей) и входного воздействия. Я работаю в данной области больше 15 лет)
Потому что микроконтроллер СТМ32 имеет в составе процессор Кортекс М4. А кроме него ещё память и много чего.
смотря какая серия
ести и с ARM Cortex М0, М0+ и с М7, М3...
Все идет к усложнению архитектуры проца.. Уверен появится аппаратный менеджер задач, который например будет включать задачи по таймерам и отводить им сколько нибудь тактов... Потом выяснится, что два таких проца еще лучше чем один, потом защитят память кольцами защиты от вирусов, писАть под stm32(64/128/../2048) без ОС станет невозможно, выдут книги по программированию для ОС ртос.... Уверен мы наблюдаем ускоренную эволюцию от процессоров 8080..i486,...233mmx,....core i3.... и параллельно ms-dos...windows 3.11,...NT...XP....
На самых крупных микроконтроллерах STM32 уже запускается Linux. А в простых это не нужно.
Не претендую на истину, а лишь выскажу свое личное мнение.
Мне кажется что писать с использованием RTOS можно только при соблюдении некоторых факторов :
1. Вы умеете писать работоспособный код и без нее и поэтому хорошо понимаете плюсы и минусы данного подхода.
2. можно писать с ней если приоритеты прерываний кажутся чем-то маловажным для вас и вы никогда не гуглили ответы на свои вопросы фразами типа "interrupt latency" и не считали такты(да да , в некоторых задачах на 100-180Мгц тоже приходится это делать и не по приколу, а по необходимости).
3. проект чисто домашний и можно смело брать самый "жирный МК" и не думать о его стоимости.
Если новички читают это, то просто поймите - RTOS это просто один из подходов к программированию - иногда оправдан, иногда нет, все зависит от ваших задач.
Ну а сам ролик нормальный.
Да вы озверели чтоли, новичкам много поточное приложение писать... Со всеми гонками переменных и прочими прелестями асинхронности.
Это 90% программистов вообще не умеют. Ибо в 90% случаев не нужно.
@@VitaliyRu ну по моему мнению - в 90-95%(а вообще и больше) использование ОС на МК тоже особо и не нужно. ОС нужно в других устройства, где чуть выше уровень и другие вычислительные возможности. обычно примерно так: система где есть 1) устройство на линуксе + 2) устройство на МК. линукс с ОС для вычислений, МК для связи с датчиками и ИМ.
как то так.
Новичкам (и не только )лучше RM читать , книжки по Си и Хоровица + практика практика практика. Я уже не совсем новичок, но все равно повторяю по кругу эти действия :) А кто хочет просто побаловаться "миганием лампочкой" и сделать это без особых затрат(умственных и временных) и забыть как пропадет интерес - ардуино будет идеально вариант и все эти ОС нафиг не нужны.
@@tx-rx По мне так тоже. Либо линух, винда и тому подобное. Либо по стараинке в петле с прерываниями(там своей боли хватит :) Их к слово по возможности лучше тоже избегать.
В видео описана задача которая прекрасно выполняется последовательно(это не только МК касается, но и той же винды), а ее предлагают сделать асинхронной.
Выше я там уже Рихтера цитировал
"В общем, мораль этого вступления такова: многопоточность следует использовать разумно. Не создавайте несколько потоков только потому, что это возможно. Многие полезные и мощные программы по-прежнему строятся на основе одного первично го потока, принадлежащего процессу "
@@VitaliyRu полностью согласен.
@@tx-rx за Хоровица отдельный привет и спасибо, дядька знатный и дай бог ему долгих лет жизни. Я после окончания университета его до сих пор перечитываю и каждый раз нахожу новое!
Правильно тыкают. В коде написано о сбросе процессора по тому, что речь о процессоре, а не о всём контроллере
По вашей логике системник тоже надо процессором называть?
У вас тут проблема с логикой. Программируете вы процессор, программу выполняет процессор, а вот в плату вы впаиваете микроконтроллер. Просто это судя по всему ваш второй коммент на этом канале и я сильно сомневаюсь что вы в курсе предистории этого обсуждения.
@@VladimirMedintsev я написал свой комментарий исходя из того, что вы сказали в видео
Да, я не в курсе предыстории.
А знаете ли Вы, почему появляется потребность вот в таких видео? А потому, что на дисциплине "информатика" операционная система - это системное ПО, задачей которого является управление файлами. Я не шучу. Именно в такой формулировке. А что такое ядро, системные сервисы и даже, банально, механизм прерываний - этого знать не нужно. И ладно ещё общеобразовательный предмет. В ВУЗе дают такие определения!
Кому интересно, Тёненбаум, "Современные ОС". Всё понятно и доступно.
Видимо это явление консерватизма. Первые ОС действительно создавались вместе с файловыми системами и предназначались для работы с файлами. MS-DOS тоже зовётся операционной системой, однако многозадачности там нет.
@@kardanium не соглашусь и оспорю. Первые ОС - как раз таки пакетные загрузчики вычислительных задач. Тогда ещё понятия "файловая система" не было. Была перфолента, стопка перфокарт или (в лучшем случае) пара десятков метров магнитной ленты. Задача - последовательный запуск заданий и вывод результатов куда-нибудь (чаще, на печать).
@@mnanorn Ну так, тогда тоже небыло многозадачности, ядра, диспетчера и прочих подобных вещей. Был просто код, который читал перфоленту, заносил ее в ОЗУ и отдавал загруженной программе управление. Позже ленты заменили на диски и следовательно, на файлы. Многозадачность появилась позже, когда вычислительные ресурсы и развитие компьютеров стали это позволять.
@@kardanium Вы считаете прерывания многозадачностью? Уточню вопрос: Вы считаете возможным организовать действительную многозадачность на одном вычислительном ядре?
@@kardanium и, да, изначальная тема комментария была "подмена действительной роли операционной системы в образовательном процессе". )
Тут прям холивар развели! Надо-не надо...Не нравится frtos - пиши свой диспетчер... В любом раскладе задачи быстрее 0,5-1мс придется выполнять, изгаляясь, где-нибудь в прерывании или еще как придумывать... А все диспетчеры и оси нужны для обработки МЕДЛЕННОЙ БИЗНЕС-ЛОГИКИ!!! Когда у тебя дохрена кнопок, дофига светодиодов, датчики, цапы, ацп, и все работает независимо - иди собери все это в кучу! Вот тут и выруливают помогаторы!