Я обещался написать, что делать, если вы купили то, что на фото, и тоже думали, что это трехканальный hi-end измеритель тока-напряжения. В чем проблема с этим модулем. На нем стоит чип INA3221, это неплохой трехканальный токоизмеритель. Открыв даташит, мы увидим, что у него есть 3 канала, обозначенные парами CH+ и CH-.

По описанию очевидно, что эти каналы цепляются по обоим сторонам шунта и, по сути, единственная их задача состоит в том, чтобы измерять разницу напряжения между каналами. Зная эту разницу и напряжение на CH+, микросхема может посчитать ток канала. Такой вот метод измерения называется hi-end, т. е. в разрыв некоего произвольного проводника сверху схемы питания. Взяв этот модуль в руки, я вообще вначале не понял, как его использовать, а потом до меня дошло, что за каким-то невиданным хреном из него сделали low-end. Т. е. один из его каналов всегда замкнут либо на VCC, либо на GND. Таким образом, это просто отрубает всю прелесть INA3221 и позволяет его использовать только либо на входе, либо на выходе тока с устройства. То есть, если попросту, либо сразу после батарейки, либо прямо перед. Мотивы такой схемотехники мне непонятны, буду благодарен за пояснения. Благо обратное его превращение в hi-end оказалось делом нескольких движений скальпелем. На фото сверху синим обозначена дорожка, которая замыкает все CH- на GND. Нужно отвязать ее от шунтов, перерезав в указанных красной линией местах, и паяться прямо к шунту. Левая сторона шунта просто замкнута на ближайшую дырку, а правая теперь никуда не ведет, поэтому к ней паяем второй провод. После этого модуль начинает мерять ток/напряжение в разрыве произвольного проводника на схеме. На практике это безобразией будет выглядеть вот так.

Надеюсь что эта информация кому-нибдь пригодится.

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

Железо

Итак, железо — ESP32C6. В представлении не нуждается, платформа хорошо известна любому инженеру. Почему С6, а, скажем, не S3? В дальнейшем я хочу реализовать для Bulerom полноценный TDMA MAC, а значит, мне для этого потребуется физический драйвер радиоканала. В инфраструктуре ESP32 такой драйвер имеется — IEEE 802.15.4. Именно на этой истории основан почти весь современный стек ZigBee и Thread. И именно его я хочу использовать для того, чтобы заставить Bulerom работать там, где не будут работать другие сети. Возможно, я ошибаюсь, тогда мне придется копнуть еще глубже, но уже в сторону NRF, которые дают доступ еще ниже, на уровне регистрового управления трансивером. И ESP32C6 как раз поддерживает IEEE 802.15.4, в отличие от других моделей серии.

Сетевой слой

В качестве тестового сетевого слоя я взял ESP-NOW, он идеально ложится на текущую задачу. Если кратко, у Wi-Fi есть так называемые Control Frames (CF) — фреймы, предназначенные для рассылки по сети служебной информации. Для получения такого пакета не нужно устанавливать соединение MAC-уровня. Т. е. если для того, чтобы отправить данные по Wi-Fi, вам нужно сначала произвести сканирование, потом инициировать соединение, и только после этого вы сможете выполнять обмен данными, то для CF это не требуется. У него есть расширение — Vendor Specific Action. В котором, собственно, и реализуется вся логика ESP-NOW. Плюс ко всему этому, CF могут быть еще не только unicast, но и broadcast. Что это значит для моей задачи: у меня есть драйвер сети, который позволяет отправить unicast произвольному узлу в зоне радиовидимости или broadcast всем узлам вокруг. При этом вся логика MAC-уровня полностью инкапсулирована в Wi-Fi слое. Идеальное решение для задачи тестирования L3 Burelom.

Ну и очевидно, что если отходить от темы статьи, ESP-NOW — это очень хороший способ быстро и надежно связать несколько устройств по воздуху. При этом ESP-NOW разделяет канал с Wi-Fi (по сути, это просто Wi-Fi с плагином). Т. е. он никак не мешает работе модуля с основным драйвером Wi-Fi, можно подключить устройство, например, к роутеру и использовать его как шлюз в интернет, параллельно принимая данные по ESP-NOW. Условие только одно — чтобы было разделение частотных каналов.

В общем, этими средствами можно очень быстро развернуть работающую IoT-сеть. Но это не наши методы. Поэтому роль ему отводится только в качестве псевдо-MAC.

Псевдо-MAC и адаптация к ESP32

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

• Cipher: функции аппаратного шифрования

• Mac: программно зависимые функции L2 уровня

• Rand: аппаратно специфичный истончик энтропии

Собственно, в целевом решении под имплементацией Mac подразумевается именно реализация L2 уровня сети. Т. е. в случае ранее упомянутого IEEE 802.15.4 это будет полноценный TDMA драйвер, задача которого будет забирать данные из L3, планировать их в расписание, собирать входящие фреймы и передавать их на уровень L3. ESP-NOW — это уже реализованный вендорский L2, поэтому моя задача тут сводится к тому, чтобы просто сделать адаптер между Burelom и драйвером ESP-NOW. Поэтому он называется у меня Псевдо-MAC, потому что по сути ничего сам на L2 не делает.

За деталями реализации вы можете сходить ко мне в репозиторий. В принципе ничего сложного для понимания там нет.

Тестовый стенд и методика

Тестирование сети проводилось (должно было проводиться) в трех режимах:

1. 1-Hop. Прямая связь между двумя устройствами. Тут всё просто: A отправил пинг на устройство в радиовидимости (B), получил ответ. Доказывает то, что сеть работает на уровне линка.

2. 2-Hop Routing. Это проверка AODV-маршрутизации. Задача тут усложняется, сети нужно найти маршрут до узла от узла А до узла С, при том, что они находятся вне прямой радиовидимости. Для этого по сети должен пройти Routing Request и простроить маршрут на промежуточном узле B. Доказывает, что сеть умеет выполнять динамическую маршрутизацию.

3. Multihop. Узел A отправляет пакет на узел C. Сеть должна простроить маршрут через два промежуточных узла B, С. Каждый узел сети виден только соседнему узлу. Доказывает, что сеть может транслировать данные в режиме mesh.

Результаты тестирования

Тестировал я всё это дело в три этапа. Первым этапом было создание звезды, чтобы было понимание, что у узлов 2-4 имеется линк к 1. Этот этап был пройден без осложнений.

Далее я попробовал построить мультихоп дома, поскольку живу в современной многоэтажке, имеются стены толщиной 70 см. Получилось собрать некоторое подобие меша, используя изгибы стен. На этом этапе устранил несколько ошибок. Вообще вот сколько себе говорю, никогда не вызывай unwrap() в Rust, даже если кажется, что ничего не может случиться, оно случится!

Ну и завершающим этапом тестирования должно было стать тестирование схем 2 и 3 на естественном рельефе, для этого я отправился в парк около дома. Но там я столкнулся с очень значительными сложностями. Сложности свелись к тому, что ко мне подошли два охранника парка и попросили объяснить, что я делаю. После попыток такового объяснения мне сообщили, что ничего не поняли и с их точки зрения я выгляжу крайне подозрительно. А учитывая известную всем ситуацию, может быть, я тут занимаюсь диверсионной деятельностью или делаю что-то, связанное с дронами. И что, вероятно, им из соображений бдительности стоит вызывать Росгвардию. На все попытки объяснить им, что диверсионность моих железок не большая, чем у домашнего Wi-Fi роутера, они не реагировали. Поэтому мне пришлось срочно ретироваться. Хорошо хоть хоть их «бдительность» осталась только на словах, а то, возможно, я бы это сейчас не писал, а рассказывал архитектуру ESP32 какому-нибудь дознавателю.

Но за то время, что успел там пробыть, было получено вот это:

11.379 [INFO ] Send ping Ping to 4
11.380 [INFO ] <1> Initialized route request dest=4
11.385 [INFO ] <1> Received transit preq packet from=1, packet dropped due seen
11.398 [INFO ] <1> Created route target=4, gateway=2, hops=3
11.398 [INFO ] <1> Received target prep packet from=4
11.399 [INFO ] <1> Route request completed dest=4 gw=2
11.399 [INFO ] <1> Send dataghram dest=4 gw=2 data=50696E6731

Hops=3, route request прошел два промежуточных узла вперед и назад, собственно, это чего я и хотел увидеть. Качество PCB антенн ESP32, конечно, никакое, при этом оно разнится от модуля к модулю. Потому что в схеме линией узел 4 периодически получал hello-пакеты от 2. Т. е. 2 видел 3 и 4, а 4 видел только 3. Это приводит к ошибкам маршрутизации. Потому что прорвавшийся пакет от 4 к 2 создает новый более короткий маршрут, узел 2 начинает считать, что 4 на расстоянии одного хопа, а это более приоритетный роут. А затем линк пропадает, и маршрут оказывается в подвешенном состоянии до его обнуления по бездействию. Надо бы придумать какой-то защитный механизм от залетных hello-пакетов.

В общем, Burelom работает на железе. Конечно, использование ESP-NOW на PCB-антеннах — чушь полная. Но это сильно упрощает тестирование, буду работать дальше в сторону расширения возможностей сети.

P. S.

Инцидент с «бдительными» гражданами требует очень серьезного осмысления, потому что как будто бы имеется совершенно реальный шанс привлечь к себе внимание соответствующих спецслужб. Возможно, стоит обратиться к этим самым спецслужбам за разъяснением, как добросовестному инженеру не загреметь в диверсанты, проводя практику в собственном дворе.

Сей сказ о том, что как я сенсорную сеть “изобретал”. Изобретал в кавычках потому что в общем-то технология эта уже достаточно зрелая, применяется в промышленности и придумывать что-то принципиально новое в ней сложно. Но у меня есть замечательная страсть к строительству велосипедов и собиранию граблей, поэтому в путь!

Что это и зачем нужно? Представим себе следующую задачу. Лето, активный сезон шашлыков и туристических прогулок. Все везде жгут костры, несмотря на особые режимы и драконовские штрафы. В жару, при высоком уровне пожарной опасности поджечь лес от обычного костра даже в трезвом состоянии не самая сложная задача, достаточно просто неправильно выбрать место под него или недоглядеть. И всё, начинается пал лесной подложки, который расползается по лесу и потушить его самостоятельно нет никакой возможности. А если на пути пала встретятся торфяные почвы, сухостой, это сильно усложняет ситуацию. Реагировать на каждый дымок в лесу пожарная охрана не может, у нее нет достаточного человеческого ресурса для этого. А если и реагируют то зачастую по месту прибытия оказывается группа мирно сидящих у костра туристов. Т е понять где реальный пожар а где контролируемый костер на начальных этапах почти невозможно. Ресурсы органов охраны лесов тратятся, леса продолжают гореть. А теперь представьте себе, по лесу была бы раскинута сеть устройств, которые работают годами без техобслуживания от солнечных панелей, собирают информацию о температуре, влажности воздуха и почвы, уровне CO2, скорости ветра, дисперсиях, могут подключать в случае необходимости тепловизор. Всё это связано между собой и через сетевые шлюзы отправляет данные в облако (или на edge севера). А там применив заточенные под эти цели ML модели, можно на выходе получить очень конкретный ответ на вопрос - а что это там за дым на горизонте? Это отдыхающие разожгли очередной костер на поляне на которой уже жарят шашлыки 50 лет без инцидентов, или пора ехать тушить реальный пал. Пример конечно утрированный, в реальности всё обстоит чуть более сложно, но чтобы уловить смысл зачем эти технологии нужны достаточен.

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

1. Электроэнергия это очень дефицитный ресурс. Всё что мы имеем в распоряжении это дай бог 5-15 вт солнечную панельку, которая кое-как проработав полдня, должна накопить достаточно энергии что что бы устройство проработало… Да бог знает сколько, может завтра снег пойдет и панелька окажется в сугробе. Соотвенно вся электронная база должна иметь минимальные паразитные токи. Тут счет идет на микроамперы, если использовать на в устройстве широко распространенные компоненты общего назначения, оно не проживет в таком режиме пары дней.

2. Устройство будет печься под зноем, заливаться дождями, и леденеть в тридцатиградусный мороз. Из этого следует что у него в составе должны быть компоненты которые поддерживают такие режимы эксплуатации (пламенный привет Li Ion аккумуляторам…).

3. Мы имеем дело с очень плохой радиосвязью и большими площадями. Наличие на пути сигнала леса, холмов/гор, представляют для него очень серьезное препятствие. Также нужно понимать что даже квадрат 10x10 км, это 100 кв. км площадей. И даже если повтыкать узлы через каждый километр, это непреодолимая дистанция для решений применяющихся в городской среде (к примеру в том же городском ZigBee). Поэтому мы вплотную сталкиваемся с вопросами усиления сигналов через внешние антенны и его трансляции на значительные дистанции.

4. Неустойчивость инфраструктуры. В таких жестких условиях эксплуатации любой узел в любой момент времени может приказать долго жить. Получить доступ к нему может оказаться задачей экспедиционного уровня (если это например узел находящийся на каком нибудь горном перевале или в глубокой тайге. Поэтому необходима предельная устойчивость сети к локальным травмам.

В общем-то с последнего пункта требований я и решил начать изобретать свой велосипед. Для решения таких задач применяются беспроводные сети с топологией - mesh. Такая сеть представляет из себя сетку, по которой строятся маршруты от одного узла до другого через промежуточные узлы, которые являюсь полноценными участниками сети, могут ретранлировать данные предназначенные для других узлов. Ядром такой сети является протокол маршрутизации - как ретрансляторы понимают, куда им направить пакет предназначенный для другого узла. Протоколов этих несколько, но для текущей задачи я выбрал AODV. Узел A желает понять куда (кому из ближайших нод, это называет шлюз) ему нужно передать пакет чтобы он достиг узла Б. Для этого он широковещательно закидывает в сеть пакет - узел Б откликнись. Получившие его ближайшие узлы, делают то же самое, соседние то же. И так пакет разлетается по сети пока не он не попадет на узел Б. К этому моменту информация о кратчайшем маршруте бедует уже храниться на промежуточных узлах (за счет прохождения поискового пакета). Всё что нужно сделать узлу Б, отдать в шлюз из которого пришел пакет сообщение - привет, я тут. Опять же очень упрощенное описание, есть много нюансов вроде TTL, hops, seen_packets, и прочее, но для понимания сути оно не нужно. Данный протокол был выбран мной на том основании, что в сенсорной сети которую я проектирую, практически нет подвижных узлов, а значит маршруты являются по большей части статичными. Они устаревают только тогда когда какой-то узел уходит с радиолинка. Поэтому AODV практически не дает служебного трафика в сравнении с другими типами маршрутизаций.

Кто-то может возразить что меш сеть это моветон для энергоэффективных устройств, много служебного трафика, большие пакеты. Но тут важно сделать уточнение. Меш сеть это уровень L3 модели OSI, а значит что она ничего не знает о физическом канале по которому проходят ее пакеты. За это отвечают уровни L2 (MAC) и L1 (PHY). На физический уровень я повлиять не особенно не могу. А вот уровень линка находится под моим полным контролем, а значит я могу управлять временем - когда и в каком количестве передаются данные. Таким образом я могу могу через управление трансивером сделать например heartbeat сеть, которая функционируют в определенные временные промежутки, например 55 секунд из 60 сеть молчит, 5 секунд происходит радиообмен. Или более серьезные решения вроде TDMA. Таким образом я получаю очень большое пространство маневра для работы над связкой L3-L2, что может дать приемлемый результат для меша в сенсорной сети.

И так, что было мной сделано на этом этапе. Бала сделана заготовка меш сети и оттестирована в эмуляторе (скришнот из него ниже), а именно реализовано:

• Полная связность сети, пакеты могут проходить от узла к узлу в мультихоп режиме.

• Полность релазиован протокол динамической маршрутизации AODV.

• Реализован механизм beaconing, распространения данных об узлах по сети и соответственно поддержка node discovery и построения локальной топологии сети.

• Базовое шифрование полезной нагрузки пакетов.

• Механизм шлюзования или сопряжение с сетью другого рода.

Касательно аппаратной платформы под которую она предназначается. Всё это создается в инфраструктуре rust, embassy и embedded-hal. Соответственно основная шестерка продуктов которые активно участвуют в развитии этого стека - STM32, NRF, ESP32, TI, NXP, RPI. Я лично таргетируюсь на ESP32, как на платформу наиболее подходящая для быстрого прототипирования и на NRF, которая являются эталоном в сфере устройств с низким энергопотреблением.

С исходным кодом меш сети и эмулятора можно ознакомиться в моем GitHub.

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

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

Что это и зачем

Начну как обычно с цитаты:

mruby is the lightweight implementation of the Ruby language complying with part of the ISO standard. mruby can be linked and embedded within your application.

Словом, это такая особенная реализация языка Ruby, с упором на встраивание и встраиваемые системы — да да, тот самый «кровавый embedded», где царствует чистый C, ссылочная арифметика, malloc() и прочие кошмары и ужасы для современного разработчика.

И вдруг в этом царстве Аида появляетесь вы весь в белом и пишете что-то такое, высокоуровневое:

extend Yeah::DSL
set port: 3000

get '/hi/{name}' do |name|
"Привет #{name}"
end

ENV['SHELF_ENV'] = 'production'

puts "Запуск.."
__main__ [0]

И.. оно просто работает:

И даже вот так:

Круто?

Сколько там пудов соли нужно скушать, чтобы так просто работать с юникодом из чистого С, тем более в embedded среде?

Кстати вся эта «радость хипстера» еще и собирается в очень небольшой бинарник:

Внутри будет «все и сразу»:

MRuby, все используемые библиотеки и само приложение.

Хотя на ЛОРе заметили, что «640кб хватит на всех» это как‑то многовато будет, все же напомню что мы живем в мире копеечных 128Гб флешек и битва за каждый байт свободного места уже не так актуальна как 10 лет назад.

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

Поддерживаемые платформы

К сожалению не удалось найти одним списком все поддерживаемые MRuby платформы, поэтому ограничусь только конкретными найденными примерами.

Из самого интересного:

разработка для Sega Dreamcast и Nintendo Wii, для POS-терминалов, встраивание в iOS приложения.

Ну и собственно встраиваемые системы:

1. ESP32 , шаблон проекта находится вот тут.

1. RP2040 (Raspberry Pi), пример проекта находится тут.

2. PIC32, пример вот тут.

Тестовый проект

Поскольку «малинки» в очередной раз под рукой не оказалось, было решено реализовать тестовый проект на банальном x86 — была собрана вся цепочка разработки, включая фреймворки, был реализован «Hello world» в виде веб‑приложения, работающего на встроенном веб‑сервере.

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

Для тестового проекта использовалось вот это «чудо»:

Yeah! is a DSL for quickly creating shelf applications in mruby with minimal effort

Если кратко, то это своеобразная попытка реализовать «мини‑Rails, работающий на мини‑Ruby». Вполне себе успешная, надо отметить.

А теперь самое важное:

Фреймворки для mruby представляют собой надстройку, которая в процессе собирает сам mruby и добавляет себя в собираемые бинарники.

Звучит сложно и выглядит страшно, но для embedded-среды является привычным делом.

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

Для сборки фреймворка Yeah! требуется внешний «большой» Ruby и rake, будут работать как 2.x так и 3.x версии.

Клонируем проект с фреймворком Yeah!:

git clone https://github.com/katzer/mruby-yeah.git

Поскольку по‑умолчанию собирается только компилятор mirbc, без интерактивной консоли (mirb) и интерпретатора (mruby), чего не хватит для нормальной разработки конечного приложения, добавляем в файл build_config.rb:

conf.gem :core => 'mruby-bin-mruby'
conf.gem :core => 'mruby-bin-mirb'
conf.gem :core => 'mruby-bin-mrbc'

И запускаем сборку:

rake compile

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

Первая — про заголовочный файл mingw.h:

In file included from /opt/work/tmp/mruby-yeah/mruby/build/repos/host/mruby-r3/r3/src/memory.c:34:
/opt/work/tmp/mruby-yeah/mruby/build/repos/host/mruby-r3/r3/src/mman.h:15:10: fatal error: _mingw.h: No such file or directory
15 | #include <_mingw.h>
| ^~~~~~~~~~
compilation terminated.
rake aborted!

В файле mman.h есть вот такая строка:

/* All the headers include this file. */
#ifndef _MSC_VER
#include <_mingw.h>
#endif

Переменная _MSC_VER не задается при сборке на FreeBSD, поэтому срабатывает вариант по умолчанию — для Windows и MinGW. В качестве исправления, я просто закомментировал этот блок, не заморачиваясь дальнейшими изысканиями.

Вторая ошибка также достаточно банальна и происходит из-за разницы в реализации функции mmap:

/opt/work/tmp/mruby-yeah/mruby/build/repos/host/mruby-r3/r3/src/mman.h:52:9: error: conflicting types for 'mmap'; have 'void *(void *, size_t, int, int, int, OffsetType)' {aka 'void *(void *, long unsigned int, int, int, int, unsigned int)'}
52 | void* mmap(void *addr, size_t len, int prot, int flags, int fildes, OffsetType off);
| ^~~~
In file included from /opt/work/tmp/mruby-yeah/mruby/build/repos/host/mruby-r3/r3/src/memory.c:27:
/usr/include/stdio.h:444:10: note: previous declaration of 'mmap' with type 'void *(void *, size_t, int, int, int, __off_t)' {aka 'void *(void *, long unsigned int, int, int, int, long int)'}
444 | void *mmap(void *, size_t, int, int, int, __off_t);
| ^~~~
rake aborted!

В этом же файле mman.h заменяем:

void* mmap(void *addr, size_t len, int prot, int flags, int fildes, OffsetType off);

на:

void* mmap(void *addr, size_t len, int prot, int flags, int fildes, __off_t);

И повторно запускаем сборку.

Если сборка прошла успешно то в папке build/host/bin будут готовые бинарники:

ls ./mruby/build/host/bin/
mirb mrbc mruby
Теперь с их помощью запускаем сборку уже нашего тестового приложения:

/opt/work/mruby-yeah/mruby/build/host/bin/mrbc -Btest_symbol ~/test.rb

Это сгенерирует файл test.c с вот таким контентом:

#include <stdint.h>
#ifdef __cplusplus
extern
#endif
const uint8_t test_symbol[] = {
0x52,0x49,0x54,0x45,0x30,0x33,0x30,0x30,0x00,0x00,0x01,0x3e,0x4d,0x41,0x54,0x5a,
0x30,0x30,0x30,0x30,0x49,0x52,0x45,0x50,0x00,0x00,0x01,0x0c,0x30,0x33,0x30,0x30,
0x00,0x00,0x00,0xcd,0x00,0x01,0x00,0x05,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x3d,
0x1d,0x02,0x01,0x1f,0x02,0x00,0x2d,0x01,0x02,0x01,0x10,0x02,0x03,0x0e,0x03,0x0b,
0xb8,0x2d,0x01,0x04,0x10,0x51,0x02,0x00,0x57,0x03,0x00,0x2e,0x01,0x05,0x01,0x1d,
0x01,0x06,0x51,0x02,0x01,0x51,0x03,0x02,0x24,0x01,0x51,0x02,0x03,0x2d,0x01,0x07,
0x01,0x06,0x02,0x47,0x02,0x01,0x2d,0x01,0x08,0x01,0x38,0x01,0x69,0x00,0x04,0x00,
0x00,0x0a,0x2f,0x68,0x69,0x2f,0x7b,0x6e,0x61,0x6d,0x65,0x7d,0x00,0x00,0x00,0x09,
0x53,0x48,0x45,0x4c,0x46,0x5f,0x45,0x4e,0x56,0x00,0x00,0x00,0x0a,0x70,0x72,0x6f,
0x64,0x75,0x63,0x74,0x69,0x6f,0x6e,0x00,0x00,0x00,0x0e,0xd0,0x97,0xd0,0xb0,0xd0,
0xbf,0xd1,0x83,0xd1,0x81,0xd0,0xba,0x2e,0x2e,0x00,0x00,0x09,0x00,0x03,0x44,0x53,
0x4c,0x00,0x00,0x04,0x59,0x65,0x61,0x68,0x00,0x00,0x06,0x65,0x78,0x74,0x65,0x6e,
0x64,0x00,0x00,0x04,0x70,0x6f,0x72,0x74,0x00,0x00,0x03,0x73,0x65,0x74,0x00,0x00,
0x03,0x67,0x65,0x74,0x00,0x00,0x03,0x45,0x4e,0x56,0x00,0x00,0x04,0x70,0x75,0x74,
0x73,0x00,0x00,0x08,0x5f,0x5f,0x6d,0x61,0x69,0x6e,0x5f,0x5f,0x00,0x00,0x00,0x00,
0x33,0x00,0x03,0x00,0x05,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x0e,0x34,0x04,0x00,
0x00,0x51,0x03,0x00,0x01,0x04,0x01,0x52,0x03,0x38,0x03,0x00,0x01,0x00,0x00,0x0d,
0xd0,0x9f,0xd1,0x80,0xd0,0xb8,0xd0,0xb2,0xd0,0xb5,0xd1,0x82,0x20,0x00,0x00,0x00,
0x4c,0x56,0x41,0x52,0x00,0x00,0x00,0x16,0x00,0x00,0x00,0x01,0x00,0x04,0x6e,0x61,
0x6d,0x65,0x00,0x00,0xff,0xff,0x45,0x4e,0x44,0x00,0x00,0x00,0x00,0x08,
};

Длинная "сопля" выше - ни что иное как готовый байткод mruby, записанный в виде статичного массива байт.

Параметр -Btest_symbol как нетрудно догадаться отвечает за название этого массива.

А вот так выглядит само приложение для запуска (файл test_stub.c):

#include <mruby.h>
#include <mruby/irep.h>
#include <test.c>

int
main(void)
{
mrb_state *mrb = mrb_open();
if (!mrb) { /* handle error */ }
mrb_load_irep(mrb, test_symbol);
mrb_close(mrb);
return 0;
}

Все что тут происходит это просто выдача байткода интерпретатору mruby при запуске обертки. Обратите внимание на строчку:

#include <test.c>

Это и есть включение файла с байткодом mruby.

Ну и наконец сборка конечного тестового приложения:

gcc -std=c99 -static -Os -s -I/opt/work/mruby-yeah/mruby/include -I. test_stub.c -o test_program /opt/work/mruby-yeah/mruby/build/host/lib/libmruby.a -lm -lpthread

Если все пройдет успешно, в текущей папке появится финальный бинарник test_program, который я запускал в самом начале.

Эпилог

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

Также как и правительству Японии, которая этот проект финансирует.

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

С нетерпением жду отзывов о реальном использовании.

P.S.

Статья была опубликована на Хабре, оригинал которой доступен в нашем блоге.