Hard Real-Time Scripting Language для MCU

MicroPython, не?

с предсказемоей сборкой мусора или ручное управление памятью.

Первая часть не совсем понятна. Вторая - без GC, т.е. Cи хватит всем.

Если что: https://docs.micropython.org/en/latest/library/gc.html

Не форт ли ты ищешь?

а какой смысл на мк в сборке мусора? там и памяти то нет.

либо си, либо си++, без рантайма и rtti. зачем мкашечку мучать интерпретацией?

ps и потом… hard real time в современной интерпретации всегда обозначает компилируемый код, и почти всегда это си в силу его переносимости и простоты.

В A2 есть потоки реального времени, которые могут продолжать работу во время сборки мусора, хотя там 100%-ная чистота от Си - он там абсолютно не при делах. Потоки реального времени не делают всё приложение жёстко рилтаймовым, но дают возможность выделить часть приложения. Но впрочем это не скриптовый язык, а компилируемый, может и не подойти. Я бы ещё взглянул на tcl - там нет сборки мусора.

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

• Набор инструкций arm на парктике не универсален даже в рамках одной линейки архитектур. Т е если вы возьмете напримерм набор инструкций Cortex-M3 и Cortex-M4 то обнаружите что M3 оперирует урезанным набором инструкций относительно M4. Т е код скомпилиный под М4 скорее всего не будет работать под M3. Я конено не берусь утверждать об этом на 100% так как не было опыта в виде таскания кусокв кода с одного камня на другой без перекомпиляции, но все же скорее всего работать оно не будет и придется каждый раз перекомпилировать код под конкретный мк.
• Второй аспект гораздо серьезнее, это безопасность. Этот по сути сторонний код будет иметь полный доступ ко всему адрессному пространству мк, т е он может сделать по сути что угодно. Для того что бы запретить ему лезть туда куда не надо, придется задействовать MPU, который есть далеко не на всех мк. При этом если его подключить, появляется несколько других проблем. Во первых это то что теперь хип так называемого скрипта должен быть изолирован он хипа ОС и располагаться в заданном пространсте - т е нужно разделение памяти на уровне образа прошивки. Во второных поскольку теперь код не может сходить куда хочет, нужна таблица системных вызовов уровня скрипта, находящаяся за зоной протекции MPU. При этом она явна будет иметь жестко фиксированное положение, так же как и хип. И далее мы выходим на уровнеь компиляции, нужно будет определить эти функции, задать им смещение в памяти мк. В общем задача приобретает настолько сильный оттенок красноглазия, что проще уж тогда все прошивку целиком заменять каждый раз, чем делать в рантайме франкенштейна из разных кусков кода.

Ну а касаемо того что памяти нет, спорный вопрос. Lua работает со всеми своими наворотами требует всего 15кб памяти. Минимальный объем хипа на котором luaшные скрипты будут себя комфортно чуствовать (что бы работали вещи вроде библиотеки string) составляет 100-150кб. Т е 200кб sram по сути гоночный болид для lua.

Я вот тут нашел такую вот интересную штуку, что у lua оказывается можно временно выключить сборку мусора. Надо будет проверить насколько стабильно время выполненения кода с выключенным gc.

elua уже упоминали? https://github.com/elua/elua

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

Второй аспект гораздо серьезнее, это безопасность. Этот по сути сторонний код будет иметь полный доступ ко всему адрессному пространству мк, т е он может сделать по сути что угодно.

Скриптовой язык без GC будет тоже не безопасен.

Скриптовой язык без GC будет тоже не безопасен.

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

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

ps и потом… hard real time в современной интерпретации всегда обозначает компилируемый код, и почти всегда это си в силу его переносимости и простоты.

Я лично понимаю в рамках этой задачи hard real time как - четкая детерменированновть времени выполненения участов кода в виде -> не более чем T временных едениц. Т е очевидно что это будет работать медленее чем код на си за счет накладных расходов на виртуализацию. Но мне нужно четко понимать, что есть допустим функция F которая будет гарантированно выполнена за время не более чем T. И что это T не будет плавать, потому что происходят события вроде gc, или распределения каких-то например очередей событий асинхронно относительно потока скрипта.

Но мне нужно четко понимать, что есть допустим функция F которая будет гарантированно выполнена за время не более чем T. И что это T не будет плавать, потому что происходят события вроде gc, или распределения каких-то например очередей событий асинхронно относительно потока скрипта.

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

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

Так поиграйтесь со сборщиком луа, ведь можно как отключить нафиг, так и взять сборку мусора полностью под свой контроль, донастроить, а в последней версии даже закрытия добавили, поэтому в этом плане опять же всё весьма норм. СМ не догма.

Набор инструкций arm на парктике не универсален даже в рамках одной линейки архитектур

а у каких процессоров он универсален ? а бинарники и даже дистрибутивы тем временем как-то работают у всех

Второй аспект гораздо серьезнее, это безопасность

зачем в таком случае скриптовый язык если есть Rust ? По моему для микроконтроллеров он как раз подойдёт, чтобы не тянуть за уши MPU для 100 строчек кода

за основу lua первых версий - см публикации

и вперёд.

MicroPython

Это щютко? MicroPython штука очень хорошая, но вот годидзя ли? В плане hard real time script lang

Это щютко? MicroPython штука очень хорошая, но вот годидзя ли? В плане hard real time script lang

А какая постановка задачи? И что такое «hard real time script lang»? Начнем с того, что «hard real time» определяется latency. Второй момент, одни микроконтроллеры умеют в приоритеты прерываний, а другие - нет. Что делает GC и в какой момент времени, как это сказывается на задержке и что в этот момент происходит с очередью прерываний и поддерживается ли она вообще? Или контроллер должен строго прервать выполнение задачи?

Нужен полный контроль - для этого есть Asm/С/C++. Если нужна интерпретация - MicroPython или Lua. Оба при этом поддерживают управление GC и многое прочее. Какую задачу ставит перед собой ТС - не ясно из ОП, как и не ясно что за железо он хочет использовать и какой смысл вкладывает в «hard real time script lang».

Я не «железячник», так на уровне хобби. Но, по теме вообще не ясно что конкретно требуется, для каких задач и под какой контроллер. Тут уже Rust советуют, совсем уже идиотизм какой-то, извините.

Возможно, ТС, просто, хочет RTOS (Real-Time Operating System). Например, FreeRTOS. Но, как-то маловероятно, что он не знает о существовании подобного. Он же как раз просит странное «Hard Real-Time Scripting Language для MCU».