Arduino.ru

то, что на исполнение кода любой сложности требуется время - это тебя не смущает, а наличие делаев - смущает?

спирт же испаряется надо ж мгновенно :)))))

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

Как же приятно. Задал конкретный, ненубский вопрос. Получил 3 коммента - один почти оскорбительный, второй "остроумный", третий не о том.
Помогли просто шикарно :(

Попробую еще раз. Вопрос адресован к тем, кто писал в среде FreeRTOS и понимает о чем речь. Мне не нужно, чтобы разные задачи разделяли перефирию. Если у меня 2 задачи обращаются к одной перефирии, то я в более приоритетной и/или первой выставлю семафор, что она занята и сниму когда освободится. Тут я вообще проблем не вижу.
Более того, как я себе представляю использование delay вместо vTaskDelay может и не вызвать проблем, поскольку квантование времени реализовано в диспетчере FreeRTOS через прерывание и задача и с delay должна прерваться, но как там что в деталях... Просто не хотелось бы набивать шишки методом проб и ошибок...

пля. ещё одна девочка в марлевых трусиках обидчивая - с чего ты решила, что тебе нужна помощь?

Если есть в мире Ардуино "философский камень", то это FreeRTOS или подобное. И вместо что бы включать голову, они и надеются на такую волшебную палочку. Страшен не delay. Страшно то что MK занят выполнением только delay и больше ничем.

Мне было бы интересным посмотреть как вы семафором разрулите параллельные задачи, работающие по SPI с использованием ардуино класса SPI. Представьте, что у вас есть шилд Ethernet и вы хотите параллельно работать с карточкой на нём. Переписывать SPI нельзя, обойдитесь семафором.

А с delay я вообще никаких проблем не вижу, задержка заменяется внутренней реализацией из состава ОС.

Вот вообще не понятно о чем написано. delay прекрасно прерывается на обработку прерываний. Достаточно или недостаточно этого диспетчеру FreeRTOS - я не знаю. Поскольку мне неохота изучать ни реализацию delay в ардуино, ни  реализацию диспетчера FreeRTOS - я спросил здесь. Ответа, я судя по всему здесь не получу - спрошу у  автора на гитхабе (английский знаю слабо - мне это гораздо сложнее). Если и там не получу - займусь тогда уж изучением. Со знанием С/С++ у меня проблем нет, совсем не новичок.

С эзернет-шилдом - не работал, там есть нога прерывания, кроме SPI - ног и нет буфера? В чем проблема то?

У меня к SPI в одном проекте подключены дисплей и карточка. В задаче дисплей проверяется семафор занятости SPI пока не освободится. Как освободится - выставляю его и пишу данные через класс ардуино. Пока не допишу - семафор не освобождаю.
В задаче карточка - аналогично.

В каком месте произойдет коллизия и какая? Данные надо вывести "прямо сейчас"? Ну пусть задача формирующая данные помещает их в буфер.

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

А я вижу проблему замены delay на "задержка заменяется внутренней реализацией из состава ОС" и потому спрашиваю - есть случаи когда можно этого не делать и есть ли когда обязательно переписывать класс?

Как, хотяб теоретически, возможно не тормозить другие процессы но разделять (квантовать) время между ними?!  Если есть 16*1000000 тактов проца в секунду и кому то не хватит - то тормозится будет.

По теме - ежели в тасках делеи, то разделит время поровну (делей или не делей оно ж не знает чё там), а если  "задержка заменяется внутренней реализацией из состава ОС", то её вызов будет восприниматся как досрочное завершение кванта. Значить разделение времени пройдет разумней.

Из вышеизложеного - классы переписывать не обязательно. Оно всеравно не поможет. 

Про "философский камень" вам верно написали. Вы ждете что RTOS за Вас разделит самый ценный ресурс - время, и все Ваши таски будут работать незамечая друг друга. Так вот хрен. Она сожрет память и  сделает нестабильными все временные интервалы что скажется на работе переферии. Скорей всего тот же ds18b20  будет читатся через раз. А время она разделит чисто топорно, прерывая таски не в логически обоснованых местах (минимум контекста, не формируется интервал, не держим переферию), а как попало. Частично это поборется синхронизацией, и внутри либок тоже ;) И на неё Вы потратите именно тот выиграш времени разработки, который дает RTOS.

ПС.  Бросайте затею с RTOS, лучше к нам заходите - http://arduino.ru/forum/otvlechennye-temy/v-pomoshch-samogonshchiku ;)

Проблема не только в том, что вы возвращаетесь к однопоточности. Вам ещё нужно каждый раз вручную переконфигурировать интерфейс. Т.е., допустим, у вас есть два устройства на SPI, но работают они на разных скоростях. Вы должны перед использованием каждый раз настроить SPI (chip select тот же), т.е. сам класс не содержит в себе защиту насчёт использования "параллельно". Точно также обёртка над каким-то другим интерфейсом может содержать какие-то конфигурационные настройки, которые не предполагают совместное использование. Т.е. потоки могут обращаться к одной и той же памяти внутри класса-обёртки, а вы знать об этом не знаете, пока глюки не начнутся.

Я, примеру, для вывода информации в терминал написал свой класс, завёл там мьютекс и с помощью критической секции сделал аналог lock'а на время вывода в терминал с одного потока. Точно также, как я вижу, нужно переписать другие классы Arduino Framework'а, чтобы не гадать потом что они понаизменяли в регистрах мк или своих внутренних областях памяти.

Я не использовал FreeRTOS, а использовал scmRTOS. Подошёл к задаче разделения SPI (Ethernet + sd-карта). Решил, что лучше будет адаптировать низкоуровневые классы, дополнив их элементами синхронизации, чем как-то использовать уже имеющиеся. Оно может и будет работать, но очень прожорливое для моей Arduino Mega2560.

Страшно представить что будет, если, к примеру, одна задача будет читать файл, а другая - писать, если это реализовывать стандартной библиотекой. Или другой пример: реализация нескольких протоколов для работы по сети, работающих каждый в своём потоке. У меня есть большие сомнения, что это заработает без переделки классов Arduino Framework'а.

ну, представляю себе, что будет - прочитает, затем запишет.

*это ужасно. 

**та, "да" - одна читать, вторая - писать, третья - бояться. и, всё это одновременно - трёхядерный дуино, мля.

//Вам ещё нужно каждый раз вручную переконфигурировать интерфейс. Т.е., допустим, у вас есть два устройства на SPI, но работают они на разных скоростях. 

Ну это по любому прийдется, сколько бы потоков не было.

А вот доступ к spi из нескольких потоков - да, это как раз то, что потребует синхронизации. И все остальные переферии аналогично. Самый неприятный из них ИМХО, это экран. 

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

Пробовал я FreeRTOS на нане. Помигал диодиком. Вывел на экран ПРИВЕТ МИР. Здесь память кончилась. Ничего больше из задач добавить не получилось.  Ушёл на STM32. Там получилось поднять 6 задач. В том числе сеть и CD карту и тачь. Меги у меня нет. Про неё ничего не скажу, но на более мелких FreeRTOS это игрушка. Отсутствие приоритетов прерываний сильно затрудняет применение RTOS.  

))) Да! так оно выглядит. А ведь без RTOS на той же нано такой контроллер подымается - ух!

Во во. Без РТОС. Можно и так всё нормально расписать.

Дураки RTOS писали. Точно. ESP8266 SDK вон на RTOS написан. Просто потому, что в Espressif Systems лошары и не знают, что всё нормально и так расписать можно.

Пойду отсюда, пока не послали :(

дураки пытаются впихнуть невпихуемое в квадратное

Зачем глупость говоришь, дарагой?

RTOS - очень хорошая штука, но для 328ого не подходит. Ресурсов на нем нет для ОС.

Ты почитай на гитхабе - это просто развлекательная адаптация FreeRTOS для Ардуино.

Для души человек писал. Совсем не для реализации систем управления.

ESP8266 и AtMega 328p не нужно сравнивать.

---------------

Еще раз, для закрепления информации: понятно ли, что FreeRTOS - совсем не причем и никто ее не ругает? На СТМ32 - вполне уместно использовать, не на любом, конечно.

Многим, ответившим Вам людям, непонятна Ваша идея - использовать игрушечную адаптацию FreeRTOS на легкие АВР контроллеры для большой задачи.

Ардуино FreeRTOS 9.0 и просто FreeRTOS 9.0 это очень разные вещи. Берите STM32F103RET6, он на Али 427 р. стоит и не "голый", а на девелопмент борде, то есть как ардуино. 72 МГц, 512К программы и 64К ОЗУ, приоритет прерываний, атомарные операции. Вот тут FreeRTOS - вполне уместна будет.

------

На АВР ту же задачу можно решить так же успешно, но без "всего это тюнинга".

Тут давно сражаются две шлолы: кто-то любит решать задачи минимальными средствами - те выбирают прекрасно документированный и надежный АВР.

Кто-то любит иметь тройной запас по ресурсам, типа: "пусть воробьи боятся - у меня пушка!", для таких есть СТМ и его экосистема.

Только не нужно скрещивать "ежа и ужа". Не нужна RTOS на АтМеге.

То, что у контроллера ESP8266 ОЗУ 128Кб, а у 328р всего 2Кб Вы не заметили?

Эти два подхода, не совсем две школы. Это просто любительские и профессиональные разработки. Обе имеют право на жизнь. Просто требования разные. Для себя я контроллер самогонного сделал на 328р, а на заказ бы делал скорей всего не на нем. Наверно на чем-то из OrangePi.

Я за год выгоняю около 2000 л (примерно по 50л бочке в неделю, но с "паузами")  браги и, соответственно, выпиваю 400 л самогона (не один,  с любимой супругой ;) ). Пока не стал себе автоматику делать. Считаю, что уйдет "теплая ламповость" домашнего самогона!

Кстати,Логик. Я слышал, что у Вас, так же как и в Белоруссии, нет свободы гнать? Типа штрафуют? Правда, аль брешуть?

У нас, в РФ, гони хоть цистернами, только продавать нельзя.

Брешут. Гнать можна, продавать нельзя. Есть только вопросы по пожарке и т.д. если в доме. Но о проблемах с властью по данному вопросу я никогда не слышал.

"теплая ламповость" - спасибо, поржал.

Вот я прям стесняюсь спросить где хоть раз я писал об атмеге 328? Контроллер у меня собран на 2560. Его ресурсы вполне сопоставимы с ESP не считая флеша. 
Кроме того, я встречал не один проект, написанный с FreeRTOS и подобной даже на 328. 

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

А сэм у нас гонится в "клубном варианте" до 120л браги в неделю, в 2 гона и с промежуточной очисткой отбора в фильтрационной колонне. Аппарата версия уже 3+, контроллер тоже сейчас 3 версия будет. Стабильность продукта на выходе забарывает в 0 любую теплую ламповость. Вот сейчас еще котроллер к фильтрационной колонне прикрутить и можно в 2 аппарата запускать...

Ну и STM32F1 у меня есть, STM32F4 заказал. Человек я ленивый, да и времени у меня не так много: залил STduino IDE загрузчик помигал светодиодом, убедился, что I2C дисплей как обещали не работает, а код занимает в 2 раза больше, чем для AVR и отложил. Duinы всякие не для STM. Надо курить тонны мануалов. Нет у меня таких задач, с которыми бы не справился бы 2560 и стоило бы убить недели/месяцы жизни на изучение STM. Но может появятся, потому и заказал F4 про запас.

Ну вот видите! Вы даже не удосужились поведать о контролере, а еще чегото хотите?! Излагайте четче.

я запретил.

*и, таки я не понял, получается - на амтега8 балалайка не взлетит потому, что ТС о ней не написал?

Да нормально вы получили, только признавать не хотите

Это типа углевание? У Вас относительно крупное производство, можите и сервер поставить с АСУТП.

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

FreeRTOS видел, не пользовал ибо поделка только "на поиграться". Делал что-то подобное свое. Многозадачность легко разруливается на watchdog таймере Мега2560 или на нулевом таймере, вставкой простого хука (тут есть темы за это). сторонние библиотеки - да, приходится перепиливать все, без исключений. А частично НАДО перепиливать и стандартные, в частности работу с I2C, Serial .. в последнем используется операция взятия остатка для определения выхода за границу буфера, которой нет в аппаратной реализации, что приводит к соответствующим тормозам (это помимо чудесного наследия классов от Stream.h) .. есть накладки при работе с Сериал, приводящие к вывалу передачи .. ну и вообще. Начинаете править библиотеку, устраняя оттуда ту или иную несовместимость .. легко приходите к понимаю что проще выкинуть и написать свое. Благо дело, вся периферия у Меги - проста и наглядна.

Здесь есть мой пример использования scmRTOS с двумя задачами. Одна из них реализует примитивный telnet сервер. Только собираю я всё это дело отдельно от Arduino IDE при помощи специального makefile, хотя можно собрать и там. В принципе работает, но до ума не доведено пока. Здесь используется ethernet клиент из Arduino Framework'а. Я всё собираюсь выкинуть его и работать с сокетами напрямую. Времени не хватает.

Некоторые описания доступны в папке doc.

2uni т.е. использовать scmRTOS можно и при этом библиотеки из Arduino Framework'а переписывать не надо?
или все тоже, что написал Arhat109-2?
 

Serial я выкинул, т.к. совершенно бестолковая прожорливая вещь. Вместо него написал, как видно, свой простой логгер, который, кстати, дату/время ещё выводит с точностью до мсек (без rtc конечно). Ethernet оставил, т.к. его не так просто выкинуть. Дело в том, что такой код нужно уже отлаживать и так просто править его нельзя, нужно опыт большой иметь, чтобы без отладчика такое править. Поэтому задаче выделил побольше места в ОЗУ и тестировал в работе на железе. Код тоже смотрел конечно. Позже хочу напрямую, как говорил, с сокетами работать.

Если вы уверены, что код класса будет нормально работать в своём изолированном пространстве (учитывая состояния регистров мк при параллельной работе) и места в ОЗУ хватает, то стандартные классы можно использовать. Единственное, нужно добавить блокировки типа CLock, как у меня, на общие глобальные экземпляры. Логгер-то у меня общий, поэтому вывод в нём обёрнут при помощи lock/unlock.

В общем, если задача не шибко сложная и вас устроит прожорливость и корявость кода Arduino Framework'а, то использовать его можно, но с умом.

Меня, к примеру, также не устраивала работа со строками во флеш. Я добавил своего функционала.

Так выглядит отладка проекта Telnet Server: https://youtu.be/kFRJNTqen2c

Типовой BLINK на delay() и чтение аналогового порта под freeRTOS взятые отсюда работают на ура

#include <Arduino_FreeRTOS.h>

// Определим две задачи для алгоритмов Blink и AnalogRead:
void TaskBlink( void *pvParameters );
void TaskAnalogRead( void *pvParameters );

// Функция setup запустится один раз, когда Вы нажмете кнопку
// сброса или подадите питание на плату.
void setup() {

   // Теперь создадим две задачи, чтобы они работали независимо
   // друг от друга:
   xTaskCreate(
      TaskBlink
      ,  (const portCHAR *)"Blink"  // Это просто любое имя, удобное
                                    // для чтения человеком.
      ,  128                        // Размер стека задачи
      ,  NULL
      ,  2                          // Приоритет задачи.
      ,  NULL );

   xTaskCreate(
      TaskAnalogRead
      ,  (const portCHAR *) "AnalogRead"
      ,  128                        // Этот размер стека может быть проверен
                                    // и подстроен путем чтения Highwater.
      ,  NULL
      ,  1                          // Приоритет задачи.
      ,  NULL );

   // Теперь автоматически и неявно для пользователя запустится scheduler,
   // который возьмет на себя управление планированием запуска отдельных задач.
}

void loop()
{
   // Эта функция пуста. Вся полезная работа теперь осуществляется
   // в запущенных задачах (Tasks). Эти задачи реализованы функциями
   // TaskBlink и TaskAnalogRead.
}

/*--------------------------------------------------*/
/*---------------------- Tasks ---------------------*/
/*--------------------------------------------------*/

void TaskBlink(void *pvParameters)
{
  (void) pvParameters;

   // Инициализация цифрового вывода 13 в режиме выхода.
   pinMode(13, OUTPUT);

   for (;;) // A Task shall never return or exit.
   {
      digitalWrite(13, HIGH);    // включение светодиода LED
      vTaskDelay( 1000 / portTICK_PERIOD_MS ); // ожидание в 1 секунду
      digitalWrite(13, LOW);     // выключение светодиода LED
      vTaskDelay( 1000 / portTICK_PERIOD_MS ); // ожидание в 1 секунду
   }
}

void TaskAnalogRead(void *pvParameters)
{
  (void) pvParameters;

   // Инициализация последовательного обмена данными на скорости
   // 9600 бит в секунду:
   Serial.begin(9600);

   for (;;)
   {
      // Чтение входа аналогового вывода 0:
      int sensorValue = analogRead(A0);
      // Вывод на печать прочитанного значения:
      Serial.println(sensorValue);
      // Задержка в 1 тик (15 мс) между чтениями, для стабильности:
      vTaskDelay(1);
   }
}