Операционная система FreeRTOS. Самый полный курс на русском языке. Часть 1. Необходимость ОС.
ฝัง
- เผยแพร่เมื่อ 1 ม.ค. 2023
- Полный курс по операционной системе FreeRTOS. Часть 1.
Тема: Необходимость в использовании операционной системы. Какие вопросы решает.
По вопросам сотрудничества - vmedintsev@yandex.ru
Канал в телеграмм - t.me/vladimir_medintsev
Канал на TH-cam - / vladimirmedintsev
------------------------------------------
Если вы хотите поддержать автора канала номер карты Сбер:
2202-2023-2480-4008
------------------------------------------ - วิทยาศาสตร์และเทคโนโลยี
Владимир Валентинович! Наконец то в русскоязычном интернете появляются по настоящему качественные мануалы для самообразования! Очень доходчиво и главное не нудно и по настоящему интересно! Низкий Вам поклон и огромная благодарность за то что, вы делитесь своим огромным богатейшим опытом!
Спасибо, жду с нетерпением продолжение курса!
Спасибо! Буду ждать продолжение курса. Очень интересно.
Спасибо за лекцию!
Спасибо! Жду, с нетерпением, продолжения.
Владимир Валентинович, мы Вам Очень Благодарны!
Владимир, благодарю вас за ваши старания и труды!) и в частности за годный видео контент!) надеюсь по мимо диспетчера задачь, будет ещё рассказано про использования событий🙏
Это будет самый полный курс из существующих. Ну точнее он уже есть.
@@VladimirMedintsev буду однозначно ждать ваши видео труды. Я человек, не сильно далёкий от микроконтроллеров Инженер АСУ ТП и благодаря вашим трудам и своиму интересу проникся микроконтроллерами, процессорами. Был случай, когда аутсорсиру программисту мк подсказал про существования FreeRTOS, а до этого он исполнял ТЗ, в линейном стиле программирования. В любой ситуации ещё раз благодарю за ваши труды🙏🙏🙏
Давно хотел разобраться с FreeRTOS.
Спасибо.
Начало вполне понятное.
Спасибо, Владимир! Смотрю курс с удовольствием.
Отличная идея занятия по FreeRTOS жду продолжение.
Это как глоток воздуха для чистого разума в эти дни!
Очень интересно. Спасибо за такое подробное объяснение.
Отдельно большое уважение за представленные в начале проекты, в которых вам посчастливилось поработать. Действительно, очень достойно.
Успехов вашему каналу!
Благодарю за видео. Буквально пару месяцев назад начал изучать freertos на stm32. До этого строил программы на основе таймеров, программных счетчиков и костылей. На них все работает, но хочется чего то более серьезного. И тут как раз вы выпускаете курс. Большое спасибо. Хочу показать, что ваши старания и труды бесценны для подписчиков
Спасибо.
Хоть с этой ОС я работаю не первый год, все равно интересно. Спасибо.
От души, жду книгу
Очень лаконично и понятно. Супер!
Балшое спасибо из Балгария за етот и будушие ролики! Тема очень актуальная и нужная в програмирование микроконтролеров.
Спасибо! Очень доходчиво
Удобная штука. Перенос с одного контроллера на другой достаточно сложного проекта заняло не больше получаса.
Благодарю, ждем продолжение
Спасибо вам большое
Рад снова вас слышать ! Ждём продолжение
Очень нужный курс.!
Главное в обучении это работа с документацией. Если не будет проработка с исходной документации, то так люди и будут ждать и не научатся работать самостоятельно. Ведь все нельзя объять в данном формата.
Тут сто раз согласен!
Ну здесь как я понимаю введение в курс дела, дать понимание что это и как работает, мне вот гораздо интереснее и легче слушать переработанную информацию, подтвержденную опытом от человека чем лопатить документацию не подготовленную для новичка
Нет, главное это практика, подкрепляемая документацией! А ещё с опытом уже знающего человека, так как он укажет на нюансы. А штудировать в начале документацию, а потом практику, это самый худший путь.
Много кто указывает на недостатки, :
но идеального сценария не бывает!
Идеального кода тоже!
Идеально тайм менеджмент туДАже!
Спасибо за науку!
Комментарий в поддержку, повышение активности, очень хочется увидеть полный курс!
С интересом смотрел. Спасибо
Спасибо, начал изучать stm8, собираю информацию, попал к Вам чуть в будущее, посмотрю всё)
Отличное начало! Смотрел с удовольствием, не смотря на то, что уже пишу программы на FreeRTOS после обучения в GB на курсах Владимира!
Ой, спасибо вам огромное. Очень рад.
Спасибо большое за просветление нас, обычных, линейных крестьян!)👍🏼
Ключевое словосочетание. Только ты забыл добавить слово "средневековых". Автор канала и вы оттуда, там и останетесь.
Ой, а вы у нас откуда такой просветленный? Меня забавляют такие заносчивые личности.
Спасибо за урок
Спасибо
Спасибо!
Ура ура началось !
очень интересное и полезное видео
У меня на работе FreeRTOS вовсю применяется, мне тоже пришлось разбираться с оной ОС и писать под неё, хотя я больше железячник, нежели программист. Однако штука эта требует разбирательств, да и со временем что-то забывается, так что я крайне благодарен Владимиру Мединцеву за курс. Думаю его сохранить и периодически самообразовываться.
Спасибо. Очень рад что таким, как вы могу быть полезным.
Я тоже !
#TOP!
Меня останавливало использование FreeRTOS то, что это требует дополнительной памяти и как следствие применение более дорогих микроконтроллеров. Сейчас все более доступными становятся ESP32 у которых достаточно памяти и фреймворк Ардуино уже работает поверх FreeRTOS. Поэтому с нетерпением буду ждать следующий урок и осваивать FreeRTOS.
Переменная count внутри if в нижнем регистре, а в вне if вы ее инкрементируете, но она уже в вернем регистре. Надо исправить. В "С" переменные регистрозависимые.
Вот это звук в начале)))
Можно покритиковать? Конечно для новичков очень сумбурное объяснение. Любая ОС прежде всего предназначена для распределения ресурсов устройства между задачами/потоками. Те 8 преимуществ - это не преимущество ОС и их она не обеспечивает. Это больше относится к проектированию приложения. Даже без ОС нужно проектировать приложение так, чтобы они удовлетворялись :) А если не удовлетворяются, то что-то вы делаете не так. Задача любой ОС - разделить процессоре время между процессами в соответствии с их приоритетами, а также предоставить механизмы для совместного использования одних и тех же ресурсов разными процессами (семафоры, мютексы).
Офигеть! Просто офигеть! Не знал о вашем опыте работы, думал вы всю жизнь просто разрабатывали коммерческую электронику! А тут такой головокружительный опыт! Спасибо вам за работу! Спасибо за уроки! Именно ваш канал подтолкнул меня пересесть с 8 ми бит Atmega328P на здравый STM32F103. Большой привет вам от техника-программиста из ЦНИИ РТК! Прихожу с работы, сразу сажусь за изучение ❤
И вам спасибо за позитивную оценку моего скромного творчества. И конечно же приятно, что у меня есть подписчики из таких интересных компаний.
С терминологией полностью согласен.
У нас все таки xTaskCreate, а не xThreadCreate
Самое логичное - не функция задержки, а таймер в прерывании и функция усыпления. Ядро храпит без задних ног пока не произойдет некое событие которое приведет к проходу по циклу. Как частный случай события - прерывание по таймеру. Собственно именно так я работал когда начинал на Асм-е и в начале при переходе на Си до создания кооперативного диспетчера задач и выноса всех функций и таймеров в отдельный .h-файл.
Вопрос о распределении времени - тот еще вопрос. Это вопрос о допустимости произвольной остановки любой задачи в процессе ее исполнения. Ну и вопрос цены ресурсов которые на это тратятся как по памяти так и по времени. Вопрос с далеко не однозначным ответом.
Детали взаимодействия между модулями никуда не деваются, что и логично т.к. модули почти никогда не работают сами по себе. Они просто от простых механизмов переходят на семафоры, мьютексы, сокеты, сигналы. Причина усложнения взаимодействия по сути это та самая остановка в произвольный момент времени и связанная с этим волатильность переменных и состояния.
Имхо, freertos полезна для тех, кто не набил себе руку в создании собственного планировщика. А так, сам повсеместно использую прерывания системного таймера в stm32 для распределения времени
@@easystm6865 Ну, там сам планировщик банальный - на 30 строк кода с учетом всех скобок плюс десяток банальных функций на одну-три строки. Плюс несколько массивов в оперативке и флеше для состояния задачи/таймера и адреса самой задачи и ее типа/условия запуска. Сложность только в красивой и удобной реализации о которой задумываешься в том числе после опыта использования RTOS в некоторых из которых сделано через то самое место.
Примерно месяц назад начал изучать микроконтроллеры и СИ, и мозг просто закипает, очень сложно и непонятно.
А вы, в своих видео, вот так без напряга рассказываете о нереально сложных штуках. Вы гений.
Начал использовать freertos и мне стало проще делить программу на модули, эти модули я очень быстро могу перенести в другой проект без головной боли. Правда я ещё нахожусь на стадии изучения и программы не всегда эффективные получаются.
Здравствуйте! Благодарю за труды. Очень хотелось бы увидеть примеры работы обработки коротких прерывания на FreeRTOS.
Это есть в данном курсе.
Запустил я тут курс на планшете подключенном к аудио системе в 3 кВт и в первые 10 секунд у соседей посыпалась штукатурка. Звук 🚀
Спасибо за курс! Будете ли преподавать его на GB?
о как вовремя. если еще и е ESP32 смогу применить вообще красота будет =)
Сможете
@@VladimirMedintsev замечательно. значит на чаёк не зря поделился xD
За это огромнейшее вам спасибо. Это всегда приятно.
Спасибо большое, Владимир! Скажите, планируется ли какое то расписание выхода лекций курса? Или примерный интервал новых роликов по данной теме?)
Курс сделан полностью. Интервал между видео будет определяться активностью аудитории, если активность будет высокой - ролики будут выходить часто, если активность снизится из-за усталости от темы, то интервал будет увеличен.
Ого какой стаж... Уважание...
Я ОСРВ оставляю только для крупных проектов. Очень крупных. А для таких небольших у меня используются конечные автоматы. Главный цикл крутится быстро, а все, что требуется выполнять нечасто, управляется системными таймерами. Я такие проекты вообще всегда начинаю с системного таймера. Проект разбивается на подсистемы, подсистемы берут данные откуда им надо, а обработанные результаты хранят у себя. Кому надо, тот их и возьмёт. Алгоритмы разбиваются на шаги, шагам присваиваются номера состояний автоматов. Каждая подсистема имеет свой автомат. Конечно, в таком подходе сложновато планировать приоритеты подсистем, но в несложных проектах я никогда с таким не сталкивался даже на AVR-ках.
Спасибо, буду смотреть с удовольствием! Вопрос от нуба. Можно запустить FreeRTOS на одноплатном компьютере с процессором RISC-V или запустить в докере в Linux?
Встречный вопрос: ЗАЧЕМ?????????
В докере в принципе нельзя операционку запустить, по определению. Если конкретный RISC-V МК поддерживается FreeRTOS , почему нет (например на RISC-V ESP32-C3 FreeRTOS работает, как и на всех МК от espressif). Меня немного смущает ваше определение "запустить FreeRTOS", я надеюсь вам понятно, что FreeRTOS нельзя запустить как программу под Linux. Если очень упрощённо - это голый диспетчер задач + АПИ для работы с многозадачностью. RTOS нужно конфигурить, набивать тот же диспетчер тасками ит.д. ит.п., в конце скомпилировать под свой конкретный МК прошивку. Ну или всзять готовыю прошивку, созданную под ваши задачи.
Запусти DOS в докере и тогда FreeRTOS у тебя сама взлетит. Не забудь только под рутом избавиться от лишнего. Или sudo rm -rf /* исполни.
Ладн шутки в сторону. Ты коммент в поддержку ролика написал?
Если будет возможность то расскажите про нюансы работы FreeRTOS с библиотеками newlib, когда там идёт работа с float и выводом их через sprintf, когда все падает в HardFault из за особенностей malloc и т.д. Тоесть расскажите про проблемы с которым вы сталкивались на реальных проектах. Заранее спасибо.
Если что-то падает значит вы неправильно выделили стек под эту задачу. По особенности работы с памятью в этом курсе будет сказано
решил в рукопашную, без использования malloc. Пришлось писать свои функции типа atof(), ну и работы со строками.
Вообще отладка ртос даже интереснее самой оси.
Не забудьте запрячь коня перед выездом в соседние владения, средневековые крестьяне.
@@SergeySvistunov спасибо тебе, боярин. Вразумил сиволапых!
Есть вполне рабочий третий вариант:
Вообще ничего не писать в бесконечном цикле. Перевести процессор в режим сна, сразу после всех инициализаций.
В прерывании системного таймера организовываем все нужные периуды, далее создаём низкопреоритетные програмные прерывания, которые вызывает системный таймер.
Если есть какие то процессы которым нужен риалтайм где не желателен джитер, то заводится это через самый простой таймер (к примеру ТИМ6), и так же всё в прерывании.
Слышал противников такому, мол везде написанно что в прерывании ни ни, типа там нужно быть минимум времени.... А смысл? Ну к примеру с тем же опросом датчика. Если уж в прерывании мы проводим слишком много времени и не успеваем, так в любом случае мы так же это и не успеем вне прерывания - менять проц.
У такого метода есть плюс, если мы полностью избавимся от необходимости в системном таймере (всё будет в колбеках переферии и в колбеках таймеров), то перед переводом в сон его можно нафиг выключить.
При этом экономим расход энергии в разы. Мало встречал реальных проектов, которые используют больше 10-20 процентов процессорного времени.
Минусы - читаемость, нужно жёстко документировать всё и вся.
Я понимаю, что привычка и нежелание что-либо менять заставляют искать оправдание дичайшим проявлениям сознания. Однако, я искренне надеюсь, что есть люди понимающие, что описанный вами подход ничего кроме головной боли не несёт. Это совершенно не подходит для сложных задач.
Куда убирается огромный сегмент кода, который призван обеспечить синхронизацию? А уак без синхронизации дальше?
Про микропотребление во FreeRTOS не забудьте. Пожааааалуйста !!!
Да этот ролик уже даже загружен.
- Чё делаешь?
- Айдлю 😀
как это нет возможности быстрого переключения функции? А прерывания уже отменили?
При переходе от суперцикла к FreeRTOS мы решаем одни проблемы, а взамен получаем другие, чтоб решить которые, нужны более глубокие знания. Всё должно быть к месту.
Мне искренне интересно, а какие проблемы мы в итоге получаем?
@@VladimirMedintsev накладные расходы. Перерасходование памяти, если стек задачи брать с запасом, или хадфаулты, если стек недостаточен. Внимательно нужно следить за атоманростью, иначе можно получить сложноуловимые баги. Также при переходе на ОС, нужно менять стиль написания кода, а именно принцип взаимодействия модулей. Я не говорю, что FreeRTOS - это плохо, я говорю, что нужно иметь неплохое понимании для работы в нём. И кстати , если правильно организовать суперцикл, то тоже можно неплохо распределить временные ресурсы.
Чувствуется некоторый намек на "без rtos у вас не поучится следовать best practices разработки ПО". Плюсы rtos которые были перечислены всё-таки можно реализовать и без rtos _но придется превозмогать_. Быть может надо делать упор на первый пункт - rtos вам дает некоторую абстракцию, готовая абстракция с множнством функций из коробки. Хотите - используйте, не хотите - отлично, можно и на суперлупе все сделать - вот примерно так, учитывая все последствия.
Не могли бы Вы высказать свое мнение, дать оценку проекту OpenPLC. Спасибо.
Ответ на ваш вопрос есть у замечательного баснописца Крылова. В басне про Лебедя, Рака и Щуку есть слова максимально раскрывающие суть проекта OpenPLC: "Кто виноват из них, кто прав, - судить не нам; Да только воз и ныне там.".
Подскажите, какой осциллограф выбрать доя изучения работы микроконтроллеров?
Определите имеющийся бюджет и возьмите максимально помещающийся в имеющуюся сумму. Это реальный совет.
@@sergsapov2927 У нас есть один из осликов - приставка к компьютеру. Но только дорогая приставочка больше 150 т.р. по сегодняшним ценам, так мы на него нарадоваться не можем.
Ричард Столман в мире firmware😊
FreeRTOS теряет прерывания, потому что в системных обработчиках часть кода выполняется с отключёнными прерываниями. То-есть FreeRTOS не может 100% гарантировать время реакции на события. Такая фигня получилась по причине роста снизу вверх. FreeRTOS на раннем этапе развития использовала немощные МК, то самое -что было на рынке в тот момент. А потом появился ARM и RISC-V, под который FreeRTOS написала свой порт без смены общей концепции алгоритма.
Вроде-бы есть поддержка ARM и RISC-V, но только на уровне принеси подай. Выглядит примерно как инженер с высшим образованием на разгрузке вагонов.
Для RISC-V вообще мракобесие получилось, там даже документацию на ядро читать не стали.
FreeRTOS типа бесплатная, это её единственное преимущество. Ну как бесплатный просроченный сыр.
Жаль если так,
у СТМ отличный nvic. CortexM
RiscV не так много ресурсов как кажется, ядро на сколько простое, настолько же слабое.
Esp32 вроде адекватно, хотя не знаю с чем сравнивать!
Здравствуйте, а есть какие то курсы?
xn--d1auc.xn--j1alhf.xn--p1ai/sse
07:45: Странная постановка задачи. Зачем обновлять информацию на дисплее каждый цикл, когда это можно делать только при возникновении определённого события? В частности, после считывания определённого сигнала с устройства ввода (н-р, "button1.isDown()") или обновления показаний датчиков.
Это пример демонстрирующий что части задачи могут работать в различных ритмах
@@VladimirMedintsev вам следовало подобрать более реалистичный/обоснованный пример, потому что на основе этого примера какой-нибудь глупый джун, который не пользуется RTOS, начнёт вставлять delay/sleep туда, где он нафиг не нужен и даже противопоказан. "Дядя же показал в youtube".
Если руководствоваться вашим принципом то перед любым роликом нужно делать как минимум 2х часовое введение с оговорками так плохо и так плохо. По сути я не сказал что так надо делать, я показал ситуацию когда компоненты программы работают в разном ритме. Если вам лично этот пример не зашёл, то вы можете попробовать придумать свой. Но уж к теме FreeRTOS это точно не имеет ни малейшего отношения.
@@VladimirMedintsev нет, нужно было просто показать real world problem. Также, в своё время приходилось работать с глупыми джунами, которые в т.ч. насмотрелись "мануалов" в интернете.
13:13 FreeRTOS .
Спасибо за видео. Но я бы добавил сугубо личное ИМХО. 1. Помимо плюсов у rtos есть и минусы, про которые не сказано совсем!!! (К примеру требование более дорогого и мощного МК в плане ОЗУ и ПЗУ как минимум! 2. Необходимо определиться, для поставленной задачи вообще ли требуется rtos, так как в большинстве задач достаточно использования таймера проработанного времени, используя который можно ограничить количество запусков функций в единицу времени (это не сложно, при необходимости можно написать функцию с указанием миллисекунд до истечения которых процесс не запускается) при этом другие процессы спокойно работают, код меньше и читабельность лучше, чем при использовании rtos) 3. Возможно есть что то ещё, но только это пришло сейчас на ум 🤔
Вот вы про первый минус пишете. Про требование более дорогого и мощного МК. Это вы где-то прочитали или просто выдумали? А насколько более мощного и дорогого?
@@VladimirMedintsev ну самое простое если инициализация и работа переферии занимают весь флеш или ОЗУ и хочется проект перенести на rtos. Что тогда делать? Только МК с большим флешем или ОЗУ? Или добавление rtos обладает возможность уменьшить исходный проект или использование ОЗУ?
Правильно ли я понимаю, что опыта использования rtos у вас нету?
@@VladimirMedintsev я вам один вопрос, вы мне другой. А ответа нет. А хотел я услышать, что чудес не бывает, и при использовании rtos вам потребуется свободных 4-10кбит ПЗУ и 1кбит+ ОЗУ как минимум (которых уже может попросту не быть). Про производительность не говорю. Но думаю, чудес тоже ждать не стоит.
Вы не вопрос задали, а фантазировали и фантазировали не имея реального опыта. И дело тут сразу в нескольких факторах:
1. Создавая проект разработчик должен адекватно оценивать необходимый МК. Т.е. нужно выбирать МК с небольшим запасом по ресурсам. Если это не сделано, то у вас уже проблемы.
2. Если в процессе развития проекта он перестает помещаться в МК это повод к замене микроконтроллера на более жирный. Благо pin-to-pin совместимость никто не отменял и делается это элементарно.
В перечисленных выше пунктах нет ни слова о rtos там говорится о правильности выбора микроконтроллера. А теперь что касается ваших измышлений на тему "код увеличится", "проект не поместится". Не забывайте, что в проекте реализованном БЕЗ rtos есть куча кода реализующего логику, последовательность переключения функций. С использованием rtos этот код сократится и освободится место. Да возможно потребуются дополнительно 4 кб флеша и 1-2 кб озу, но такие обьемы есть всегда.
Ну и да, это хорошо, что вы не стали говорить про производительность. Rtos требует под свои нужды менее 1% и вот они есть всегда. Однако если я вдруг попрошу вас оценить производительность которая требуется под конкретную задачу, выяснится что сделать этого вы не можете. Ну или если попрошу обосновать необходимость работы МК на той или иной тактовой частоте.
Если будет возможность то расскажите про как все это работает с C++, а то уже трэнд везде использовать C++14
Где вы этот тренд видели?
@@VladimirMedintsev на BMW и Miele например, везде полностью стандарт C++14
@@bagamut т.е. вы пишете код для компании BMW?
@@VladimirMedintsev да
@@sergsapov2927 вперед, видео снимайте
Помнится уже было на канале про фриэртос... Вполне достаточно для начала работы. А остальное практика...
А по мне так - мк должен быть мк, а из него делают настольный компьютер
Это современный подход к разработке. И использование операционной системы повышает производительность и уменьшает количество ошибок.
@@VladimirMedintsev Да, современный. Ну да Бог с ним.
На столе лежит G474 может осовременню благодаря вам, благо памяти 128 на 128.
Думается мне, что RTOS "съедает" огромное количество ресурсов МК. Меня всегда останавливает от ее использования мнение старших коллег, которые пробовали FreeRTOS для наших задач. Мнение одно: увеличивается размер программы.
Собственно,
Задача: управление дизельным отопителем. 3-4 исполнительных элемента (шим), 7-8 датчиков (АЦП), цифровой канал связи (uart).
МК: самый дешевый, который был на рынке в больших количествах, например, Attiny88 (8 Кбайт flash/ 0.5 Кбайт ram). Сейчас занято 95% FLASH и 85% RAM.
Вопрос: могла бы ОС реального времени вместиться в такой маленький контроллер и упростить разработку? Или FreeRTOS - это для более старших МК (на ядре cortex-m3 и выше)?
Без реализации графики, чисто управление всей электроникой ИВЛа приблизительно 90к ПЗУ, 12к ОЗУ. Внутри алгоритм управления, стек MODBUS, консолька и телеметрия состояния аппарата с большим разрешением по времени.
Использование операционной системы вполне оправдано другое дело что скорее всего ваши коллеги не разобрались с тем как её правильно настраивать. Операционная система позволяет нам оптимизировать код сделать его с меньшим количеством ошибок.
Тут игра идет на стоимость времени разработки против стоимости железа. Т.е. если у вас не 100 000 партии устройства, то на стоимость железа в сравнении со стоимостью работы инженера можно забить, а потому, ЕСЛИ снижается время на написание и отладку кода, вместо дешевого МК вполне можно взять жирный.
Вы случайно не из Самары, там делают широкий спектр подогревателей, сейчас они на стм32.
Ваше устройство я бы делал с использованием RTOS, но, боюсь, с таким количеством памяти это было бы сложно. Если вообще возможно. Мне было бы интересно, если кто-то назовет RTOS, которая будет работать на таком процессоре.
Не важно какое у процессора ядро. Нужно больше памяти. Это касается и флэш для размещения кода RTOS, и ОЗУ из-за того, что стэки у каждой задачи свои и требует бОльше памяти.
Сорри, но я так и не услышал внятного списка плюсов FreeRTOS (и вообще RTOS).
1. Модульность - это архитектура приложения и органиация разработки проекта
2. Улучшить расширяемость - за счет модульности, хорошо но см п1
3. Абстрагирование - это архитектура и огранизация проекта см п1
4. Командная работа - органиация разработки проекта см п1
5. Утилизация неиспользуемого времени - архитектура приложения, нужна такая функциональность, она закладывается в архитектуру, не нужна не закладывается.
6. Отложенная обработка прерываний - архитектура приложения, тоже самое что и п5
Написать наивный диспетчер задач с тестами это пол дня работы с нуля.
По поводу синхронизации: вы говорите, что большой кусок кода для синхронизации уходит в ядро ОС, но мое представление о хорошем приложении, где полезная работа стремится к 100% времени использования процессора, а синхронизация это потери, в идеальном приложении они должны быть 0. Да, я понимаю, что это не реализуемо в реальном приложении, но надо стремиться к этому. А может проекту и не нужна вся эта синхронизация?
ЗЫ. Это здорово, что вы пытаетесь поделиться своими знаниями! :)
8:00 72 МГц при длине тела 720 циклов, ну и норм, ШИМ 100КГц!
Какая нам разница куда процессор тратит ресурс! Электрику всё одно надо!
Синусоиду 100 полувон, можно порезать с частотой 1000раз на π ✓
Погрешность и коррекция 1/1000 этих 0.1%
"Как только вы напишете new Thread - все кончено, ваша программа теперь содержит устаревший код" (с) Стивен Клири.
В современном мире порождение потоков - абсолютно такая же конченная вещь, как счетчики циклов, поллинг и функции обратного вызова. Эмбеддед среда, конечно, отсталая в этом плане. Но с ростом количества ядер и туда подтянутся прогрессивные техники. И весь говнокод можно будет на помойку отправить, вместе с пенсионерами )
Одна беда с этими операционками, не пойми сколько памяти нужно выделять :(
Все там понятно и достаточно легко считается. Будет видео на эту тему.
@@VladimirMedintsev ок, посмотрим. Спасибо за труд!
И внезапно все что вы рассказывали делается на одном таймере и несколько строчек кода и вот ваш диспетчер готов, не нужно никакого RTOS. И ничего лопатить не нужно. Как хотите мигайте, пищите, опрашивайте. У вас подход АСУшника. Мы ничего не понимаем в железе но надо быстро нахерачить проект и получить деньги. Это правильный подход. Но вот для себя так писать моветон. Это тупик.
Жаль тут нету смайлика "рука-лицо".
@@VladimirMedintsev Согласен, очень жаль. Я бы его поставил в конце прошлого сообщения.
Интересно - а где в Ираке?
Что где в Ираке?
То есть мы про прерывания, про аппаратные таймеры, и другие фичи контроллеров, забыли.
И теперь всё это будем организовывать програмно?
Ничего подобного. Все перечисленное остается и прекрасно работает.
Иногда проще создать программный таймер в той же FreeRTOS. Настроить аппаратный таймер в STM32 та ещё задача с вычислением делителей и всего такого.
@@Leech00001 Это работает толька тогда, когда ваша FreeRTOS не занимает 99,9% оперативной памяти контроллера, и у вас есть средства, покупать более дорогой контроллер, ради только лени, лени разбираться в аппаратных возможностях контроллера.
@@user-fw7sq9sj5k Ну так в чем проблема - сделай свой диспетчер задач и не займет он столько места. Я, к примеру, сделал и вместе с памятью под задачи он занимает в AVR меньше 400 байт кода плюс пару десятков байт в оперативке. Что касается покупки более дорогого... Тут вопрос только в том, что дороже стоит - более жирный МК или время разработчика по утаптыванию имеющегося функционала в более тощий.
@@user-fw7sq9sj5k тут уже писали что если вы не производите решения в 1М+ количествах, то перейти на более жирный камень это не пипец финансовая проблема. Стоимость будет изменяться в центах. И вы ещё забываете что количество аппаратных таймеров ограниченно. Может покажете камешек который поддерживает 50 аппаратных таймера. Может расскажете тогда как это сделать без программной реализации.
Пора Esp32 ! 21й век!
СТМ уже надёжно устарел.
Только для аппаратных решений !
Пояснение простое и понятное, но не совсем верное в первой половине видео, все можно реализовать на прерываниях таймеров без ОС, об этом наверное стоило бы упомянуть.
Так объяснение не совсем верное или не полное??? Следуя вашей логике я должен был все пагубные практики перечислить?
да не не) огромное вам спасибо за этот курс. Если желание будет, расскажите пожалуйста про каких-нибудь пару проектов где это применено и как это применено. Смотришь ролики либо читаешь книгу, все легко все понятно, но когда сам садишься за проект, а шаблонного опыта мало(именно с ОС), становится проблемой. Плюс если даже спросить, то получаешь ответы: Нахрена тебе ОС, либо нахер столько задач ОЗУ много? В итоге все сложно)
Как там на Крымском мосту, ничего в море не сдувает?
Нет, все просто замечательно.
Владимир, хотелось бы услышать ваши комментарии по поводу пропуска прерываний при переключении контекста задач во FreeRTOS
Там не происходит какого-либо пропуска прерываний.
на какой архитектуре? Какое конкретно прерывание? Что подразумевается под "пропуском"? Не вызывается ваш таск или стандартный обработчик? Я так понял, речь про software interrupts.
На arm. Не вызывается обработчик
@@DmitriNesterov Собираемся делать большой проект с использованием ртом, но смущает обилие информации про проблемы с обработчиками аппаратных прерываний именно при смене контекста задач. Проект предполагает большую частоту вызова обработчиков прерываний
Нет такой проблемы.
Это на C код?
Да, это язык Си.
@@VladimirMedintsev Почему тогда "count" то с заглавной буквы, то со строчной. Шутка, я понимаю, что этот пример не про это.
Большая да, замечательная не соглашусь...
Есть принцип KISS. Пока хватает таймеров и прерываний по таймерам.
// ---------------------
{ t = millis(); // каждые 2 мсек (500гц) #define T1_OUT 2
if( t1_next < t ) { t1_next = t + T1_OUT;
potent =analogRead(PA0);
} // ---------------------
t = millis(); // каждые 50 мсек (20гц) #define T3_OUT 50
if( t3_next < t ){ t3_next = t + T3_OUT;
Serial.print(potent);Serial.println(" ");
} // ---------------------
t = millis(); // Мигать светодиодом каждые 20-1000 мсек (1гц-50гц) в зависимости от потенциометра
if( t4_next < t ){ t4_next = t + 20 + potent*0.25;
GPIOC_BASE->ODR ^= 0b1