AVR и FreeRTOS (Многозадачность)

[artemka19]

Имеющимися блоками UART от FLProg изменить скорость наверное не получится.
Перед новой Serialx.begin() вроде придется выполнять Serialx.end();

тут нужно смотреть что в библиотеке Serial.

Если к примеру взять библиотеку WebServer для esp32, то в ней есть такая конструкция:

void WebServer::begin() {
close();
_server.begin();
}

где мы видим, что при вызове WebServer.begin происходит сначала выполнение функции close();, а уже только потом запуск веб-сервера.
Т.е. для перезапуска веб-сервера вовсе необязательно вызывать команду WebServer.stop или WebServer.end
Вполне возможно что и в библиотеке Serial точно также.

[artemka19]

Dryundel, а вот теперь вопрос: а почему так сделано? от кого/чего эта защита?

Возможно конечно что и от Случайного запуска нескольких копий веб-сервера....т.е. по сути это запрет на нескольких потоков WebServera в самой библиотеке.

О чем я и говорил выше: нужно переписывать библиотеки для rtos

[Dryundel]

Dryundel, а вот теперь вопрос: а почему так сделано? от кого/чего эта

Не суть зачем. Тот кто писал, наверняка учитывал нюансы.
Вопрос в том, на сколько я понял, что задачи в RTOS не выполняются от начала и до конца. Они приостанавливаются или блокируются, выполняются частями и возврат в задачу происходит подобно возврату из прерывания. Поэтому нельзя при возврате задачу установить параметры того же Serial. Но там есть и другие механизмы. Как с ними правильно работать, пока не понял. К примеру есть параметр задачи и что то же в него можно передавать. Естественно о реальной многопоточности речь не идёт. Не думаю что возможна перенастройка порта каждый раз при возврате в задачу. Поэтому я скорей склонен согласиться, что такие экзотические выкрутасы в RTOS не прокатят.

[artemka19]

теперь про память:
(на примере того же веб-сервера есп32 )

void WebServer::sendContent_P(PGM_P content, size_t size) {
const char * footer = "\r\n";
if(_chunked) {
char * chunkSize = (char *)malloc(11);



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

Значит что?
Значит надо запускать класс в каждом потоке отдельно.

А значит и памяти нужно в 2 раза больше. ( 2 х malloc(11)).

Я согласен - вполне реально запускать rtos в arduino ide и получить многопоточность....но какой ценой мы получаем эту самую многопоточность?

Нам просто нужна память...много памяти...причем и динамической в том числе

[artemka19]

мы просто-напросто затрем все что у нас было сохранено в буфере в другом потоке.

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

Отправлено спустя 47 минут 29 секунд:

Поэтому нельзя при возврате задачу установить параметры того же Serial

Почему нет?
если в задачу можно передать флаг и скорость, то задача может выглядеть так:

void Task1 (en, speed) {
//---тут код задачи
if (en){
Serial.stop;
Serial.begin(speed);}
//---и тут код задачи
}

[artemka19]

но это НЕ будет многопоточностью.
нам же нужно будет еще и буфер куда то опорожнить.

Да и фиг бы с ним с буфером (можно подождать в крайнем случае): но мы разрываем соединение (Serial.stop) - вот это куда серьезнее

[Dryundel]

artemka19, ну вот как то так.
Смена скорости Serial каждые 5 сек. Обсуждаем дальше?

3_Task_AVR_FreeRTOS_SpeedSerial.ino

(1.97 КБ) 28 скачиваний

Отправлено спустя 5 минут :
ecoins, вот здесь присутствует мьютекс, можете глянуть. На словах позже буду рассказывать.

Отправлено спустя 18 минут 16 секунд:

Это наверное нужно чтобы впихнуть невпихуемое. Но нам проще купить камушек помощнее. Подход Ecoins намного понятнее и то не сильно заходит основной массе.

Подход ecoins, основан на своеобразном представлении RTOS. Это личная разработка, которая изобреталась для обхода камней преткновения в FLProg. Phazz, если быть честнее, заслуга того, что эта система хоть как то зашла основной массе, не этой вот массы, а исключительно ecoins, и стоило ему невероятных усилий. Другой бы уже давно сломался.
Камушек говорите помощнее. Ну да конечно, каждому Сизифу свой камушек. А на достаточно мощных камушках уже разработчиком в ядро внедрена RTOS. Наверное не просто так. А вот скажите, конкретно Вы на чем учились? На мощных камушках или все-таки на хиленькой и дешевой, в то время, AVR? Вот то то и оно. Хоть, как говорит artemka19, для AVR FreeRTOS игрушка, это не убило RTOS в целом.

[ecoins]

Смена скорости Serial каждые 5 сек. Обсуждаем дальше?
3_Task_AVR_FreeRTOS_SpeedSerial.ino

Посмотрел скетч - очень интересно и полезно.
Обращу внимание, что стандартными средствами FLProg такие действия не реализовать, поскольку в них нет блока Serial.end.
На что обратил внимание - примененная библиотека Arduino_FreeRTOS.h поддерживает только контроллеры AVR.
Но вероятно, библиотеки на другие контроллеры совместимы основному функционалу API.
Надо пробовать. Круг наших интересов и в том. чтобы наработки должны без особых проблем работать на разных архитектурах.
----------
Одной из особенностей работы на разных архитектурах является различие (обычно нюансы) в работе основных интерфейсов (UART,i2c,SPI,1-Wire), которые мы решаем на библиотечном уровне.
Соответственно универсальное применение например Serial,begin() или Serial1.begin не всегда приемлемо.
--------
Вопрос: в скетче код:
xSemaphoreTake(mutex, portMAX_DELAY)
означает захват порта UART0 ?
---------
Очень интересная тема создана, и идет полезное обсуждение,
Спасибо.
---------

[Dryundel]

Но вероятно, библиотеки на другие контроллеры совместимы основному функционалу API.

Как то я в этом сильно сомневаюсь. У ESP своя RTOS у RPi своя.
Вот скажите, почему бы разработчикам ядра ESP не привязаться к стандартным функциям Servo например или по прерываниям. Нет же изгольнулись, добавили пару буковок, а нахрена? Вот то же самое и с RTOS наверняка.

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

Это очень похвально, но складывается такое впечатление, что чем дальше идет развитие, тем сложней это делать. Одни в лес, другие по дрова. Вроде одно и тоже, а каждый вносит свои оттенки.

Одной из особенностей работы на разных архитектурах является различие (обычно нюансы) в работе основных интерфейсов (UART,i2c,SPI,1-Wire), которые мы решаем на библиотечном уровне.
Соответственно универсальное применение например Serial,begin() или Serial1.begin не всегда приемлемо.

Вот это мне кажется не совсем правильным. Это придает вашим разработкам тупиковость, в том смысле, что никто кроме Вас, после Вас не сможет распутать этот клубок. Слишком уж все концы спрятаны и запутаны. Как идею и концепцию может кто то и подхватит, а вот так чтобы взять наработки и двигать дальше, сильно сомневаюсь.

xSemaphoreTake(mutex, portMAX_DELAY)
означает захват порта UART0 ?

Означает захват мьютекса (флага, эстафетной палочки). А вот xSemaphoreGive(mutex) - это его возврат, но не конкретно кому то, а просто освобождение. Поэтому есть нюансы. Задача может выполняться только при захвате мьютекса. Мьютексов может быть много, но для определенной группы задач, он один. И он же сразу может быть захвачен той же задачей которая его только что вернула, поэтому в конце таймаут на запрет этого захвата.

Отправлено спустя 6 минут 41 секунду:
portMAX_DELAY это максимальное время удержания мьютекса (до упора, пока задача не выполнится), можно установить актуальное время, тогда мьютекс будет отдан по истечении этого времени и не важно выполнилась ли задача до конца или нет. Ну это что то типа функции прерывания с таймингом.
Задачи не участвующие в "дележке" мьютекса, выполняются независимо.

[ecoins]

Это очень похвально, но складывается такое впечатление, что чем дальше идет развитие, тем сложней это делать. Одни в лес, другие по дрова. Вроде одно и тоже, а каждый вносит свои оттенки.

Это и так, и не совсем.
Мы ведь говорим об контроллерах под Arduino IDE?
А за последние год-два все ключевые производители (ST, RaspBerry) "застолбили" свое присутствие под Arduino , и это присутствие активно поддерживается.
Видимо сказался ошеломляющий успех контроллеров ESP(Китай).
Контроллеры AVR уже лежали в основе Arduino IDE.

По всей видимости не существует "мощного" комитета под Arduino IDE, который бы настаивал на стандартизации подходов.
Да и само развитие среды Arduino IDE идет не быстро.
Но состояние дел в любой момент может и измениться в благоприятную сторону - рынок много определяет, а Ардуинщиков становится все больше и больше, новых статей о якобы "убогости" Arduino вроде перестали появляться.

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

Вот это мне кажется не совсем правильным. Это придает вашим разработкам тупиковость, в том смысле, что никто кроме Вас, после Вас не сможет распутать этот клубок. Слишком уж все концы спрятаны и запутаны. Как идею и концепцию может кто то и подхватит, а вот так чтобы взять наработки и двигать дальше, сильно сомневаюсь.

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

Означает захват мьютекса (флага, эстафетной палочки).

Понятно. Такая реализация означает, что если какой-нибудь "хулиган" в какой-то новой библиотеке
применит Serial.print(), то могут возникнуть конфликты.

[Dryundel]

Понятно. Такая реализация означает, что если какой-нибудь "хулиган" в какой-то новой библиотеке
применит Serial.print(), то могут возникнуть конфликты.

Ну такое хулиганство в основном считаю кощунством. А Вы к стати этим грешите и вместо C++ создаете свой язык программирования. У Вас же все Serial.print() в библиотеке. Это во первых.
А во вторых, такие конфликты могут быть во многоядерных контроллерах и то там RTOS это как то учитывает. Если же камень с одним ядром, то вряд ли. Настоящей многопоточности в RISC не существует. Однако бесконтрольный вывод Serial.print() может оказаться проблемой не только для RTOS.

[artemka19]

Но состояние дел в любой момент может и измениться в благоприятную сторону

неа)))
они с 2015 не смогли/не захотели устранить баг
с длиной переменной примерно в 4кб.

причем в в platformio нет такого бага.

Отправлено спустя 2 минуты 48 секунд:
и как бы и не проблема вовсе в блоках писать код, который platformio проглатывает.....но проблема в том что многие штатные функции в флпрог нам не подвластны к редактированию из под флпрог...

Отправлено спустя 6 минут 16 секунд:

artemka19, ну вот как то так.
Смена скорости Serial каждые 5 сек. Обсуждаем дальше

интересно конечно.
А 5сек - это обязательно нужен тайминг? по флагу не получилось реализовать?

Отправлено спустя 3 минуты 52 секунды:

они с 2015 не смогли/не захотели устранить баг
с длиной переменной примерно в 4кб

даже больше: команда arduino ide выпустила arduino IDE PRO - но даже там, к сожалению, баг с ограничением длины стринг переменной не исправлен)

[Dryundel]

А 5сек - это обязательно нужен тайминг? по флагу не получилось реализовать?

Что значит не получилось? Все получилось и именно по флагу, точней по мьютексу. В чем проблема то?
У Вас есть другой вариант? Давайте посмотрим.

[artemka19]

. В чем проблема то?

смутило "...раз в 5сек..."
Если это не жесткий минимум, то весьма перспективные новости

[Dryundel]

смутило "...раз в 5сек..."
Если это не жесткий минимум, то весьма перспективные новости

Да нет же. Можно и больше. Вот три разных скорости чередующиеся каждые 20 сек.

3_Task_AVR_FreeRTOS_SpeedSerial_3.ino

(2.36 КБ) 28 скачиваний

.
Ну и всё те же три разных блинка (на трех пинах) с выводом их состояний в Serial на разных скоростях.

[ecoins]

Ну такое хулиганство в основном считаю кощунством. А Вы к стати этим грешите и вместо C++ создаете свой язык программирования. У Вас же все Serial.print() в библиотеке. Это во первых

В основном используется Serial.write() буферированный вывод с контролем заполнения буфера.
И напрямую эта функция не используется, только через библиотечные функции.
Функция Serial.print() введена исключительно из-за RaspBerry PI Pico и как временная мера...

Однако бесконтрольный вывод Serial.print() может оказаться проблемой не только для RTOS.

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

[Dryundel]

преодолеть эти особенности работы с контроллерами просто через FreRTOS не лучший путь

Самого лучшего пути не существует. )))

проект усложняется

С использованием диспетчера задач от ecoins проект, тоже усложняется и вы даже не представляете на сколько для новичка. )))
Хотя FreeRTOS в целом это еще более сложная структура соглашусь. Что на раз ее не возьмешь, это тоже факт.

работает медленнее

С этим категорически не согласен. Вот просто в корне.

потребляет больше ресуров

Что есть то есть. Любая операционка, даже такая миниатюрная требует ресурсов. Ваш диспетчер задач с прочими прелестями тоже ведь не из пустоты соткан.

и пр....

Аргумент не принят.

Чем больше вникаю во FreeRTOS, тем менее вероятным мне кажется внедрение ее в FLProg. Очень много того, что невозможно объединить в принципе. Однако там есть очень даже интересные механизмы, с которыми Вам следовало бы получше ознакомиться и что то позаимствовать.

[ecoins]

Что есть то есть. Любая операционка, даже такая миниатюрная требует ресурсов. Ваш диспетчер задач с прочими прелестями тоже ведь не из пустоты соткан.

Ну очень и очень оптимизирован -компактный и простой, почти как "утюг", и быстрый.
Если посмотрите код, убедитесь.
Между прочем результат более чем 2-х летней оптимизации с использованием логического анализатора.

Чем больше вникаю во FreeRTOS, тем менее вероятным мне кажется внедрение ее в FLProg. Очень много того, что невозможно объединить в принципе. Однако там есть очень даже интересные механизмы, с которыми Вам следовало бы получше ознакомиться и что то позаимствовать.

В упрощенном виде, например только планирования задач, в некоторых случаях воспользоваться можно, хотя можно сделать и проще, например как в библиотеке "Ticker.h"

FLProg имеет много общего с классическими PLC(ПЛК).
artemka19 уже обращал внимание что FreeRTOS в подобных системах не прижился.
Подтверждаю, и на то есть ряд причин, с частью которых Вы уже столкнулись.
А вот чего еще нет в ПЛК, так это "Диспетчер задач" - и здесь FLProg в большом выигрыше. И еще по целому ряду причин...