скриптовый язык для МК

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

Базовый МК - stm32f030, памяти 4к, флеша 16к

Вот хочу какой-то компактный байткод. Или машину состояний. Загрузка через UART

Сейчас впихнул форт, вроде завелся. Но терзают смутные сомнения, что есть еще варианты.

0

okotimiv, зачем делают DSL знаете? Вот это оно и есть )

0

И это еще совершенно не означает, что оно для чего-то тут нужно. Во всяком случае задача не выглядит требующей DSL.

0

А грузить исполняемый участок кода в ROM никак нельзя, по тому же UART? Или скрипт объемом поменьше будет? Все операции никак не залезут во FLASH, чтобы потом только кидать команду типа - сделай подогрев с такими-то параметрами? Можно даже перезапись контроллера сделать по UART, не используя штатный бутлоадер. Функция, которая будет перезаписывать флеш переносится в ROM. По UART принимаем новую прошивку, которую функция складывает в свободный флеш. Затем перетирает новой прошивкой старую прошивку, и ресетит контроллер. Разве что расход флеша увеличится вдвое, но такое вполне работает, причем новую прошивку можно получать по любому каналу данных, от UART до Ethernet.

0

Сообщение от Hotd А грузить исполняемый участок кода в ROM никак нельзя, по тому же UART? Или скрипт объемом поменьше будет? Все операции никак не залезут во FLASH, чтобы потом только кидать команду типа - сделай подогрев с такими-то параметрами? Можно даже перезапись контроллера сделать по UART, не используя штатный бутлоадер. Функция, которая будет перезаписывать флеш переносится в ROM. По UART принимаем новую прошивку, которую функция складывает в свободный флеш. Затем перетирает новой прошивкой старую прошивку, и ресетит контроллер. Разве что расход флеша увеличится вдвое, но такое вполне работает, причем новую прошивку можно получать по любому каналу данных, от UART до Ethernet.

это будет алгоритм без права на ошибку. любой сбой в процессе приема и вуаля - флэш уже испорчен, а в раме лишь маленький кусочек кода (4к рам против 16к флэш)
и усе, гарантийный случай с ремонтом у производителя

а вот идея грузить бинарный машинный код в рам с тем, чтобы гарантированно не попортить флэш - по моему вполне вариант
но опять же, если речь идет о независимости от средств компиляции (предполагаю, что это одна из задач ТС) то не вариант

0

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

0

Сообщение от Hotd В процессе приема мы грузим прошивку в нерабочую область флеша, с помощью функции, которая висит в ROM, потом проверяем контрольные суммы, и только после этого переписываем родную прошивку. Если прошивка придет битая - можем еще раз её запросить.

под двойным расходом флэш подразумевалось, что основная прошивка должна быть не более 8к, а 8к надо держать свободными как буфер?
аа я тогда это не уловил с первого прочтения

0

http://dunkels.com/adam/ubasic/ или http://www.stroustrup.com/dc.c вполне можно допилить до нужного состояния очень простеньекого интерпретатора с минимальным потреблением памяти.

0

С бутлоадерами OTA все гораздо проще, чем вам кажется.

Делается обычный "построчный" бутлоадер, с принудительным выходом в него из приложения. Естественно, бутлоадер должен поддерживать коммуникационные интерфейсы, как правило это тот же интерфейс, который обычно используется для взаимодействия с устройством. Бутлоадер работает вместе с ответной частью на хосте. Прошивка принимается "построчно", то есть небольшими блоками, проверяется целостность блоков, после чего они пишутся в постоянную память. По окончании процесса все проверяется целиком, и перезапускается в режиме приложения.

Если что-то произойдет в процессе загрузки, она просто повторяется, потому что с бутлоадером при этом ничего не происходит. Восстанавливаете канал, и прошиваете заново.

Если нужна еще большая надежность - бутлоадер делается на пару приложений. То есть за раз шьется только одно, второе гарантированно работоспособно. Аналог Dual BIOS в некоторых материнских платах. Чаще всего это излишне, особенно "на этапе отладки". Впрочем, вполне возможно, тем более что ТС явно готов пожертвовать ресурсами МК. Можно даже сделать так, что работа основного алгоритма в процессе прошивки не прервется.

У меня таким образом работают реально большие и сложные системы, эта часть не создает никаких проблем.

0

Ну, ну - вызов бутлоадера из приложения!
Неудачно прошились - не запустится приложение, прощай бутлоадер...

Бутлодер должен всегда запускаться первым!
При запуске проверяем некое условие и принимаем решение - запускать приложение или перепрошивать.

0

Сообщение от okotimiv С бутлоадерами OTA все гораздо проще, чем вам кажется.

не спорю. Я умею бутлоадеры. Вариант рассматривался. Не нравятся две вещи:
1. на время обновления прошивки процесс нужно останавливать, выходы переводить в безопасное состояние
2. чтобы собрать прошивку, на компе надо иметь тулчейн. Кроссплатформенность, бла-бла.

0

Сообщение от Pymkvym Ну, ну - вызов бутлоадера из приложения! Неудачно прошились - не запустится приложение, прощай бутлоадер...

имеется в виду, что бутлоадер запускается при старте процессора, проверяет и запускает аппликуху. А вот в работающей аппликухе есть команда выхода в бутлоадер.
Если аппликуха поломана, то она не запустится.

0

Тоже озадачивался выполнение скриптов либо байт-кодов.
Тема интересная.

0

Сообщение от Stiit.mi Сообщение от Pymkvym Ну, ну - вызов бутлоадера из приложения! Неудачно прошились - не запустится приложение, прощай бутлоадер...

имеется в виду, что бутлоадер запускается при старте процессора, проверяет и запускает аппликуху. А вот в работающей аппликухе есть команда выхода в бутлоадер.
Если аппликуха поломана, то она не запустится.
Не надежно, ИМХО - зависло приложение - и усё!
Не... пусть будет такой вариант, но полагаться на него на 100% нельзя.

0

Сообщение от okotimiv С бутлоадерами OTA все гораздо проще, чем вам кажется.

а если все таки аккуратно складывать полную прошивку в буфер, там проверять и только после этого затирать приложение?
при этом складывать в буфер может само приложение используя более высокий уровень протокола, чем можно сделать на бутлоадере
даже если тот же физический интерфейс, хотя можно использовать и другой, более сложный (ethernet например)
и только после этого передавать управление бутлоадеру который буфер зашьем вместо приложения и запустит его

конечно это как писал выше Hotd - двойной расход флэш. Но затраты не существенные, или МК с двойным запасом или внешний флэш

0

Давайте не будем уводить в сторону - бутлоадеры я бы тоже обсудил с удовольствием, но тема другая.

0

Я склоняюсь к байт-коду.
То есть пишем некий "компилятор" который с "человеческого" языка формирует набор кодов.
А в прошивке работает switch/case - машина.

0

Сообщение от Stiit.mi 2. чтобы собрать прошивку, на компе надо иметь тулчейн. Кроссплатформенность, бла-бла.

мое предположение оправдалось)

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

0

Ну парсить простые команды несложно.
Ресурсов даже у этого камня - хватит.
В том числе - с передаваемыми аргументами.

А вот как сделать условные/безусловные переходы (не линейное исполнение скрипта) или вызывать для выполнения другой скрипт - тут уже интересней.

С переменными опять же - как быть?

0

Использовать принцип программирования как в калькуляторах, типа МК-34/54. Там и ветвления и переменные и кодом ничего нельзя испортить. И реализуется просто. Только добавить команды специфичные работе устройства, вроде считать температуру, включить лампочку.

0

Сообщение от PRS Использовать принцип программирования как в калькуляторах, типа МК-34/54. Там и ветвления и переменные и кодом ничего нельзя испортить. И реализуется просто. Только добавить команды специфичные работе устройства, вроде считать температуру, включить лампочку.

Кстати да, а для переменных использовать регистры общего назначения как X, Y в калькуляторах и стек LIFO

0