Многозадачность на ардуино? Реально ли в FlProg?

[ElectroMechaniC]

Привет соратники! Кто что слышал за многозажачность на ардуино? Вообще реальнпя ли вещь? Можно ли реализовать средствами FLP? Стоит просить сергея реализовать блок? Или сами накидаем?
Вот ссыль на новость!
http://pccar.ru/showthread.php?t=25825

[Anydy]

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

[pan]

новость? вряд ли

http://nuttx.org/

http://we.easyelectronics.ru/os-rtos/ur ... v-avr.html

http://www.cyberforum.ru/microcontrolle ... 58081.html

[Александр_Светлый]

виндоус такая многозадачная зависнет...

В этом как раз многозадачность Виндовс и кроется, она может работать и тупить одновременно!

[kalobyte]

3 лупа по таймеру переключать - это все равно что человку сломать ноги, дать ему костыли и вместо резиновых наконечников приделать туда колесики
под мк есть оси реального времени типа freertos
только для нее придется флпрог переписать с нуля вместе со всеми модулями

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

[ElectroMechaniC]

УГУ!!! Ясно! Под наши задачи не проканает )))

[ussrtk]

Ну вот прошло немного времени и такое впечатление,что под ESP32 многозадачность может стать реальностью: теперь не просто переключаемся по таймеру - теперь можем запускать задачу на втором ядре! по умолчанию IDE все размещает на ядре 0
А давайте заставим хоть что то выполняться на ядре 1?

[Nikan]

.

[ussrtk]

А давайте заставим хоть что то выполняться на ядре 1?

а ничего, что там вай фай с блютусом?

Я думаю, что именно из-за них НАДО включать многозадачность.

[Nikan]

.

[ussrtk]

Я думаю, что именно из-за них НАДО включать многозадачность.

мне сдается вы путаете теплое с мягким - о умолчанию в ESP32 CORE_0 отдается под обслуживание радиоканала (WiFi) и самого контроллера, а CORE_1 - под выполнение скетча ардуино. То есть "обычные" скетчи будут выполняться всегда на CORE_1,
заставив работать 0 ядро получите те де траблы что и 8266

Может и так. Но что вы скажете, прочитав и, самое важное, проверив этот материал "ESP32:Примеры/Создание задач для использования обоих ядер ESP32"
И заметьте, я не настроен с вами тягаться в мастерстве сарказма и "не предлагать не смешивать не смешиваемое". Я предлагаю оперировать фактами.
P.s. Все таки мягкое от теплого я отличаю. Другое дело - не верны данные в рассматриваемой статье: но я точно знаю, что у меня скетч из статьи скомпилировался. Сегодня хотел его исследовать и поэтому поднял ворс. Надеясь на понимание.

[Ingwar]

Пару месяцев назад пробовал этот пример. Пусть не на Си, но работает.

[Nikan]

.

[ussrtk]

P.s. Все таки мягкое от теплого я отличаю. Другое дело - не верны данные в рассматриваемой статье: но я точно знаю, что у меня скетч из статьи скомпилировался. Сегодня хотел его исследовать и поэтому поднял ворс. Надеясь на понимание.

а чего тут понимать, хочется страдать мазохизмом - так в путь

ход мыслей понятен.

[Anydy]

Все верно, на ESP8266 сколько проблем было что одно ядро обслуживает и Wifi и скетч -- постоянные зависоны, на ESP32 стало полегче -- скетч теперь работает вне зависимости от состояния Wifi --- а вы хотите вернуться в прошлое и иметь опять проблемы?

[ussrtk]

Все верно, на ESP8266 сколько проблем было что одно ядро обслуживает и Wifi и скетч -- постоянные зависоны, на ESP32 стало полегче -- скетч теперь работает вне зависимости от состояния Wifi --- а вы хотите вернуться в прошлое и иметь опять проблемы?

Нет, проблем не хочу. И вернуться не хочу. Я о другом: ранее и теперь из-за задержек цикла при обращения к сети, модeли ESP опасно использовать тогда, когда нужно отреагировать на скоростной сигнал. Например, срабатывание аварийного конечника хода - если его пропустить на пол секунды, то возможны разрушения.
В ESP32 включение слежения за аварийным конечником в ядро 0 никак его не ухудшит его работу! А аварийную ситуацию не проспит. Это во-первых.
Во-вторых: неужели не интересно в рамках FlProg заставить работать ядро 0 в собственных интересах, хотя бы и в ограниченном функционале?
И в третьих: да, в 8266 были коллизии работы радимодуля и основного скетча. Но там мы ничего сделать не могли. А теперь, освоив генерацию отдельного потока в отдельном ядре можно попробовать нагрузить его в разумных пределах.

Я понял так, что это никому здесь не нужно. Ок. Я больше не стану беспокоить. Но ответить был должен.

З.Ы, Я уже в рамках FlProg запускаю задачу на ядре 0. И особых разрушений работоспособности не вижу.

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

Пару месяцев назад пробовал этот пример. Пусть не на Си, но работает.

НЕ только на СИ - в ФлПрог работает.
Тмм мы имеем повторение идеи, причем простейшей. А здесь - управляемый ПБ. Вес так просто, но реализуемо и это главное.

[Anydy]

Во-вторых: неужели не интересно в рамках FlProg заставить работать ядро 0 в собственных интересах, хотя бы и в ограниченном функционале?

Я думаю даже пробовать не нужно......

[ussrtk]

Во-вторых: неужели не интересно в рамках FlProg заставить работать ядро 0 в собственных интересах, хотя бы и в ограниченном функционале?

Я думаю даже пробовать не нужно......

Спасибо, я понял.
А как вы считаете - все эти эксперименты в интрнете с потоками и ядрами на ESP32 - чепуха?

[Anydy]

Спасибо, я понял.
А как вы считаете - все эти эксперименты в интрнете с потоками и ядрами на ESP32 - чепуха?

Точно не знаю, но пусть будет лечше так -- 1 ядро занимается wifi, 2 ядро занимается скетчем....никто друг другу не мешает.....я вообще говорил что нужно иметь два МК в проекте... --- один выполняет строго определенные функции ...например общение с внешним миром .... а второй уже отрабатывает вашу программу!

[Nikan]

.