FlProg

Как мне кажется достаточно интересный ролик. Сравнение Esp32, Stm32 и др. в математике с float! Кто быстрей. Ссылка на канал на Rutube.ru Заметки Ардуинщика

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

lfgjikjjyj писал(а): 12 апр 2025, 10:33 а если на есп активировать вайфай то она становилась слабее блупилки

а если блупилку заставить обрабатывать вайфай - то она еще хуже есп будет)))

kilemch5 писал(а): 12 апр 2025, 11:49

lfgjikjjyj писал(а): 12 апр 2025, 10:33 а если на есп активировать вайфай то она становилась слабее блупилки

а если блупилку заставить обрабатывать вайфай - то она еще хуже есп будет)))

Сарказм тут не работает Вы должны прекрасно понимать что у ESP на wi-fi завязаны отдельное ядро а второе ядро обрабатывает код собственно два ядра там не работают против одного ядра СТМ наверняка видео об этом говорится

montirovka писал(а): 12 апр 2025, 10:00 Как мне кажется достаточно интересный ролик. Сравнение Esp32, Stm32 и др. в математике с float! Кто быстрей.
2025-04-12_09-54-33.png

Ссылка на канал на Rutube.ru Заметки Ардуинщика

Это ролик искажает действительность.
С точки зрений быстродействия ESP32 худший выбор - это связано с архитектурой процессора и видимо не лучшей реализацией софта.
Мы проводили исследования на средне нагруженных тестах (много сенсоров, расширителей входов/выходов и прочее).
В некоторых случаях даже MGA2560(8 бит,16мГц) оказывалась быстрее.
Результаты выкладывали на форуме.

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

ecoins писал(а): 12 апр 2025, 13:43

montirovka писал(а): 12 апр 2025, 10:00 Как мне кажется достаточно интересный ролик. Сравнение Esp32, Stm32 и др. в математике с float! Кто быстрей.
2025-04-12_09-54-33.png

Ссылка на канал на Rutube.ru Заметки Ардуинщика

Это ролик искажает действительность.
С точки зрений быстродействия ESP32 худший выбор - это связано с архитектурой процессора и видимо не лучшей реализацией софта.
Мы проводили исследования на средне нагруженных тестах (много сенсоров, расширителей входов/выходов и прочее).
В некоторых случаях даже MGA2560(8 бит,16мГц) оказывалась быстрее.
Результаты выкладывали на форуме.

Очень сомневаюсь что в равных условиях 2560 сможет хоть как-то противостоять esp32. Есть примеры отличной платы на есп32 которая управляет станком чпу (хоть и маленьким) с тремя шаговыми двигателями и параллельно работой с вэбинтерфейсом.

Phazz писал(а): 12 апр 2025, 14:52 Очень сомневаюсь что в равных условиях 2560 сможет хоть как-то противостоять esp32. Есть примеры отличной платы на есп32 которая управляет станком чпу (хоть и маленьким) с тремя шаговыми двигателями и параллельно работой с вэбинтерфейсом.

Можно сомневаться, а можно провести исследования...
Многие 3D - принтеры делались именно на MEGA2560.
----------------------------------------------------------------------
viewtopic.php?p=123988#p123988 --------------
По контроллера с гарвардской архитектурой(AVR,STM32) быстродействие в целом пропорционально частоте процессора.
У ESP8266 и у ESP32 все гораздо хуже.
-----------
Проблема ESP в том, что у них программа хранится на внешнем по отношению к MCU FLASH и обмен реализуется через подкачку в область оперативной памяти вроде бы размером не более 64к.
На коротеньких и линейных программах все быстро, но чуть размер и алгоритм усложняется, резко падает быстродействия.
В таблице результат на небольшом тесте.
------------
Gyver провел сравнение на коротком тесте тяжелой операции с плавающей арифметикой.
И все в пользу ESP32 - и тест короткий, и чип работает с плавающей арифметикой.
И сделал вывод - RP2040 очень медленный процессор.
Уточняю: ESP32 - сам процессор 80мГц, RP2040-133 мгц.
В RP2040 обмен тоже реализуется через подкачку, но видимо реализовано гораздо лучше и падение скорости с ростом размера программы не сильно падает.
И у ESP32, и у RP2040 по два ядра. Но второе ядро в FLProg использовать просто - и на него можно повесить отдельные сложные операции, а вот у ESP32 второе ядро не очень получается использовать. Сейчас доступны чипы RP2350B - у них уже и встроенная плавающая арифметика, и пинов больше (корпус 80 пинов).
Ниже фото одного из наших последних проектов ----------
И комплексное сравнение ESP32 c RP2040,RP2350B и тем более с STM32F4,H5,H7 - ну это как сравнить "божий дар с яичницей".
--------
С уважением, ecoins.

Многие 3D - принтеры делались именно на MEGA2560

При этом могут держать сетевое соединение и обрабатывать вэбинтерфейс?

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

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

Я не знаю что содержалось в коде и отключили ли вы радиомодуль при этом. Но даже в вашем тесте 2560 не лучше. В общем есть вопросы к методикам. Как собственно и у Гайвера тоже.
А от куда информация про 80МГц?

В любом случае esp32 универсальная и не дорогая плата и она очень нужна для diy. А эти миллионы циклов мало кому нужны и esp32 покрывает очень большую часть задач.

Ну да вам циклы точно не нужны
А для тех кто занимается оптимизацией цикл - это самое первое На что надо обратить внимание и иметь под рукой
Короче говоря программист без замера цикла - это всё равно что Строитель без рулетки который будет вам на локтях на руках на пальцах показывать сколько чего и До куда

Будете как древний крестьянин когда они локтями всё измеряли

Phazz писал(а): 12 апр 2025, 16:22 При этом могут держать сетевое соединение и обрабатывать вэбинтерфейс?

В любом случае esp32 универсальная и не дорогая плата и она очень нужна для diy. А эти миллионы циклов мало кому нужны и esp32 покрывает очень большую часть задач.

Там ещё и олед дисплейчик прикручен и СД карта. И всё на одной ЕСПэхе.
з.ы.
А просто циклы - это лишь синтетика. Важны конкретные реальные реализации.
А соотношение цены/качество лучше чем у ЕСП на текущий момент вряд ли можно найти.

Phazz писал(а): 12 апр 2025, 16:22

Многие 3D - принтеры делались именно на MEGA2560

При этом могут держать сетевое соединение и обрабатывать вэбинтерфейс?

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

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

Я не знаю что содержалось в коде и отключили ли вы радиомодуль при этом. Но даже в вашем тесте 2560 не лучше. В общем есть вопросы к методикам. Как собственно и у Гайвера тоже.
А от куда информация про 80МГц?

В любом случае esp32 универсальная и не дорогая плата и она очень нужна для diy. А эти миллионы циклов мало кому нужны и esp32 покрывает очень большую часть задач.

1.Я не против ESP32.
2."При этом могут держать сетевое соединение и обрабатывать вэбинтерфейс?" - наверное могут. И хорошо бы если во время работы Wi-Fi не вмешивался в работу двигателей. Возможно что на каких-то участках движения WiFi блокируют, а при передвижении включают.
Эту тему я не исследовал, ЧПУ на ESP32 не встречал. Непосредственно на FLProg одновременная работа двигателей и Wi-Fi - возможно возникнут проблемы. А может и не возникнут... Но я бы такую конструкцию не решился бы делать.
3."Но даже в вашем тесте 2560 не лучше." - Поверьте на слово. При тесте большого объема (много сенсоров и расширителей важен объем и нелинейность алгоритма) ESP32 был медленнее Mega2560 и даже ESP8266! После получения первых результатов я сам удивился, много раз перепроверял и исследовал эту проблему больше года. Не уверен в абсолютной точности моих выводов, но в целом картину обрисовал и она похоже на реалтстичность.
4."В общем есть вопросы к методикам. Как собственно и у Гайвера тоже" - согласен. Но есть и откровенно провокационные методики. Еще один пример - проверять быстродействие по команде digitalWrite() - именно из команд работы с пинами на ESP32 долгое время были проблемы с DS1820,DHT22. Возможно что в новых версиях кое-что поправили в CORE, но не уверен.
5."Я не знаю что содержалось в коде и отключили ли вы радиомодуль при этом" - в приведенном тесте радиоканал не использовался.
6."А от куда информация про 80МГц?" После CPU 240 мГц стоит уточнение (WiFi,BT).
Ниже скорость FLASH 80мгц. Не может процессор работать намного быстрее, чем считываемые из памяти инструкции.
Часть ответственного кода можно разместить в оперативной памяти - будет быстрее.
Но в практике FLProg это редко используется.
7."А эти миллионы циклов мало кому нужны" - наверное кому-то и не нужны. Но часто сталкиваюсь с удивлением, почему-то в каком-то сочетании блоков и алгоритмов что-то "тормозит" или не работает....
8."покрывает очень большую часть задач" - действительно большую.
Но серьезные производители промышленных контроллеров в сторону ESP пока не смотрят.
Фирма ST выпускает чипы с радиоканалом (семейство WB,WL), делают это за счет двух разных процессоров.
В сторону WiFi на ядре пока не смотрят.
А технологические и конструкторские возможности у них существенно выше чем у ESP.
-----
С уважением, ecoins.

Кто назовет навскидку прикладные задачи, где требуется 100+ тыс циклов в секунду?
Пока что я ни тут, ни в ТГ канале не видел подобных проектов. Подавляющее число проектов - измерить температуру, поморгать лампочкой. Это можно делать и с сотней циклов в секунду. Что в целом подтверждает тысячи ПЛК со временем цикла не менее 1мс (а у многих и 10 мс достаточно).

Так же некорректно сравнение STM32 f/h 4/7 серий с ESP, и тем более с AVR. Они принципиально разные. Это как сравнивать КамАЗ и Оку/Жигули по гркзоподъемности.

Я не говорю что топовые СТМ не интересны и не нужны, но использовать их для условных ПЛК - как-то нерационально. И решать проблемы кривого и избыточного кода тупо производительностью МК - путь в никуда.
Гораздо интереснее раскрыть аппаратные возможности топовых МК. Там и много новых приложений можно реализовать.

slsl писал(а): 12 апр 2025, 17:21

Phazz писал(а): 12 апр 2025, 16:22 При этом могут держать сетевое соединение и обрабатывать вэбинтерфейс?

В любом случае esp32 универсальная и не дорогая плата и она очень нужна для diy. А эти миллионы циклов мало кому нужны и esp32 покрывает очень большую часть задач.

Там ещё и олед дисплейчик прикручен и СД карта. И всё на одной ЕСПэхе.
з.ы.
А просто циклы - это лишь синтетика. Важны конкретные реальные реализации.
А соотношение цены/качество лучше чем у ЕСП на текущий момент вряд ли можно найти.

Вы себя убеждаете собственными утверждениями - они могут сильно отличаться от реальности.

ecoins писал(а): 12 апр 2025, 17:31 Эту тему я не исследовал, ЧПУ на ESP32 не встречал. Непосредственно на FLProg одновременная работа двигателей и Wi-Fi - возможно возникнут проблемы. А может и не возникнут... Но я бы такую конструкцию не решился бы делать.

GRBL контроллер ЧПУ на ESP32.

После CPU 240 мГц стоит уточнение (WiFi,BT).

Вы ошибаетесь, 80МГц это скорость работы с памятью флэш (это влияет на скорость прошивки и работу с файловой системой).

Но часто сталкиваюсь с удивлением, почему-то в каком-то сочетании блоков и алгоритмов что-то "тормозит" или не работает....

Это как раз вопрос не к производительности а к оптимизации кода. Если кто-то вставит делэй, то все эти млн. превращаются в тыкву. А если всо нормально, то 100к это с большим избытком.

Но серьезные производители промышленных контроллеров в сторону ESP пока не смотрят.

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

в приведенном тесте радиоканал не использовался

Его нужно принудительно отключать. Иначе он вам всю производительность убьет из-за того что не может ни куда подключиться

Phazz писал(а): 12 апр 2025, 17:54

После CPU 240 мГц стоит уточнение (WiFi,BT).

Вы ошибаетесь, 80МГц это скорость работы с памятью флэш (это влияет на скорость прошивки и работу с файловой системой).

Но часто сталкиваюсь с удивлением, почему-то в каком-то сочетании блоков и алгоритмов что-то "тормозит" или не работает....

Это как раз вопрос не к производительности а к оптимизации кода. Если кто-то вставит делэй, то все эти млн. превращаются в тыкву. А если всо нормально, то 100к это с большим избытком.

1.А программа не на FLASH хранится?
И это FLASH не имеет отдельной шины адреса данных(32 разряда).
Обычно выполняется в виде отдельного чипа.
Соединяется по 4-х разрядной шине данных - скорость шины ограничена аппаратной реализацией.
2.По поводу 100к. Это у меня на очень простом тесте.
На тесте, о котором писал, было меньше 9к после тщательной оптимизации.
С уважением, ecoins.

WildCat писал(а): 12 апр 2025, 17:38 Кто назовет навскидку прикладные задачи, где требуется 100+ тыс циклов в секунду?
Пока что я ни тут, ни в ТГ канале не видел подобных проектов. Подавляющее число проектов - измерить температуру, поморгать лампочкой. Это можно делать и с сотней циклов в секунду. Что в целом подтверждает тысячи ПЛК со временем цикла не менее 1мс (а у многих и 10 мс достаточно).

Так же некорректно сравнение STM32 f/h 4/7 серий с ESP, и тем более с AVR. Они принципиально разные. Это как сравнивать КамАЗ и Оку/Жигули по гркзоподъемности.

Я не говорю что топовые СТМ не интересны и не нужны, но использовать их для условных ПЛК - как-то нерационально. И решать проблемы кривого и избыточного кода тупо производительностью МК - путь в никуда.
Гораздо интереснее раскрыть аппаратные возможности топовых МК. Там и много новых приложений можно реализовать.

Вы очень узко мыслите
К примеру в аудио обработке ваши 100кгц так себе порог там и повыше требуется порой
Или допустим робототехника где в реальном времени отслеживать высокоточное движение или действие куда больше сотни надо
А измерительные системы где нужно к примеру мне обрисовать высокочастотный сигнал а значит моя реализация должна на и порядок превосходить этот сигнал в быстродействии
Да мало ли где ещё
Что вцепились то в цыклы
Я уже сказал вам и вам и ему они точно не нужны раз у вас появляются странные вопросы на предоставление ответы

lfgjikjjyj писал(а): 12 апр 2025, 18:09

WildCat писал(а): 12 апр 2025, 17:38 Кто назовет навскидку прикладные задачи, где требуется 100+ тыс циклов в секунду?
Пока что я ни тут, ни в ТГ канале не видел подобных проектов. Подавляющее число проектов - измерить температуру, поморгать лампочкой. Это можно делать и с сотней циклов в секунду. Что в целом подтверждает тысячи ПЛК со временем цикла не менее 1мс (а у многих и 10 мс достаточно).

Так же некорректно сравнение STM32 f/h 4/7 серий с ESP, и тем более с AVR. Они принципиально разные. Это как сравнивать КамАЗ и Оку/Жигули по гркзоподъемности.

Я не говорю что топовые СТМ не интересны и не нужны, но использовать их для условных ПЛК - как-то нерационально. И решать проблемы кривого и избыточного кода тупо производительностью МК - путь в никуда.
Гораздо интереснее раскрыть аппаратные возможности топовых МК. Там и много новых приложений можно реализовать.

Вы очень узко мыслите
К примеру в аудио обработке ваши 100кгц так себе порог там и повыше требуется порой
Или допустим робототехника где в реальном времени отслеживать высокоточное движение или действие куда больше сотни надо
А измерительные системы где нужно к примеру мне обрисовать высокочастотный сигнал а значит моя реализация должна на и порядок превосходить этот сигнал в быстродействии
Да мало ли где ещё
Что вцепились то в цыклы
Я уже сказал вам и вам и ему они точно не нужны раз у вас появляются странные вопросы на предоставление ответы

Флпрог о какой робототехнике в флпрог речь? Блоками такую систему особо не реализуете.

Phazz писал(а): 12 апр 2025, 18:20

lfgjikjjyj писал(а): 12 апр 2025, 18:09

WildCat писал(а): 12 апр 2025, 17:38 Кто назовет навскидку прикладные задачи, где требуется 100+ тыс циклов в секунду?
Пока что я ни тут, ни в ТГ канале не видел подобных проектов. Подавляющее число проектов - измерить температуру, поморгать лампочкой. Это можно делать и с сотней циклов в секунду. Что в целом подтверждает тысячи ПЛК со временем цикла не менее 1мс (а у многих и 10 мс достаточно).

Так же некорректно сравнение STM32 f/h 4/7 серий с ESP, и тем более с AVR. Они принципиально разные. Это как сравнивать КамАЗ и Оку/Жигули по гркзоподъемности.

Я не говорю что топовые СТМ не интересны и не нужны, но использовать их для условных ПЛК - как-то нерационально. И решать проблемы кривого и избыточного кода тупо производительностью МК - путь в никуда.
Гораздо интереснее раскрыть аппаратные возможности топовых МК. Там и много новых приложений можно реализовать.

Вы очень узко мыслите
К примеру в аудио обработке ваши 100кгц так себе порог там и повыше требуется порой
Или допустим робототехника где в реальном времени отслеживать высокоточное движение или действие куда больше сотни надо
А измерительные системы где нужно к примеру мне обрисовать высокочастотный сигнал а значит моя реализация должна на и порядок превосходить этот сигнал в быстродействии
Да мало ли где ещё
Что вцепились то в цыклы
Я уже сказал вам и вам и ему они точно не нужны раз у вас появляются странные вопросы на предоставление ответы

Флпрог о какой робототехнике в флпрог речь? Блоками такую систему особо не реализуете.

Ну почему какую-то часть можно Если нормальные блоки делать К примеру на регистрах хотя бы для начала

К примеру у меня блок 711 Я прошёлся через дигиталы в районе чуть больше мегагерца а вот легонько если копнуть в регистры он начал выпрашивать чуть больше 3 МГц по тактированию Ну это на esp32 а вот на стмке Я думаю там куда больше можно выжить только сама микруха уже ударится ацпешная в пределы своих физических характеристик Ну мы же не ради неё стараемся