Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
.
Нет, я не использую файловую систему вообще. Я гружу байт код в выделенный сектор флеша и при старте система пытается запустить байт-код от туда. Файловая система может быть оправдана чисто с инструментальной точки зрения, 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 из скрипта в какой-нить отладочный канал и смотреть че творится внутри скрипта. Системный софт как-то на этом уровне отлаживает, не всегда можно дебажится. Да вопрос проверки корректности аргументов тоже можно зарешать.
А подскажите куда по графическим языкам глянуть?
Но вот проверить корректность аргументов при переходе через границу API он уже не сможет.
Здесь может помочь модуль checks, который позволяет для каждой функции описывать возможные типы аргументов или другие проверки аргументов. Вот исходник - https://github.com/fab13n/metalua/blob/master/checks.lua
А что в итоге с производительностью?
Судя по статье, байт код достаточно тяжёлый для интерпретации.
Ну и всегда у контроллера есть метрика - влезает столько то команд пользовательской программы, со временем исполнения нннн команд/мс.
А динамическая натура памяти в луа еще потребует и эту метрику измерять И контролировать на этапе разработки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Lua, как инструмент во встроенных системах