[Ruslan1 16]

32 минуты назад, Arlleex сказал:

Ну а во-вторых, какая RTOS, если надо по UART/SPI/I2C че-то настроить, пару раз отправить показания датчика и заснуть? Мне лично будет даже лень расчехлять RTOS для этого.

Да пожалуйста:

Задача1: раз в какое-то время запускать опрос датчика

Задача2: просыпается по прерыванию, которое посылает сюда сообщение из датчика (принятое, например, по ПДП или побайтово). Обработка и отсылка сообщения в задачу, собирающую данные со всех датчиков для формирования из них нужного пакета (например, передача 20 показаний датчика за раз, или десяти опрошенных датчиков).

задача3: работа с внешним интерфейсом (запросы-ответы от линии связи, передача всех запрошенных данных)

задача4: работа с внешним интерфейсом (периодические отсылки, например измеренные данные)

задача5: локальный интерфейс (лампочки-кнопочки-дисплейчики)

задача6: локальный отладочный терминал (обычно UART с системой команд и/или отладочным логом)

задача7: опрос набортных сенсоров (ну например напряжение питания и состояние батареи).

задача6: вотчдог, контролирующий все задачи: принимает сообщения от всех задач и ребутит систему или отдельные задачи если ему чего-то не нравится.

А еще очень помогают приоритеты, чего суперлупом не сделать. Например, когда длинные вычисления делаются в задаче с малым приоритетом в фоне, а подача в нее новых данных (буферизация) идет средствами RTOS (очередь сообщений). Понятно, что природу не обмануть и суммарное время нужно считать (чтобы все вычисления успевались до переполнения очереди), но для особо настырных есть многоядерные камни (начиная с народного ЕСП32)- и задачи запросто могут быть разделены между ядрами. У меня есть проект, где одно ядро ЕСП32 только DSP вычислениями загружено по такой схеме.

 

И что значит "расчехлять"? оно такое страшное? Первый раз, конечно, нужно документацию прочитать, чтобы сконфигурировать ну и вообще понять что это и как. Но даже тут сэкономить можно: просто найти на используемый камень пример в Интернете с морганием светодиодом, и использовать как опору. И читать документацию, смотря на этот пример.

9 минут назад, jcxz сказал:

ааа.... Я уж было подумал, что вы реально на Юкос работали. И в нефти купались. 

Не, так глубоко я не заплывал. К сожалению. Или к счастью, это сейчас спорный вопрос. 🙂

[x893 35]

17 minutes ago, Ruslan1 said:

Да пожалуйста:

Задача1: раз в какое-то время запускать опрос датчика

Задача2: просыпается по прерыванию, которое посылает сюда сообщение из датчика (принятое, например, по ПДП или побайтово). Обработка и отсылка сообщения в задачу, собирающую данные со всех датчиков для формирования из них нужного пакета (например, передача 20 показаний датчика за раз, или десяти опрошенных датчиков).

задача3: работа с внешним интерфейсом (запросы-ответы от линии связи, передача всех запрошенных данных)

задача4: работа с внешним интерфейсом (периодические отсылки, например измеренные данные)

задача5: локальный интерфейс (лампочки-кнопочки-дисплейчики)

задача6: локальный отладочный терминал (обычно UART с системой команд и/или отладочным логом)

задача7: опрос набортных сенсоров (ну например напряжение питания и состояние батареи).

задача6: вотчдог, контролирующий все задачи: принимает сообщения от всех задач и ребутит систему или отдельные задачи если ему чего-то не нравится.

А еще очень помогают приоритеты, чего суперлупом не сделать. Например, когда длинные вычисления делаются в задаче с малым приоритетом в фоне, а подача в нее новых данных (буферизация) идет средствами RTOS (очередь сообщений). Понятно, что природу не обмануть и суммарное время нужно считать (чтобы все вычисления успевались до переполнения очереди), но для особо настырных есть многоядерные камни (начиная с народного ЕСП32)- и задачи запросто могут быть разделены между ядрами. У меня есть проект, где одно ядро ЕСП32 только DSP вычислениями загружено по такой схеме.

 

И что значит "расчехлять"? оно такое страшное? Первый раз, конечно, нужно документацию прочитать, чтобы сконфигурировать ну и вообще понять что это и как. Но даже тут сэкономить можно: просто найти на используемый камень пример в Интернете с морганием светодиодом, и использовать как опору. И читать документацию, смотря на этот пример.

Не, так глубоко я не заплывал. К сожалению. Или к счастью, это сейчас спорный вопрос. 🙂

Не понятно из-за чего сыр-бор идёт.
Можно с РТОС, можно без.
Кому как удобнее, так и делает.

 

[haker_fox 60]

В далёком 2006 году, когда я был молод и неопытен, задался тем же вопросом, и как раз про FreeRTOS. Её конкретно не попробовал на махонькой ATmega16, которая у меня имелась, а scmRTOS, за счёт своей компактности, позволил вкусить дивные плоды ОСРВ, да ещё и возбудить интерес к Си++.

С тех пор я все проекты делаю с использованием ОСРВ. Правда на работе вынужден по указанию включать в свои проекты FreeRTOS, и даже использовать её))) Хотя, не испытываю от неё особого восторга. Она, ИМХО, громоздка. Но всё же вполне себе адекватная ОС, предоставляющая в избытке необходимые сервисы на все случаи жизни.

Как и для любого правила есть исключения, так и я не использую ОСРВ для проектов, которые можно назвать тестовыми: проверить новый МК, или работоспособность некой микросхемы в связке с микроконтроллером. Для проектов на Raspbery Pi Pico не использую ОС, да ещё и программирую на Python, о, ужас! Но это для любительских проектов и соверешнно некритичных к производительности (различные вспомогательные измерительные инструменты и приборы).

Подводя итог, могу сказать, что любая догма на счёт применимости или, наоборот, неприменимости ОСРВ - химера ограниченного ума, перефразируя Ральфа Уолдо Эмерсона (в оригинале: постоянство - химера ограниченного ума).

[artemkad 53]

12 часов назад, Ruslan1 сказал:

А еще очень помогают приоритеты, чего суперлупом не сделать.

Вот там выше я привел простейший диспетчер задач для суперлупа суть которого заключается в анализе флагов(битовых или таймерных - не суть важно) и запуске в зависимости от них того или иного куска кода. Ничего не мешает впихнуть в анализ флагов и анализ приоритетов. Впрочем, почти всегда система приоритетов является костылем. В подавляющем большинстве задач достаточно тех двух приоритетов которые обеспечиваются системой прерываний - то что требует немедленной реакции и то что исполняется как получится. И связываются эти два слоя буферами(очередями) и флагами.

Разница суперлупа от вытесняющей операционки лишь в способе оформления задач. В суперлупе они пишутся как проходные с как можно более быстрым завершением, а в вытеснялках как бесконечные циклы с учетом переключения на другую задачу в любой момент цикла.  Ну и накладные расходы с этими подходами связанные. В частности, для вытеснялок критическим является объем ОЗУ сжираемый на каждую следующую задачу.

12 часов назад, Ruslan1 сказал:

Например, когда длинные вычисления делаются в задаче с малым приоритетом в фоне,

Или вообще не делается, потому как парочка задач с высоким приоритетом отбирает все процессорное время. И, что самое забавное, обычно эти задачи с высоким приоритетом ничего не делают(зачастую ожидают результатов тех самых расчетов с низким приоритетом).

Длинные вычисления на которые можно забить болт зачастую говорят о том, что проблема в консерватории.

12 часов назад, Ruslan1 сказал:

но для особо настырных есть многоядерные камни (начиная с народного ЕСП32)- и задачи запросто могут быть разделены между ядрами.

А для тех, кто хоть раз пытался разделить задачи между ядрами ESP32, слово "запросто" вызывает недоумение. Единственное что там "запросто" получается это усыпить(отключить) все ядра оставив лишь одно с убогой системой команд  на дежурке. В остальном-же для каждого ядра пишется свой отдельный код который мало взаимодействует между ядрами.

12 часов назад, Ruslan1 сказал:

Первый раз, конечно, нужно документацию прочитать, чтобы сконфигурировать ну и вообще понять что это и как.

И первый и второй и двадцатый раз от документации на ОС не оторвешься. Если конечно проекты сложнее моргания светодиодом. 

 

[siargy 6]

4 hours ago, artemkad said:

В подавляющем большинстве задач достаточно тех двух приоритетов которые обеспечиваются системой прерываний - то что требует немедленной реакции и то что исполняется как получится. И связываются эти два слоя буферами(очередями) и флагами.

не могли бы обьяснить, как реализована система:

- есть алгоритм, запускается периодически по таймеру, исходя из показаний разных датчиков и предыдущих состояний чегото там выщитываеца и в конце выдается сигнал разрешения работы

- в прерывании обрабатывается сигнал ошибки и все выключаеца

 

Собственно как разрулить ситуацию если ошибка прилетает между моментом опроса и обсчета, перед выдачей разрешения работы?

[jcxz 184]

5 часов назад, artemkad сказал:

Вот там выше я привел простейший диспетчер задач для суперлупа суть которого заключается в анализе флагов(битовых или таймерных - не суть важно) и запуске в зависимости от них того или иного куска кода.

То, что вы "приводили выше" к диспетчеру задач имеет отношение такое же, как собачья конура к особняку.

5 часов назад, artemkad сказал:

Разница суперлупа от вытесняющей операционки лишь в способе оформления задач. В суперлупе они пишутся как проходные с как можно более быстрым завершением, а в вытеснялках как бесконечные циклы с учетом переключения на другую задачу в любой момент цикла.

Ну да. При такой логике и между лисапедом и самолётом разницы почти никакой нет. Ведь и у того и другого есть колёса и они могут ездить. 

5 часов назад, artemkad сказал:

Или вообще не делается, потому как парочка задач с высоким приоритетом отбирает все процессорное время. И, что самое забавное, обычно эти задачи с высоким приоритетом ничего не делают(зачастую ожидают результатов тех самых расчетов с низким приоритетом).

Длинные вычисления на которые можно забить болт зачастую говорят о том, что проблема в консерватории.

Покажите пожалуйста, каким образом с помощью вашего "диспетчера" распределить время одного CPU между двумя задачами.

Одна из которых: Обслуживает частые высокоприоритетные события с малым требуемым временем обслуживания. Например - управление каким-то технологическим процессом.

Вторая: Сложная тяжёлая задача, выполняемая на низком уровне приоритета. Типа парсинга или генерации HTML-страниц. Или MPEG-декодера. Или отрисовки различных графических элементов, имеющих совершенно разный размер и длительность отрисовки, отличающуюся на порядки? или чего-то ещё подобного. Где данные обрабатываются большими блоками непрерывно.

Как? И в какую консерваторию обращаться?

 

А если к тому же эти две задачи ещё и обращаются к общему разделяемому ресурсу? (флешка или ФС или т.п.) Драйвер которого имеет API, вызываемый с уровня задачи ОС.

[Ruslan1 16]

4 часа назад, artemkad сказал:

Или вообще не делается, потому как парочка задач с высоким приоритетом отбирает все процессорное время. И, что самое забавное, обычно эти задачи с высоким приоритетом ничего не делают(зачастую ожидают результатов тех самых расчетов с низким приоритетом).

Если оно "ждет", то спит и вообще не занимает ресурс, проснется по событию RTOS (очередь или семафор). 

Само собой, нужно понимать что от чего зависит и как. Да, я помню, еще в описании uC/OS-II было описание как докатиться до взаимной блокировки, задач, конечно же такое возможно и в FreeRTOS. 

4 часа назад, artemkad сказал:

А для тех, кто хоть раз пытался разделить задачи между ядрами ESP32, слово "запросто" вызывает недоумение.

А что не так? у меня сейчас есть проект такой на ESP32. Общение между задачами происходит через стандартные сервисы FreeRTOS: задача, запущенная на одном ядре, выдает данные в очередь, а задача, запущенная на другом ядре, эту очередь ждет. Работает, проверял логическим анализатором- очень все предсказуемо (задержки и время обработки). Я Espressif фреймворк использую. Там есть в документации кратко, как "ванильный FreeRTOS" у них рапараллелен на два ядра: ESP-IDF FreeRTOS SMP Changes.

 

4 часа назад, artemkad сказал:

Единственное что там "запросто" получается это усыпить(отключить) все ядра оставив лишь одно с убогой системой команд  на дежурке. В остальном-же для каждого ядра пишется свой отдельный код который мало взаимодействует между ядрами.

Вот этого не пробовал. Знаю, что можно RTOS только на одном ядре запустить, а другое врукопашную использовать (то есть без сервисов и шедулера), но я так глубоко не копал.

[Ruslan1 16]

2 часа назад, siargy сказал:

не могли бы обьяснить, как реализована система:

- есть алгоритм, запускается периодически по таймеру, исходя из показаний разных датчиков и предыдущих состояний чегото там выщитываеца и в конце выдается сигнал разрешения работы

- в прерывании обрабатывается сигнал ошибки и все выключаеца

 

Собственно как разрулить ситуацию если ошибка прилетает между моментом опроса и обсчета, перед выдачей разрешения работы?

Задача№1: принимает решение о включении (на основе данных) и выдает этот сигнал в очередь для задачи №4

Задача№2 (или прерывание): принимает решение о выключении (на основе данных) и выдает этот сигнал в две очереди: для задачи №3 и для №4.

Задача№3: ждет (очередь с сигналами от №2) и выключает. больше ничего не делает.

Задача№4: ждет (очередь с сигналами от 1 и 2), и принимает решение по заранее обработанному алгоритму. Например, включает если пришел сигнал от №1(включить) и не пришел сигнал от №2(выключить) в течении предыдущих 2 ms и в течении следующих 10 ms.

Но вариантов много. Идея в том, чтобы разделить сложное действие на небольшие простые модули(задачи), с входом и выходом, которые просто спят пока нет новой входной информации.

[artemkad 53]

55 минут назад, jcxz сказал:

Покажите пожалуйста, каким образом с помощью вашего "диспетчера" распределить время одного CPU между двумя задачами.

На кой задаче распределяемое время? Если для выполнения чего либо, то как и в любом суперцикле сперва выполнится одна задача, а затем вторая. Суммарно это займет даже меньше процессорного времени чем если они бы в процессе переключались между собой.

1 час назад, jcxz сказал:

Одна из которых: Обслуживает частые высокоприоритетные события с малым требуемым временем обслуживания. Например - управление каким-то технологическим процессом.

Вторая: Сложная тяжёлая задача, выполняемая на низком уровне приоритета. Типа парсинга или генерации HTML-страниц. Или MPEG-декодера. Или отрисовки различных графических элементов, имеющих совершенно разный размер и длительность отрисовки, отличающуюся на порядки? или чего-то ещё подобного. Где данные обрабатываются большими блоками непрерывно.

Не вижу в чем проблема в парсинге  страниц - там по любому самый медленный процесс в приеме и вызов задачи можно осуществлять по факту приема строки или чанка. Декодирование MPEG предполагает, что производительности хватает на декодирование кадра пока приходит следующий, а отсюда для управления чем либо с частотой как минимум 25 раз за секунду будет море времени.  В чем проблема с отрисовкой - тоже большой вопрос. Чай не на Басике пишем.

[jcxz 184]

12 минут назад, artemkad сказал:

На кой задаче распределяемое время? Если для выполнения чего либо, то как и в любом суперцикле сперва выполнится одна задача, а затем вторая. Суммарно это займет даже меньше процессорного времени чем если они бы в процессе переключались между собой.

Т.е. - начала парситься страница. Это длилось например 100мсек. За это время процесс управления технологическим оборудованием (котлом) долго не получал управления и котёл взорвался.

Суперлуп рулит. 

12 минут назад, artemkad сказал:

Не вижу в чем проблема в парсинге  страниц - там по любому самый медленный процесс в приеме и вызов задачи можно осуществлять по факту приема строки или чанка. Декодирование MPEG предполагает, что производительности хватает на декодирование кадра пока приходит следующий

Какие "строки"/"чанки"? Парсить нужно целиком принятую и проверенную страницу. А если она к тому же пришла в gzip-е? Что часто делают современные сервера?

MPEG тоже декодируется только когда кадр принят полностью. Никаких "чанков" чтобы это ни было.

12 минут назад, artemkad сказал:

для управления чем либо с частотой как минимум 25 раз за секунду будет море времени. 

А 1000 раз в секунду? Например - инвертором? Или ещё каким ПИД-регулятором?

И с чего вы решили, что для парсинга страницы или чего-то ещё всегда хватит 1/25 сек? Прям на любое-любое действие хватит 1/25 сек? правда? 

 

PS: Простейшее JSON-сообщение может прийти такого размера, что на его парсинг даже на довольно мощном Cortex-M4 может потребоваться несколько десятков или сотен мсек.

И ещё 100500 разных других алгоритмов, где есть аналогичные требования. Везде в них суперлуп сядет в лужу.

[artemkad 53]

40 минут назад, Ruslan1 сказал:

Если оно "ждет", то спит и вообще не занимает ресурс, проснется по событию RTOS (очередь или семафор). 

Спит это если задача отдает управление RTOS, а не тупо ожидая чего-то еще в цикле.

3 часа назад, siargy сказал:

есть алгоритм, запускается периодически по таймеру, исходя из показаний разных датчиков и предыдущих состояний чегото там выщитываеца и в конце выдается сигнал разрешения работы

- в прерывании обрабатывается сигнал ошибки и все выключаеца

 

Собственно как разрулить ситуацию если ошибка прилетает между моментом опроса и обсчета, перед выдачей разрешения работы?

Два флага(разрешение алгоритма и разрешение защиты) и одна общая процедура включения/отключения всего и вся вызываемая в прерывании и по завершении таймера

[Ruslan1 16]

3 минуты назад, artemkad сказал:

Спит это если задача отдает управление RTOS, а не тупо ожидая чего-то еще в цикле.

Если задача "тупо ожидает в цикле" - то это уже непрофильное применение RTOS. Что-то нужно менять в делении на задачи, например разделить задачу на две. Задача не должна просто ждать, не отдавая управление. Для длинных пауз есть системный сервис (в тиках RTOS), для малых величин- таймер с прерыванием и ожидание семафора от этого таймера в задаче.

 

3 минуты назад, artemkad сказал:

Два флага(разрешение алгоритма и разрешение защиты) и одна общая процедура включения/отключения всего и вся вызываемая в прерывании и по завершении таймера

А если флаги выставлены в порядке "1)включить, 2)выключить", а просканированы в порядке "1)выключить 2)включить", то в результате оно останется включенным? Если сигнал аварии и сигнал включения несинхронны, то запросто такое возможно. И нужно какие-то предыстории и постистории контролировать, хотя бы чтоб не включить там, где должно быть выключено.

[jcxz 184]

27 минут назад, artemkad сказал:

Спит это если задача отдает управление RTOS, а не тупо ожидая чего-то еще в цикле.

Если у программера задача "тупо ожидает в цикле", то такой программер очевидно не знает - что такое РТОС и как в ней работать. И не знает что такое "событийно-ориентированное программирование". И ему нужно учиться, а не быдлокодить.

[artemkad 53]

21 минуту назад, jcxz сказал:

Парсить нужно целиком принятую и проверенную страницу.

А браузеры-то этого и не знают начиная выводить страницу еще до окончания ее полного приема. Забавно бы выглядело иное во времена связи через телефонные модемы. По любому, при парсинге всегда есть ключевые слова и разделители по границе которых можно отдавать управление в кольцо. 

36 минут назад, jcxz сказал:

Т.е. - начала парситься страница. Это длилось например 100мсек.

100мс  это 100 000 мкс или 0.8...2млн операций на древней AVR-ке.  Опять-же, сколько времени займет ее прием?

55 минут назад, jcxz сказал:

А если она к тому же пришла в gzip-е?

Помнится там тоже обработка идет кусками по завершению которых никто не мешает заняться остальным.

57 минут назад, jcxz сказал:

За это время процесс управления технологическим оборудованием (котлом) долго не получал управления и котёл взорвался.

 Если для котла критичны 100мс, то что мешает отработать аварийные цепи в прерываниях? Судя по тому, что у камня хватает ресурсов для парсинга зипованных web-страниц, время подобной реакции будет исчисляться микросекундами. 

[artemkad 53]

37 минут назад, Ruslan1 сказал:

Что-то нужно менять в делении на задачи, например разделить задачу на две.

И каждой задаче откусывать кусок оперативки. Как по мне, множить задачи в суперлупе обходится как-то дешевле...

40 минут назад, Ruslan1 сказал:

Задача не должна просто ждать, не отдавая управление.

Ну так РТОС сама переключит контекст. На что многие и рассчитывают. Причем речь не всегда о тупом ожидании - иногда это оооо-чень длинные циклы.

44 минуты назад, Ruslan1 сказал:

А если флаги выставлены в порядке "1)включить, 2)выключить", а просканированы в порядке "1)выключить 2)включить", то в результате оно останется включенным?

Не останется. Флаги не сканируются, а читаются. Атомарно. Как достичь атомарности чтения/записи в байт состояния это уже отдельный вопрос. Ну или биты аварии читать последними если хочется полностью разделить рабочие и аварийные флаги.