Там сборщик мусора отдельная тема. Он вызвается после каждой операции «по чуть-чуть». Он настраивается прямо из Lua. Конкретно можно настроить сколько «работы» он может проделать за итерацию и как много может пытаться высвободить за раз. Можно настроить на полную очистку после каждого действия. Можно в принципе отключить, а потом включить, когда много ресурса. Лично я не меняю стандартного поведения (по чуть-чуть после каждого вызова), но потом вызываю полную очистку после какого-то большого действия. Так же если память закончилась (функция выделения памяти вернула NULL), то запускается полный цикл очистки (это неподтвержденная информация. Просто на практике это работает так).
Важно отметить необходимость в корневом CMakeLists-е указать определение, разрешающее не использовать double значения (поскольку микроконтроллер не имеет аппаратной поддержки double. Только float):
Я всерьез задумываюсь о переходе на эту ОС (по крайней мере, попробовать. Уж очень ее активно пилят и крутые штуки делают). В частности для того, чтобы разбить приложение на динамические библиотеки и подключать по желанию Lua. Для этого проекта-песочницы.
Питон не нужен. Просто не нравится. А вот Lua достаточно компактная и быстрая (чтобы дергать Си-функции много ресурса не надо).
161428 — 71172 = 90256 (при Lua c библиотеками base, coroutine, table, string). Только на Lua и обвязку. Остальное вам. Обычно берут 128 Кб. Даем драйвера в оставшиеся 40816 (128 * 1024 — 90256) и выполняемся с MicroSD).
Ну так я не говорю, что на проду надо тащить интерактивную консоль. Достаточно просто исполнять в потоках скрипты. И нет проблем.
Есть еще сомнительный выигрыш в памяти. Что не надо тащить в память МК код приложения. Но тут надо учитывать размер оперативной памяти. Иногда ставят SDRAM внешнюю. Когда есть работа с фото например или большими объемами. Там прокатит этот вариант идеально.
Ну и в устройствах, которые я проектирую, в 99% случаев есть интерфейс (чаще всего это RS-485). Он предоставляет CLI для настройки устройства (да, у нас настраиваются устройства через CLI или бинарный протокол).
Ну и основная идея отделить бизнес-логику от железа с возможностью менять ее не меняя код работы с железом. Если что и упадет — то устройство продолжит жить дальше и можно через ту же консоль все исправить.
А что плохого, если аппаратная платформа позволяет сделать это? Я понимаю, когда есть какие-то жесткие требования (например, не выделять память в устройствах жизни обеспечения). Но когда можно за цену atmega328p, на которой приходится ужиматься для реальных задач взять тот же stm32 (пусть и не f4, а f1. Но туда тоже влезет без проблем), то почему нет?
Однако есть и другой путь — использование скриптового языка, позволяющего производить отладку бизнес-логики в реальном времени на самом устройстве или загружать сценарии работы прямо с внешней памяти, не включая данного кода в состав прошивки микроконтроллера.
Честно сказать, признаю велосипеды только на уровне аппаратных багов периферии. И то стараюсь это в обертки заворачивать. Подменяя стандартные методы. Чтобы было понятно, зачем я пишу «магическую константу» по «магическому адресу». Порой приходится городить целые объекты-агрегаторы, которые пишут «магические массивы» в «магические регистры».
Так в статье так и происходит ведь. Мы набираем в буфер данные по байтам (подменяя как нам хочется \n\r. А то разные библиотеки любят по-разному каретку переводить) и затем вызываем метод объекта, который отправляет всю посылку за раз.
Полезная штука, не знал. Спасибо. Однако ее можно применять только в своем коде, при условии, что никакая из библиотек в составе проекта не использует printf (иначе все равно придется переопределять и это теряет всякий смысл). А код библиотек я стараюсь не править, чтобы при любом обновлении без проблем обновить субмодуль с библиотекой.
Как запустить то, что работает под «большой ОС» из коробки на МК без лишних затрат и проблем с надежностью.
есть введение, должно быть заключение
Что-то как-то не подумал об этом. Но оно было бы бессмысленно — уровня «я привел самые частые грабли и краткие методы их решения».
Если не нравятся готовые printf.c, xprint и прочие, то в чем сложность написать его самому, если не полный, то лайтовый. Или доработать указанные выше? Плавающая точка, в принципе, несложно делается.
Сами функции всем устраивают. Вообще не люблю велосипеды по возможности писать. Не так давно писал статью о том, как можно запихать как можно больше стандартных библиотек в МК чтобы не писать своего, пусть и в ущерб памяти. Сейчас отрабатываю вариант комфортной отладки без лишней перепрошивки, но удобнее чем в той статье. Опишу, как обнаружу основные изъяны (если таковые будут).
Не совсем. В статье я упоминал, что "… если вы используете newlib-nano...". Интерфейсы верхнего уровня — да. Одинаковые (в большинстве своем). А вот «внизу», каждый как сам захочет (на сколько мне известно, это не регламентируется).
Мне не нравится python. Как язык. Просто ИМХО. Поэтому даже не рассматривал. Возможно он чем-то даже лучше. По мне он избыточен и неявен.
Уже была статья о том, как запустить c# интерпретатор на stm32f4. Тут же на хабре. Всё очень медленно.
Питон не нужен. Просто не нравится. А вот Lua достаточно компактная и быстрая (чтобы дергать Си-функции много ресурса не надо).
Есть еще сомнительный выигрыш в памяти. Что не надо тащить в память МК код приложения. Но тут надо учитывать размер оперативной памяти. Иногда ставят SDRAM внешнюю. Когда есть работа с фото например или большими объемами. Там прокатит этот вариант идеально.
Ну и в устройствах, которые я проектирую, в 99% случаев есть интерфейс (чаще всего это RS-485). Он предоставляет CLI для настройки устройства (да, у нас настраиваются устройства через CLI или бинарный протокол).
Вроде русским по цвету фона написано…
Как запустить то, что работает под «большой ОС» из коробки на МК без лишних затрат и проблем с надежностью.
Что-то как-то не подумал об этом. Но оно было бы бессмысленно — уровня «я привел самые частые грабли и краткие методы их решения».
Сами функции всем устраивают. Вообще не люблю велосипеды по возможности писать. Не так давно писал статью о том, как можно запихать как можно больше стандартных библиотек в МК чтобы не писать своего, пусть и в ущерб памяти. Сейчас отрабатываю вариант комфортной отладки без лишней перепрошивки, но удобнее чем в той статье. Опишу, как обнаружу основные изъяны (если таковые будут).