Pull to refresh
Comments 44
Прочитал всю статью. Дважды. Все равно не понял, зачем lua тянуть в микроконтроллеры.
учитывая распространенность NodeMCU в DIY, похоже некоторый смысл есть
А не проще и дешевле просто Lua в C перегнать?
github.com/davidm/lua2c — реп старенький, наверняка что-то по-свежее есть.
Просто вчера они пихают в stm java, сегодня lua, что завтра? Scala? Angular?
А что плохого, если аппаратная платформа позволяет сделать это? Я понимаю, когда есть какие-то жесткие требования (например, не выделять память в устройствах жизни обеспечения). Но когда можно за цену atmega328p, на которой приходится ужиматься для реальных задач взять тот же stm32 (пусть и не f4, а f1. Но туда тоже влезет без проблем), то почему нет?
Вы своей луа в максимальной упаковке сожрали 200к памяти. На f1 вся флеша 256 кб, и то на особо жирных моделях (*RC/*VC), и 64к под RAM.
Вопрос — а код, который НЕ lua, и остальная обвязка куда?
161428 — 71172 = 90256 (при Lua c библиотеками base, coroutine, table, string). Только на Lua и обвязку. Остальное вам. Обычно берут 128 Кб. Даем драйвера в оставшиеся 40816 (128 * 1024 — 90256) и выполняемся с MicroSD).

Уже была статья о том, как запустить c# интерпретатор на stm32f4. Тут же на хабре. Всё очень медленно.

Вроде бы сказал, что на хабре… Вот. Там полноценная виртуальная машина. Работает по USB.
Это практически одно и тоже, микрософт забросили свой micro framework, но он open source, эти ребята подхватили. Так вот там не интерпретатор, а среда запуска, без виртуальной машины.
У меня есть плата которая есть в списке поддерживаемых, хочу попробовать запустить.
И вообще, шарп, конечно, крутой язык (один из любимых под ПК), но очень медленный для МК.
Однако есть и другой путь — использование скриптового языка, позволяющего производить отладку бизнес-логики в реальном времени на самом устройстве или загружать сценарии работы прямо с внешней памяти, не включая данного кода в состав прошивки микроконтроллера.

Вроде русским по цвету фона написано…
Вы забиваете гвозди не то, что микроскопом, а низкоорбитальной ионной пушкой.
Ну и основная идея отделить бизнес-логику от железа с возможностью менять ее не меняя код работы с железом. Если что и упадет — то устройство продолжит жить дальше и можно через ту же консоль все исправить.
и можно через ту же консоль все исправить.

На проде никакой консоли не будет. На проде эта штука хорошо если не будет залита компаундом и\или спрятана в глубине аппарата с единственным доступным отверстием — это слотом для SD карты и кнопкой ребута.

Единственные (почти) случаи, когда внутри нужен интерпретатор — это ЧПУ станки (там почти всегда G-code) и какие-то жалкие попытки бизнеса сэкономить на изготовлении прошивок (что-то краем уха слышал о проекте где ядро было в прошивке, а на external sd была обвязка, которая регулировала, с чем мы сейчас работаем, кажется речь была о СКУД системах).
Ну так я не говорю, что на проду надо тащить интерактивную консоль. Достаточно просто исполнять в потоках скрипты. И нет проблем.

Есть еще сомнительный выигрыш в памяти. Что не надо тащить в память МК код приложения. Но тут надо учитывать размер оперативной памяти. Иногда ставят SDRAM внешнюю. Когда есть работа с фото например или большими объемами. Там прокатит этот вариант идеально.

Ну и в устройствах, которые я проектирую, в 99% случаев есть интерфейс (чаще всего это RS-485). Он предоставляет CLI для настройки устройства (да, у нас настраиваются устройства через CLI или бинарный протокол).
Ну что вы! Это просто микро-микро контроллер. :-) У нас 15 лет назад ещё хуже было. Контроллер ICPDAS I-7188 — это MS-DOS compatible, 80188, 40Мгц, 256 или 512К ОЗУ. На это чудо было сделаны функциональные блоки (задвижки и так далее), собственный недо-язык программирования и компилятор для него.

Фото этого чуда
image

Как видите по размеру разъемов — у типичной STM32 возможностей (GPIO, АЦП, ЦАП) побольше.

На таких вот «мыльницах» и их старших братьях (80 МГЦ) делалась автоматизация котельной на НорНикеле и автоматизации для цементных заводов. Типичная трехзвенная SCADA — нижний уровень (то, что должно работать 24*7*365) на контролерах, средний — на сервере, верхний — на персоналке (визуализация графиков и пуль оператора).

Теперь самое главное — почему не на Си. Собственный язык — это не только для того, чтобы технологи на нем писали. Любой заводской цех — живой, в смысле состава оборудования. Что-то сломалось — значит наживую, заводскими инженерами в течение 5-10 правится код управления, чтобы работать в обход сломавшейся части. Потом, примерно раз в месяц — ППР (планово-предупредительный ремонт) и возврат к штатному варианту.

Ещё хуже — ползучая модернизация. Это когда через 5-10 лет выясняется, что замены отказавшего датчика больше не выпускается. И заменяется на аналог, работающий немного не так. Или купили новое оборудование, и надо его встроить.

Заводские инженеры не могут менять сишный паскалевский код. Но — у них есть право менять «настройки». А собственный язык программирования — относится к «настройкам» системы.

Аналогично надо относится и к системам «умного дома». Там тоже — раз в 5-10 лет — ремонт, меняется состав семьи, ставятся новые розетки и выключатели. И тоже есть смысл не зашивать все в код, а дать возможность допрограммировать алгоритмы верхнего уровня.
Допустим для стендового оборудования. Когда под разные задачи надо менять часть бизнес-логики без необходимости перепрошивки, и с возможность добавления сценариев со временем.
Иногда бывает полезно иметь скриптовый язык в устройстве, особенно когда стоит задача дать пользователю возможность слегка модифицировать логику работы, но при этом не дать натворить непоправимого.

Lua кстати — самый шустрый и легковесный вариант для таких случаев. По работе делал примерно то же самое, что описано в статье, для местного испытательного комплекса. Только у нас там еще и самописный WEB-сервер (сеть через Ethernet). Все вместе занимает 144380 байт во флеше STM32F429 (FreeRTOS + драйвера + Lua + стек TCP/IP + WEB-сервер).
Lua кстати — самый шустрый и легковесный вариант для таких случаев.

Не считая FORTH? ;)
я бы даже сказал, не рассматривая как вариант вообще.

особенно когда стоит задача дать пользователю возможность слегка модифицировать логику работы
А что мешает? Кроме незнания FORTH, разумеется.
Он, вообще-то говоря, для подобных задач и разрабатывался…
Ну точно так же можно сказать, что ничего не мешает (ну кроме незнания архитектуры процессора) просто отводить пользователю область памяти, пусть он прямо туда свой скрипт в бинарном коде фигачит (с консоли), можно даже слегка огородить, и не позволять лезть куда не надо, как на стадии проверки нафигаченного перед исполнением, так и в рантайме, MPU обычно хоть какой-нибдь даже есть, но никто почему-то так не делает.
Может быть это не очень удобно?

Хотя нет, вообще-то делают, в тринамиковских контроллерах шаговых двигателей пользователю дают очень примитивный ассемблер виртуальной машины, для написания «скриптов». user friendly, лучше не придумаешь. Обратной польской нотации там только не хватает для полного счастья.
MPU обычно хоть какой-нибдь даже есть


В тех системах, с которыми работаю я, MPU обычно нет. :)
Там куда можно впихнуть Lua, всё-таки какой-нибудь обычно есть.

И я слишком тонко пошутил? Или вы серьёзно рассматриваете возможность выделить пользователю блок памяти, который он может просто заполнить исполняемым бинарным кодом в качестве «пользовательского скрипта»?
О-о-о, мосье — большой эстет! :)

Может тогда уж лучше TCL? :)
Смайлы я оценил. :)

А вот непонимание отличия скриптового TCL от FORTH — расширяемого языка — вызывает лёгкую грусть… Видимо, кроме меня тут мало кто использовал его на практике. :))
FORTH в подобных устройствах позволил бы написать для каждого класса задач свой «язык решения задачи». И обратная польская запись, к слову — совершенно не проблема. К ней либо быстро привыкаешь, либо меняешь FORTH-систему, «заставляя» её работать привычным для себя образом.
Хотя зачем это делать, я не знаю. Мне это в своё время нисколько не мешало… :)
+1 за форт. По гибкости и компактности с ним конкурировать не может ни одно решение.
Подзабыт уже, к сожалению…

А на тех же PIC от Microchip, которые я использую, ещё и неудобен в реализации, вследствие архитектуры процессоров.

Но компактности и скорости как разработки, так и исполнения программ на FORTH многие в своё время удивлялись. :)
Уникальность форта в простоте. Сделать свою реализацию можно очень быстро. Следовать или не следовать стандартам каждый решает сам, но поскольку стандарты писали весьма умные люди, следование стандартам как правило полезно. В отличие от питона да и того же луа форт будет держаться на энтузиастах и проживет еще долго. Так что имхо за форт переживать не надо :). К слову: github.com/ForthHub/discussion/issues
Так что имхо за форт переживать не надо :)

Ну так я и не. :)
Наоборот, «продвигаю». :))
К слову: github.com/ForthHub/discussion/issues

Да, работа идёт… :))
Круто! Респект!
Не сочтите за рекламу, но возьмите Embox, там Вам и STM-ки будут и Lua (и python до кучи) и модифицировать сможете как угодно. Если конечно нет какого то тайного смысла делать самому. :)
Я всерьез задумываюсь о переходе на эту ОС (по крайней мере, попробовать. Уж очень ее активно пилят и крутые штуки делают). В частности для того, чтобы разбить приложение на динамические библиотеки и подключать по желанию Lua. Для этого проекта-песочницы.
Питон не нужен. Просто не нравится. А вот Lua достаточно компактная и быстрая (чтобы дергать Си-функции много ресурса не надо).
По умолчанию все числа в Lua — это double. Но можно скомпилировать его так, чтобы это были int (хотя версии после 5.3 поддерживают его нативно). Как у вас в проекте с этим?
Важно отметить необходимость в корневом CMakeLists-е указать определение, разрешающее не использовать double значения (поскольку микроконтроллер не имеет аппаратной поддержки double. Только float):

Мне не нравится python. Как язык. Просто ИМХО. Поэтому даже не рассматривал. Возможно он чем-то даже лучше. По мне он избыточен и неявен.

А сборщик мусора как часто вызывается? И каким образом? Сам по себе после интерпретации, принудительно или по прерыванию какому?
Там сборщик мусора отдельная тема. Он вызвается после каждой операции «по чуть-чуть». Он настраивается прямо из Lua. Конкретно можно настроить сколько «работы» он может проделать за итерацию и как много может пытаться высвободить за раз. Можно настроить на полную очистку после каждого действия. Можно в принципе отключить, а потом включить, когда много ресурса. Лично я не меняю стандартного поведения (по чуть-чуть после каждого вызова), но потом вызываю полную очистку после какого-то большого действия. Так же если память закончилась (функция выделения памяти вернула NULL), то запускается полный цикл очистки (это неподтвержденная информация. Просто на практике это работает так).
Отдельно хочу отметить проект eLua. В моем случае, у меня уже имеется готовая программная низкоуровневая прослойка для взаимодействия как с периферией микроконтроллера, так и для прочей требуемой периферии, расположенной на плате устройства. Поэтому данный проект мною не рассматривался (поскольку он признан предоставить те самые прослойки для связи ядра Lua с периферией микроконтроллера).

Советую присмотреться к eLua повнимательней. Кроме библиотек для работы с железом (которые я с своих разработках тоже не использую) этот проект содержит такую очень полезную доработку как LTR (Lua Tiny RAM), использование которой позволяет существенную экономию оперативной памяти.
При использовании этой доработки в реальных задачах оказалось возможным выполнять на микроконтроллере несложные, но и не тривиальные (в несколько десятков строк), скрипы «бизнес-логики», выделяя под Lua'шную кучу всего 32 килобайта.
Only those users with full accounts are able to leave comments. Log in, please.