Comments 12
.
Нет, я не использую файловую систему вообще. Я гружу байт код в выделенный сектор флеша и при старте система пытается запустить байт-код от туда. Файловая система может быть оправдана чисто с инструментальной точки зрения, usb mass-storage к примеру. Но вот у меня девайс по CAN скрипт получает, зачем там файловая система?
Для корутин не нужно отдельного стейта. Если она одна, то ее можно размешать в основной стейт без проблем.
Если имеется ввиду внешний флэш, то да, есть такой вариант, но в любом случае основное ограничение в системе RAM. Флэша больше чем виртуальный памяти Lua машины не нужно.
Про корутину. Она тем и отличается от функций , что имеет свой стек. Поэтому при вызове другой функции не надо выгружать переменные корутины. Просто передается управление в основной стек или в стек другой корутины. При возврате все внутренние переменные и параметры не надо снова загружать так как они находятся в ее стеке.
--------------------
Просто хорошо знаю внутренности VMLua и LuaJit так как использую ее давно и на микроконтроллерах ESP и в OC Windows.
Все, я понял вашу мысль. Вы абсолютно правы, но у меня специфическая штука, у меня нет главного стейта и основного стека:) У меня есть только стейт корутины, и корутина делает уступку только хосту. Т.е. по сути у меня нет корутины:) Я использую ее механизм для передачи управления между хостом и прикладной функций Lua, которая у меня бесконечный цикл и никогда не завершается. Можно было сделать и без коруитны, но поскольку у меня на Lua по сути написана итерация прикладного алгоритма (или функция выходных значений от входных если в терминах релейки), мне удобно через resume\yield передавать входные переменные и забирать выходные. Плюс явная уступка хосту дает мне возможность контроля над временем итерации прикладного алгоритма. И собственно в статье я про это и пишу, про использование механизма корутины, и в этом случае не нужно отдельного стейта, все живет в основном.
Понятно, но зачем тогда корутину использовать? У Вас как бы не типовое применение. Почему не делали типовую VMLua и на ней все крутили ?
Типовую VMLua не кручу, потому что мне на фиг не надо программировать контроллер из под виртуалки, не решаются так мои системные задачи и ПЛК для АСУ ТП так не делаются. Мне нужно программировать только бизнес-логику. Что бы править ее без перекомпиляции ядра и пускать в нее прикладных инженеров. А корутину пользую потому что так проще решить задачу - мне нужна явная передача управления из цикла скрипта обратно в процесс RTOS, с сохранением контекста скрипта, и явный возврат обратно в скрипт. И статью я собственно писал именно по это, что вот какая классная штука Lua, можно приспособить как ПЛК в маленьких реалтайм системах на раз-два.
Немного отступлю от основного контекста: во времена AVR-ок, когда 128 Мега шилась под нескольку минут, а разработчики платы на этапе макетирования заказывали изменения раз так 100 за день, ооочень хотелось как-то организовать всё скриптами. После миграции на STMки проблема ушла сама собой: мгновенная заливка огромных прошивок, выполнение из RAM, а драйвер Keil-a позволил мониторить регистры в реальном времени. С тех пор единственным аргументом в пользу скриптов была бы их правка юзерами, дескать, «на тебе, а интервалы там себе в текстовом файле подправишь как тебе нравится». Однако сейчас можно либо вывести черезWiFi веб-морду, либо через USB-CDC вносить правки самописной программой с нормальным интерфейсом... В общем для меня не «полная замена» на Lua, а именно расширение, выглядит как что-то очень специфичное и узкоспециализированное, нужное только тому, кто... - ну вы поняли)
правка юзерами
Эта фича хорошо проталкивается продавцами, покупатели реально ведутся на такое. В реальности (я про нашу контору), всё, что сложнее "палка - веревка", приходится делать нам, разработчикам. И тут уже начинаюися спотыки об ограничения скриптовой системы. В итоге, мы добавили систему плагинов, когда расширения системы реализуются в формате динамически загружаемых библиотек (чистый "нативный" код); а "скриптовую стстему" оставили для продавцов, пусть дальше клиентам лапшу вешают про "правку юзерами".
У LUA скриптов весьма неудобная отладка.
Нет пошаговой отладки, нет просмотра в реальном времени переменыых скрипта.
А ведь отладка занимает 90% времени. А сейчас с AI и вообще 99%
Проверить синтаксис может и DeepSeek для любого языка, с этим проблем нет.
Но вот проверить корректность аргументов при переходе через границу API он уже не сможет.
Если бы софт писался в одном простанстве языка, то это тоже мог бы проверить AI. А тут нет. И приходится напарываться на эти грабли уже в поле.
А почему не смотрели на создание моделей в графических языках, с интерфейсом к софтовому фреймворку железа. Они компилируются, хороши симулируются, можно запускать и удаленно на PC в режиме SIL.
Ну ни кто не мешает перенаправить printf из скрипта в какой-нить отладочный канал и смотреть че творится внутри скрипта. Системный софт как-то на этом уровне отлаживает, не всегда можно дебажится. Да вопрос проверки корректности аргументов тоже можно зарешать.
А подскажите куда по графическим языкам глянуть?
А что в итоге с производительностью?
Судя по статье, байт код достаточно тяжёлый для интерпретации.
Ну и всегда у контроллера есть метрика - влезает столько то команд пользовательской программы, со временем исполнения нннн команд/мс.
А динамическая натура памяти в луа еще потребует и эту метрику измерять И контролировать на этапе разработки.
Lua, как инструмент во встроенных системах