Комментарии 44
НЛО прилетело и опубликовало эту надпись здесь
учитывая распространенность NodeMCU в DIY, похоже некоторый смысл есть
НЛО прилетело и опубликовало эту надпись здесь
А что плохого, если аппаратная платформа позволяет сделать это? Я понимаю, когда есть какие-то жесткие требования (например, не выделять память в устройствах жизни обеспечения). Но когда можно за цену atmega328p, на которой приходится ужиматься для реальных задач взять тот же stm32 (пусть и не f4, а f1. Но туда тоже влезет без проблем), то почему нет?
ДотНет!
Уже была статья о том, как запустить c# интерпретатор на stm32f4. Тут же на хабре. Всё очень медленно.
nanoframework.net/home/getting-started-guides это?
а то у них билдится в студии и уже .exe загружается.
а то у них билдится в студии и уже .exe загружается.
Вроде бы сказал, что на хабре… Вот. Там полноценная виртуальная машина. Работает по USB.
И вообще, шарп, конечно, крутой язык (один из любимых под ПК), но очень медленный для МК.
Однако есть и другой путь — использование скриптового языка, позволяющего производить отладку бизнес-логики в реальном времени на самом устройстве или загружать сценарии работы прямо с внешней памяти, не включая данного кода в состав прошивки микроконтроллера.
Вроде русским по цвету фона написано…
НЛО прилетело и опубликовало эту надпись здесь
Ну и основная идея отделить бизнес-логику от железа с возможностью менять ее не меняя код работы с железом. Если что и упадет — то устройство продолжит жить дальше и можно через ту же консоль все исправить.
НЛО прилетело и опубликовало эту надпись здесь
Ну так я не говорю, что на проду надо тащить интерактивную консоль. Достаточно просто исполнять в потоках скрипты. И нет проблем.
Есть еще сомнительный выигрыш в памяти. Что не надо тащить в память МК код приложения. Но тут надо учитывать размер оперативной памяти. Иногда ставят SDRAM внешнюю. Когда есть работа с фото например или большими объемами. Там прокатит этот вариант идеально.
Ну и в устройствах, которые я проектирую, в 99% случаев есть интерфейс (чаще всего это RS-485). Он предоставляет CLI для настройки устройства (да, у нас настраиваются устройства через CLI или бинарный протокол).
Есть еще сомнительный выигрыш в памяти. Что не надо тащить в память МК код приложения. Но тут надо учитывать размер оперативной памяти. Иногда ставят SDRAM внешнюю. Когда есть работа с фото например или большими объемами. Там прокатит этот вариант идеально.
Ну и в устройствах, которые я проектирую, в 99% случаев есть интерфейс (чаще всего это RS-485). Он предоставляет CLI для настройки устройства (да, у нас настраиваются устройства через CLI или бинарный протокол).
Ну что вы! Это просто микро-микро контроллер. :-) У нас 15 лет назад ещё хуже было. Контроллер ICPDAS I-7188 — это MS-DOS compatible, 80188, 40Мгц, 256 или 512К ОЗУ. На это чудо было сделаны функциональные блоки (задвижки и так далее), собственный недо-язык программирования и компилятор для него.
Как видите по размеру разъемов — у типичной STM32 возможностей (GPIO, АЦП, ЦАП) побольше.
На таких вот «мыльницах» и их старших братьях (80 МГЦ) делалась автоматизация котельной на НорНикеле и автоматизации для цементных заводов. Типичная трехзвенная SCADA — нижний уровень (то, что должно работать 24*7*365) на контролерах, средний — на сервере, верхний — на персоналке (визуализация графиков и пуль оператора).
Теперь самое главное — почему не на Си. Собственный язык — это не только для того, чтобы технологи на нем писали. Любой заводской цех — живой, в смысле состава оборудования. Что-то сломалось — значит наживую, заводскими инженерами в течение 5-10 правится код управления, чтобы работать в обход сломавшейся части. Потом, примерно раз в месяц — ППР (планово-предупредительный ремонт) и возврат к штатному варианту.
Ещё хуже — ползучая модернизация. Это когда через 5-10 лет выясняется, что замены отказавшего датчика больше не выпускается. И заменяется на аналог, работающий немного не так. Или купили новое оборудование, и надо его встроить.
Заводские инженеры не могут менятьсишный паскалевский код. Но — у них есть право менять «настройки». А собственный язык программирования — относится к «настройкам» системы.
Аналогично надо относится и к системам «умного дома». Там тоже — раз в 5-10 лет — ремонт, меняется состав семьи, ставятся новые розетки и выключатели. И тоже есть смысл не зашивать все в код, а дать возможность допрограммировать алгоритмы верхнего уровня.
Фото этого чуда
Как видите по размеру разъемов — у типичной STM32 возможностей (GPIO, АЦП, ЦАП) побольше.
На таких вот «мыльницах» и их старших братьях (80 МГЦ) делалась автоматизация котельной на НорНикеле и автоматизации для цементных заводов. Типичная трехзвенная SCADA — нижний уровень (то, что должно работать 24*7*365) на контролерах, средний — на сервере, верхний — на персоналке (визуализация графиков и пуль оператора).
Теперь самое главное — почему не на Си. Собственный язык — это не только для того, чтобы технологи на нем писали. Любой заводской цех — живой, в смысле состава оборудования. Что-то сломалось — значит наживую, заводскими инженерами в течение 5-10 правится код управления, чтобы работать в обход сломавшейся части. Потом, примерно раз в месяц — ППР (планово-предупредительный ремонт) и возврат к штатному варианту.
Ещё хуже — ползучая модернизация. Это когда через 5-10 лет выясняется, что замены отказавшего датчика больше не выпускается. И заменяется на аналог, работающий немного не так. Или купили новое оборудование, и надо его встроить.
Заводские инженеры не могут менять
Аналогично надо относится и к системам «умного дома». Там тоже — раз в 5-10 лет — ремонт, меняется состав семьи, ставятся новые розетки и выключатели. И тоже есть смысл не зашивать все в код, а дать возможность допрограммировать алгоритмы верхнего уровня.
Допустим для стендового оборудования. Когда под разные задачи надо менять часть бизнес-логики без необходимости перепрошивки, и с возможность добавления сценариев со временем.
Иногда бывает полезно иметь скриптовый язык в устройстве, особенно когда стоит задача дать пользователю возможность слегка модифицировать логику работы, но при этом не дать натворить непоправимого.
Lua кстати — самый шустрый и легковесный вариант для таких случаев. По работе делал примерно то же самое, что описано в статье, для местного испытательного комплекса. Только у нас там еще и самописный WEB-сервер (сеть через Ethernet). Все вместе занимает 144380 байт во флеше STM32F429 (FreeRTOS + драйвера + Lua + стек TCP/IP + WEB-сервер).
Lua кстати — самый шустрый и легковесный вариант для таких случаев. По работе делал примерно то же самое, что описано в статье, для местного испытательного комплекса. Только у нас там еще и самописный WEB-сервер (сеть через Ethernet). Все вместе занимает 144380 байт во флеше STM32F429 (FreeRTOS + драйвера + Lua + стек TCP/IP + WEB-сервер).
Lua кстати — самый шустрый и легковесный вариант для таких случаев.
Не считая FORTH? ;)
я бы даже сказал, не рассматривая как вариант вообще.
особенно когда стоит задача дать пользователю возможность слегка модифицировать логику работы
А что мешает? Кроме незнания FORTH, разумеется.
Он, вообще-то говоря, для подобных задач и разрабатывался…
Он, вообще-то говоря, для подобных задач и разрабатывался…
Ну точно так же можно сказать, что ничего не мешает (ну кроме незнания архитектуры процессора) просто отводить пользователю область памяти, пусть он прямо туда свой скрипт в бинарном коде фигачит (с консоли), можно даже слегка огородить, и не позволять лезть куда не надо, как на стадии проверки нафигаченного перед исполнением, так и в рантайме, MPU обычно хоть какой-нибдь даже есть, но никто почему-то так не делает.
Может быть это не очень удобно?
Хотя нет, вообще-то делают, в тринамиковских контроллерах шаговых двигателей пользователю дают очень примитивный ассемблер виртуальной машины, для написания «скриптов». user friendly, лучше не придумаешь. Обратной польской нотации там только не хватает для полного счастья.
Может быть это не очень удобно?
Хотя нет, вообще-то делают, в тринамиковских контроллерах шаговых двигателей пользователю дают очень примитивный ассемблер виртуальной машины, для написания «скриптов». user friendly, лучше не придумаешь. Обратной польской нотации там только не хватает для полного счастья.
О-о-о, мосье — большой эстет! :)
Может тогда уж лучше TCL? :)
Может тогда уж лучше TCL? :)
Смайлы я оценил. :)
А вот непонимание отличия скриптового TCL от FORTH — расширяемого языка — вызывает лёгкую грусть… Видимо, кроме меня тут мало кто использовал его на практике. :))
FORTH в подобных устройствах позволил бы написать для каждого класса задач свой «язык решения задачи». И обратная польская запись, к слову — совершенно не проблема. К ней либо быстро привыкаешь, либо меняешь FORTH-систему, «заставляя» её работать привычным для себя образом.
Хотя зачем это делать, я не знаю. Мне это в своё время нисколько не мешало… :)
А вот непонимание отличия скриптового TCL от FORTH — расширяемого языка — вызывает лёгкую грусть… Видимо, кроме меня тут мало кто использовал его на практике. :))
FORTH в подобных устройствах позволил бы написать для каждого класса задач свой «язык решения задачи». И обратная польская запись, к слову — совершенно не проблема. К ней либо быстро привыкаешь, либо меняешь FORTH-систему, «заставляя» её работать привычным для себя образом.
Хотя зачем это делать, я не знаю. Мне это в своё время нисколько не мешало… :)
+1 за форт. По гибкости и компактности с ним конкурировать не может ни одно решение.
Подзабыт уже, к сожалению…
А на тех же PIC от Microchip, которые я использую, ещё и неудобен в реализации, вследствие архитектуры процессоров.
Но компактности и скорости как разработки, так и исполнения программ на FORTH многие в своё время удивлялись. :)
А на тех же PIC от Microchip, которые я использую, ещё и неудобен в реализации, вследствие архитектуры процессоров.
Но компактности и скорости как разработки, так и исполнения программ на FORTH многие в своё время удивлялись. :)
Уникальность форта в простоте. Сделать свою реализацию можно очень быстро. Следовать или не следовать стандартам каждый решает сам, но поскольку стандарты писали весьма умные люди, следование стандартам как правило полезно. В отличие от питона да и того же луа форт будет держаться на энтузиастах и проживет еще долго. Так что имхо за форт переживать не надо :). К слову: github.com/ForthHub/discussion/issues
Круто! Респект!
Не сочтите за рекламу, но возьмите Embox, там Вам и STM-ки будут и Lua (и python до кучи) и модифицировать сможете как угодно. Если конечно нет какого то тайного смысла делать самому. :)
Не сочтите за рекламу, но возьмите Embox, там Вам и STM-ки будут и Lua (и python до кучи) и модифицировать сможете как угодно. Если конечно нет какого то тайного смысла делать самому. :)
Я всерьез задумываюсь о переходе на эту ОС (по крайней мере, попробовать. Уж очень ее активно пилят и крутые штуки делают). В частности для того, чтобы разбить приложение на динамические библиотеки и подключать по желанию Lua. Для этого проекта-песочницы.
Питон не нужен. Просто не нравится. А вот Lua достаточно компактная и быстрая (чтобы дергать Си-функции много ресурса не надо).
Питон не нужен. Просто не нравится. А вот Lua достаточно компактная и быстрая (чтобы дергать Си-функции много ресурса не надо).
По умолчанию все числа в Lua — это double. Но можно скомпилировать его так, чтобы это были int (хотя версии после 5.3 поддерживают его нативно). Как у вас в проекте с этим?
MicroPython, не?
www.st.com/en/embedded-software/grpl-upython.html
www.st.com/en/embedded-software/grpl-upython.html
А сборщик мусора как часто вызывается? И каким образом? Сам по себе после интерпретации, принудительно или по прерыванию какому?
Там сборщик мусора отдельная тема. Он вызвается после каждой операции «по чуть-чуть». Он настраивается прямо из Lua. Конкретно можно настроить сколько «работы» он может проделать за итерацию и как много может пытаться высвободить за раз. Можно настроить на полную очистку после каждого действия. Можно в принципе отключить, а потом включить, когда много ресурса. Лично я не меняю стандартного поведения (по чуть-чуть после каждого вызова), но потом вызываю полную очистку после какого-то большого действия. Так же если память закончилась (функция выделения памяти вернула NULL), то запускается полный цикл очистки (это неподтвержденная информация. Просто на практике это работает так).
Отдельно хочу отметить проект eLua. В моем случае, у меня уже имеется готовая программная низкоуровневая прослойка для взаимодействия как с периферией микроконтроллера, так и для прочей требуемой периферии, расположенной на плате устройства. Поэтому данный проект мною не рассматривался (поскольку он признан предоставить те самые прослойки для связи ядра Lua с периферией микроконтроллера).
Советую присмотреться к eLua повнимательней. Кроме библиотек для работы с железом (которые я с своих разработках тоже не использую) этот проект содержит такую очень полезную доработку как LTR (Lua Tiny RAM), использование которой позволяет существенную экономию оперативной памяти.
При использовании этой доработки в реальных задачах оказалось возможным выполнять на микроконтроллере несложные, но и не тривиальные (в несколько десятков строк), скрипы «бизнес-логики», выделяя под Lua'шную кучу всего 32 килобайта.
Спасибо, не знал. Почитаю.
полезная статья-спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встраиваем Lua интерпретатор в проект для микроконтроллера (stm32)