Диспетчер задач by Alex Gyver

[Phazz]

Phazz, в тесте, что проводил Rovki. вплоть до обрыва соединения Wi-Fi, как он пишет.

Это было в первой версии блока. Благодаря тесту Анатолия баг пофиксил. Так что проблем теперь нет.

[Rovki]

Phazz, в тесте, что проводил Rovki. вплоть до обрыва соединения Wi-Fi, как он пишет.

Это было в первой версии блока. Благодаря тесту Анатолия баг пофиксил. Так что проблем теперь нет.

Да ,вайфай не рвется , но есть фичи с таймерами ,генераторами итп. Требует скрупулезного подхода к разбиению на задачи

[krom23]

читал что только на esp32 rtos по умолчанию

На всех, как я уже говорил, наличие любой RTOS является обязательным условием для работы Wi-Fi, а отсюда следует, что при установке ещё одной RTOS даже "костыльной"(как говорит сам Gyver) может привести к конфликтам.

[Rovki]

читал что только на esp32 rtos по умолчанию

На всех, как я уже говорил, наличие любой RTOS является обязательным условием для работы Wi-Fi, а отсюда следует, что при установке ещё одной RTOS даже "костыльной"(как говорит сам Gyver) может привести к конфликтам.

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

[artemka19]

наличие любой RTOS является обязательным условием для работы Wi-Fi

как я понял, важнее КАК реализовано общение с Rtos в разрезе ArduinoIDE - учитывая библиотеки с delay() - проще дистанцироваться от нее.

*интересно конечно было бы мнение Гайвера: он случаем не рекомендовал ли использовать Другой компилятор при использовании ГайверОС ?

[ecoins]

На всех, как я уже говорил, наличие любой RTOS является обязательным условием для работы Wi-Fi, а отсюда следует, что при установке ещё одной RTOS даже "костыльной"(как говорит сам Gyver) может привести к конфликтам.

Интересный взгляд - он как-то указывает на источник потенциальных проблем при увеличении проектов.
Сами по себе прерывания по таймеру в GyverOS не является чем-то разрушительным.
Напротив, в целом ряде случаев этот способ решения других непросто решаемых проблем, например управление шаговыми двигателями.
Но этот метод переключения задач может привести почти к гарантированным проблемам, если состав вызываемых задач не контролируется и может быть длительными по времени, например вывод через UART, стандартный дисплей, даже запись во float-Modbus регистры(очень тормозной процесс для AVR) и пр.
Особенно чувствителен обмен через Modbus-RTU в нынешней реализации в FLProg.

[artemka19]

[ref]ecoins[/ref],
оно так то все сходится (но лично я считал что это справедливо исключительно для есп32):
-есп32=rtos
-использование ардуиноIDE при работе с есп32=это лишь работа с некоей библиотекой RTOS, адаптированной под ардуино ide


*ну т.е. получается нужно все таки работать напрямую esp_sdk

[ecoins]

*ну т.е. получается нужно все таки работать напрямую esp_sdk

Мы выкладывали тяжелый тестовый пример на ESP32 -ModBus TCP, UART, 3-дисплея HD44780, много сенсоров и пр.
Работает без сбоев, 7 тыс. циклов loop() при включенном Wi-Fi.

[artemka19]

[ref]ecoins[/ref],
ардуино.ide разве позволяет напрямую работать с sdk?

[ecoins]

ecoins,
ардуино.ide разве позволяет напрямую работать с sdk?

Не знаю, хотя почему и нет.
Но мы sdk не использовали, только CORE для ESP32.

[artemka19]

[quote=ecoins post_id=117777 time=1663959801 user_id=923]
Но мы sdk не использовали, только CORE для ESP32
[/quote]
но из-под ардуино ide?

а это уже работа через "библиотеку" стороннюю получается

*я к тому что при такой работе (с библиотекой) могут быть непредсказуемые результаты)))

[size=85][color=green]Отправлено спустя 5 минут 18 секунд:[/color][/size]
[quote=artemka19 post_id=117778 time=1663959941 user_id=13310]получается[/quote]
*выясняется

[artemka19]

**я не с претензиями ни в коем случае - но картина очень интересная вырисовывается: какие бы мы блоки ни делали - весь наш код компилируется через призму "Библиотеки" поддержки плат в АрдуиноIDE

Отправлено спустя 13 минут 35 секунд:
[ref]ecoins[/ref],
случайно нет связи с
Иваном Грохотковым (разработчик поддержки Arduino для ESP8266 + он же запустил doom на esp32 еще в 2016)?

[ecoins]

но из-под ардуино ide?

а это уже работа через "библиотеку" стороннюю получается

*я к тому что при такой работе (с библиотекой) могут быть непредсказуемые результаты)))

**я не с претензиями ни в коем случае - но картина очень интересная вырисовывается: какие бы мы блоки ни делали - весь наш код компилируется через призму "Библиотеки" поддержки плат в АрдуиноIDE

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

[Phazz]

при установке ещё одной RTOS

а с чего вы взяли что GyverOS это RTOS? Тут реатайм даже не пахнет.

[ecoins]

ecoins,
случайно нет связи с
Иваном Грохотковым (разработчик поддержки Arduino для ESP8266 + он же запустил doom на esp32 еще в 2016)?

Помню. А он вроде как-то с "радаров" пропал.

[artemka19]

Но иначе другая крайность - писать в машинных кодах

насколько я понимаю - sdk это еще достаточно высокий уровень кода)
Ну т.е. никак не машинный

[ecoins]

насколько я понимаю - sdk это еще достаточно высокий уровень кода)
Ну т.е. никак не машинный

https://docs.espressif.com/projects/esp ... index.html
Это достаточно высокий уровень кода с одной стороны.
С другой стороны через функции реализуется аппаратные возможности чипа.
Собственно это относится и к ядру CORE IDE, в основе которого собственно и используются функции API ESP32.
Также обстоит дело и с другими чипами.

[Alexanders]

Попробовал GyverOS 1.2.flp из первого поста. В отличии от описания на гитхабе, не вижу многих функций диспетчера и бенчмарка для него.
Это так или я чего-то недопонимаю?

[Phazz]

[ref]Alexanders[/ref], каких функций не хватает? Я реализовал только основной функционал. Если что-то еще нужно, добавлю.

[Alexanders]

Бенчмарк времени задачи и загрузки процессора, для отладки.
Остановка задачи.