Как стать автором
Обновить

Комментарии 12

Прекрасно понимаю нежелание возвращаться к loop. Сам использую Espruino на ESP32 - да, тот самый JavaScript.

Кстати, а как у здешнего Луа с поддержкой кириллицы в консоли и\или на страничках сайта размещенного на дивайсе?

В консоли ESP8266 худо-бедно кириллицу поддерживает, ESP32 - проблемы.

На железке ни разу не то что сайт не размещал - даже окно настроек не делал. У меня другой подход к их функционированию - MQTT мое все.

На Lua я сделал гораздо больше DIY проектов, чем на Ардуино

Как насчет размера кода на Луа, читал что в 3-5 раз жирнее чем на Си.

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

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

реакции на события вызываются из файла

А какого порядка получается время реакции на событие с таким подходом?

starttime = tmr.now()
dofile('start.lua')

-- start.lua:
local now = tmr.now() - starttime 
print('Lasts: '..now..'mks' )

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

starttime = tmr.now()
dofile('start> .lua')
Lasts: 11457mks
> starttime = tmr.now()
> dofile('start.lua')
Lasts: 11370mks
> starttime = tmr.now()
dofile('sta> rt.lua')
Lasts: 11261mks
> starttime = tmr.now()
> dofile('start.lua')
Lasts: 13120mks
> starttime = tmr.now()
dofile> ('start.lua')
Lasts: 11404mks
> 

не больше 12 миллисекунд при таком тестировании.

Интересно, спасибо. А насколько оно зависит от количества кода в start.lua? Насколько я понимаю (никогда серьезно не работал с Lua) оверхед от dofile состоит не только из malloc-memcpy-free но из какого-нибудь парсинга/валидации кода.

Да, хорошая мысль.

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

Но этот же код можно предкомпилировать заранее. Что я и сделал. Теперь код имеет расширение '.lc'. Код абсолютно тот же, из двух строчек. Вот результат:

Процентов 10 быстрее.

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

Честно говоря, я практически не пользуюсь этой возможностью, ибо все мои устройства IoT - "тихоходные", им не требуется немедленной реакции на события.

Любопытно. Правда я всё еще не понимаю что оно делает эти 10мс. Ведь при частоте ядра в 80МГц, 10мс это порядка 800 000 инструкций.

Помню, пользовался Lua в свое время, даже 2 проекта работали на нем. Прекрасная вещь, в какой-то степени даже заменяла RTOS на ESP8266. Но от нее пришлось отказаться по трем причинам:

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

  2. Утечки памяти, особенно во время работы веб-сервера, когда открыта страничка с периодическим опросом

  3. Проект Lua слабо развивается

  1. Это выше моего DIY понимания :-) Или я с этой проблемой ещё не сталкивался.

  2. Много изменилось за последнее время, есть хорошая документация. Думаю следующая заметка будет посвящена всему тому, что убивает память и как с этим бороться.

  3. Сложно что-то сказать. Проект заточен под IoT. Не сталкивался с какими-то проблемами для решения именно IoT задач. Сам написал несколько модулей, в т.ч. для DS2438, max32855, ряда индикаторов, да и того же ds18b20. Не испытываю проблем. Но конечно это не Python style :-)

Отказ от loop это использование ОС, со встроенными потоками, обменом сообщений и д.р.. Например Riot OS, там все не сильно сложнее ардуино. Хотя это зависит от квалификации.

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории