Ускорение MicroPython

[trolley813]

По-моему, здесь все-таки уместнее писать «микроконтроллер», а не «микропроцессор» (как-никак, у описываемых в статье штуковин и внешние интерфейсы есть, чего у процессоров нет). А в широком смысле к микропроцессорам и CPU относятся.

[alter_fritz]

Согласен, исправил. Спасибо

[GarryC]

Обычно, когда мы измеряем время реакции, нас очень интересует, помимо среднего значения, максимальное, поскольку именно оно дает границы применимости. Хорошо бы дополнить этим параметром.

[alter_fritz]

Дополнил максимальные времена отклика вариантов программ.

[poznawatel]

Огромное спасибо автору за свежие идеи! Используем micropython для управления промустановками и в 95% случаев его достаточно. Теперь применимость расширим.

[alter_fritz]

Можете поделиться, какие микроконтроллеры с micropython используете и для каких конкретно целей

[poznawatel]

Пока используем pyboard 1.1 с офиц сайта и стандартный экран к нему. Интерфейс — сенсорный экран + аппаратные кнопки (родной экран очень маленький, палец закрывает элементы интерфейса). Управляем маломощными лабораторными и промышленными установками, на которых хватает шаговых/сервошаговых приводов. Ввод-вывод через Овен-овские блоки (Modbus через RS485).

[MrBoriska]

На мой взгляд, если проводить аналогии с автомобилями… то использование MicroPython вместо С/C++/Asm, лучше представлять как использование некой продвинутой системы помощи водителю, а не швабры)

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

Прогресс не стоит на месте, и производительность таких решений часто бывает более чем приемлема, особенно с учетом гораздо большей скорости разработки программ на питоне чем на С/C++/Asm.

[webself]

Про толкать машину уже написали вам.

писать что либо на языке где все зависит от табуляции тот еще ссюр

А на это скажу, что примерно так же относился к табуляциям питона, пока сам не начал писать на нем. Сейчас, спустя годы, имею стойкое мнение, что это одна из самых ценных находок человечества. Не писать begin/end-ы, а заменить их отступами.

[webself]

alter_fritz а вы не могли бы дополнить статью аналогичными тестами на Lua/NodeMCU? Там такого количества возможностей для оптимизации нет. Только просто код и скомпилированный код. Но вроде как код луа гораздо ближе к машинному, интересно, как его быстродействие с uPython будет конкурировать.

[Vad55]

Нужно понимать, что отладочные платы типа NodeMcu, Raspberry Pi pico, RP2040-zero и прочие, это не промышленный уровень, при всем уважении к труду китайских сборщиков.

Поэтому время отклика при использовании MicroPython вполне укладывается в стандартное распределение 80% / 20 % плюс-минус. То есть грубо для 80% проектов, под которые покупаются данные платы это более, чем достаточно. Для остальных 20% проектов которые чувствительны ко времени отклика и это для них критично, можно использовать различные ухищрения для нивелирования проблемы.

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

А как вариант быстрого прототипирования, DIY и прочего обучения, MicroPython намного удобнее.