Embedded: истории из жизни, советы, новости, юмор и картинки — Горячее

Как я сенсорную сеть изобретал ч.5⁠⁠

3 дня назад

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

ESP32. LDO, питающий схему на 3V3, был вынесен полностью и заменен на back-boost преобразователь на TPS63802 с током холостого хода 11 мкА. Не сказать, что это самый хороший вариант, но он доступен мне прямо сейчас. Более оптимальным вариантом будет TPS63900, но это задачка на будущее. Всё остальное с девкита ESP32 было отправлено на вынос — USB-концентратор, светодиоды и прочее ненужное. ESP32-C5 имеет встроенный JTAG, линии D+ и D- были выведены на сервисный разъем.
MPTT-зарядка на CN3791 была перенесена в точности по даташиту.
INA3221 — так же по даташиту с добавлением RC-фильтров на шунты.
ATGM336H — тут самые радикальные изменения по сравнению с моделью. Убран EEPROM, мне не нужно хранить данные без питания, МК конфигурирует GPS полностью на старте. LNA заменен на усилитель из даташита (AT2659S). VBAT замкнут напрямую на 3V3 схемы, держать отдельную батарейку в аккумуляторном устройстве смысла я не вижу, умер основной аккум — умерло вообще всё, пока не зарядилось.

Было добавлено 4 разъема:

USB 2.0 для внутрисхемного JTAG
К солнечной панели
К аккумуляторной сборке
Разрыв для токоизмерительного щупа для измерения тока в режиме сна

Плату заказал, приедет после праздников, буду собирать.

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

Прошлые посты серии:

Как я сенсорную сеть изобретал ч.4

Как я сенсорную сеть изобретал ч.3

Как я сенсорную сеть изобретал ч.2

Как я сенсорную сеть изобретал ч.1

Показать полностью 2

vyalkin.oleg

Инженериум DIY

Доработка модуля на INA3221⁠⁠

8 дней назад

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

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

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

Показать полностью 3

[моё] Длиннопост Embedded Инженерия Рукожоп

vyalkin.oleg

Инженериум DIY

Как я сенсорную сеть изобретал ч.4⁠⁠

10 дней назад

Сделал макет тестового стенда для изучения энергопотребления. Схема, в общем-то, простейшая: есть устройство, которое изображает из себя автономный узел и всеми силами пытается прожить на аккумуляторе, подзаряжая его солнечной панелью и исполняя различные программные кульбиты вроде ухода в различные режимы сна, жонглированием периферией, радиоканалом и даже физическим отключением частей схемы. Между всем этим делом оно (прошивка) собирает информацию о параметрах электропитания и отправляет эти данные на второй узел, используя mesh Burelom. Второй узел находится на стационарном питании и работает в режиме шлюза. Зацеплен на Wi-Fi роутер и шлет телеметрию от первого узла на сервер. Там она агрегируется и выводится через UI для анализа.

Паразитные токи

Про макет я сказал не просто к слову, а потому что прототипы на девкитах и энергосбережение — это взаимоисключающие понятия. Причина в том, что на этих платах либо используются очень бюджетная периферия, либо они обвешены компонентами, которые не нужны в реализуемой задаче. К примеру, на девкитах ESP32 присутствуют оба их вида. Стабилизатор AMS1117 (и ему подобные) имеет ток собственного потребления 5–10 мА, USB-концентратор CH334 и RGB-светодиод WS2812B — по 1 мА. Каждый индикаторный светодиод — по 5–10 мА. Когда у вас помимо девкита ESP32 на пинборде еще GPS, StepUp, MPTT, INA, это всё накидывает нехилый оверхед на токопотребление, превращая устройство в печку. Текущий стенд в рабочем режиме имеет расход 200 мА/ч. Совершенно безумная цифра для автономного устройства. С одним АКБ 18650 жить ему дай бог сутки, и никакая 5 Вт солнечная панель и софт с режимами сна не выведут его на стабильный режим долговременной работы. Поэтому следующим этапом будет перенос всего этого зоопарка на свою плату, с выкидыванием всего ненужного и подбором правильных компонентов. В общем-то вот именно такую производительность имеют модули Мештастик T-Beam. Я помню, что после жонглирования всеми возможными параметрами прошивки мне удалось достичь ресурса модуля в 30 часов. И это очевидный предел без значительных аппаратных и программных оптимизаций, достижение коих и ставлю себе в задачи. Далее идет в некотором смысле отчет о проделанной работе, как и в прошлых статьях, инженерная графомания, фотографии пинбордов на предметах мебели и ссылки на код.

Узел 1

К железяке было прикручено:

Трехканальный инвалид INA3221 для измерения тока/напряжения (простите, по-другому не могу назвать это поделие).
MPTT контроллер CC3791
Солнечная панель 6v 5w с алика

Почему INA3221 — инвалид. Сам по себе чип — это отличный инструмент для измерения тока/напряжения в промежуточных точках устройства. Ситуация, когда такой измеритель ставится в разрыв произвольного провода, называется hi-end измеритель. Авторы же модуля решили почему-то, что это излишний функционал, и перемкнули все CH- линии на землю, таким образом ограничив модуль применением только в конечных точках (точка стока тока) устройства. Т. е. из отличного hi-end измерителя сделали кропнутый low-end. Пришлось его грубо доработать напильником. Как это сделать в деталях, я расскажу в отдельной статье.

MPTT-контроллер нужен для зарядки Li-Ion аккумуляторов прямиком от солнечной панели. Каналы INA были установлены в разрыв между солнечной панелью и MPTT, между MPTT и АКБ и между АКБ и устройством. Таким образом, устройство стало осведомлено о том, какой ток/напряжение дает солнечная панель, сколько от этого дела уходит на зарядку и сколько потребляет устройство в целом + уровень зарядки АКБ. Итоговое изделие имеет следующий вид:

Программно в нем был реализован простейший PowerManager, который читает INA3221 и преобразует полученные данные в удобочитаемый формат. Дальше они пакуются в proto-объект и выкидываются в меш-сеть к узлу 2.

Узел 2

Аппаратных изменений не приобрел. Программно для него был реализован MQTT-шлюз, реализующий контракт трейта Gateway меш-сети Burelom. Таким образом, всё, что приходит на этот узел, впихивается в соответствующий source-топик брокера. Сделать этот шлюз оказалось не самой простой задачей. Дело в том, что no_std-окружение Rust довольно ощутимо отстает по развитию от std. И если на std по запросу mqtt - крейты валятся как из рога изобилия, то вот для no_std их можно пересчитать по пальцам, да и, как оказалось, в удовлетворительном состоянии находится только один — rust-mqtt. Специально пилящийся для embedded применения. Все остальные либо как-то забагованы, либо реализуются только самый базовый функционал. Удивили клиенты, которые не умеют проводить даже basic-аутентификацию, зачем вообще такое позиционировать как законченную библиотеку? С rust-mqtt тоже, конечно, пришлось знатно повозиться из-за его супер-агностицизма к железу, у него не реализован внутренний цикл обработки mqtt-пакетов. В общем, логично, откуда автор знает, на какой системе это всё будет работать. Пришлось всё это дело написать, и заработало оно далеко не с первого раза. Но как результат, сейчас телеметрия стабильно уходит на сервер.

Второй интересный момент заключался с ESP-NOW. Я до этого уже упоминал, что этот протокол может работать параллельно с Wi-Fi. И вот сейчас открылась новая подробность о том, что, поскольку Wi-Fi ядро ESP32 не умеет мультиканальность, esp_now должен быть локнут на тот же канал, что и станция. А станция локается всегда на канал роутера, который может быть любым, если он жестко не залочен на самом роутере. Т. е. получается интересная картинка, что esp_now узла 2 знает, на каком канале ей сидеть, а узел 1 — нет. При этом канал этот может оказаться совершенно произвольным. Пришлось залочить канал на домашнем роутере, дабы вся сеть не рассыпалась просто оттого, что роутер решил, что ему комфортнее живется на другом канале.

Бекенд

Очень не хотелось тащить в телеметрию PostgreSQL просто по идеологическим соображениям. Но поднимать какой-нибудь Infux для того, чтобы просто поиграть с данными, тоже абсурд. Решил помучить дипсик на тему того, что вообще сейчас в индустрии СУБД для временных рядов. Выяснилось, там прямо золотой век, начиная от распределенного отечественно Clickhouse до локальных микрорешений вроде Chronix. Пораскинув мозгами, пришел к выводу взять tsink, который в зависимости от настроек может прикидываться от локальной файловой tsdb до серверного решения, умеющего в кластерную репликацию. Пока взял его локальную версию, работать с ним, конечно, одно удовольствие.

Фронтенд

Тут всё обычно для Rust экосистемы: мультиоконный Eframe и Tokio. Собственно, скриншот этого UI в шапке поста.

Что дальше?

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

Ссылки

Показать полностью 2

[моё] Инженерия Длиннопост Интернет вещей Компьютерные сети Rust Embedded Микроконтроллеры Esp32 Backend Frontend

vyalkin.oleg

Инженериум DIY

Как я сенсорную сеть изобретал ч.3⁠⁠

18 дней назад

Занялся синхронизацией узлов. Пока цель — просто добиться того, чтобы они имели одинаковое представление о времени. Для этого собрал такой стенд. Узел 1 получает время по GPS. Узел 2 получает время по NTP, узел 3 получает время через синхронизацию от узла 2 по ESP-NOW. Далее поток рассуждений об этом вопросе и весьма обескураживающие результаты практических испытаний.

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

При этом этот сплыв еще сильно зависит от температуры. Т. е. если у вас на улице, скажем, -20 или +40, дрейф будет еще выше. Очевидно, что со стандартными бюджетными кварцами 20-50 ppm уже за сутки вы получите критический рассинхрон даже для наивного хертибита сети. Через месяц он превратится в клюкву — дрейф пойдет уже на минуты. Даже если воткнуть сверхточный кварц, за сутки часы уедут на десятки мс. Для TDMA с микросекундной точностью это хана, уже через 30-40 часов устройство начнет промахиваться мимо слотов.

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

Варианты получения времени можно разделить на два случая. В первом случае некоторое устройство назначается эталонным источником времени и рассылает пакеты синхронизации по сети. Получатели этих пакетов, соответственно, корректируют свои часы в соответствии с эталоном. Помним, что это так называемое монотонное время — количество X (подставить нс, мк, мс...) прошедших с момента старта эталона. Во втором случае сеть работает на основе глобального времени UTC. И получает это время устройство либо самостоятельно, либо через синхропакеты от устройств, которые его уже получили самостоятельно. Самостоятельно устройство может получить UTC может двумя способами: через GPS или через NTP.

Для получения времени по GPS очевидно нужно, чтобы устройство было снабжено GPS-приемником, в моем случае это ATGM336H. И устройство должно видеть спутники для установления фикса (устойчивого пространственного позиционирования). Приемник шлет пакеты ZDA, содержащие UTC-время и PPS-сигнал точного момента приема пакета, позволяя реконструировать UTC-время с точностью до микросекунд.

ATGM336H впаянный в один из макетов

Для NTP требуется выход в интернет, благо ESP32 — это мастер подобных выкрутасов, для нее подключиться по Wi-Fi и в интернет сходить — тривиальная задача. Точность сомнительная, хотя драйвер NTP и пытается устранить джиттер (запрос до сервера — обработка — ответ от сервера), получается у него это хреновато из-за асимметричности маршрутов в интернете (запрос идет дольше, чем ответ, или наоборот). Каждый запрос будет давать ошибку в несколько мс. Насколько это критично? Ну чисто умозрительно не то чтобы очень, если грануляция слотов десятки... сотни мс. Для мк точности это, конечно, не проактит. Нужно будет выводить статическое среднее, но до этого мне пока дела нет, с хертбитом бы разобраться.

А что на практике? На практике получилась картина которая требует серьезных размышлений. Я реализовал небольшой планировщик, которые включает светодиод каждую десятую секунду UTC на две секунды. Вспоминаем схему из заголовка статьи и если лень ждать перематываем на 16 секунду, видео 240 fps:

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

18:00 - Вспыхивает светодиод на плате 3
18:07 - Вспыхивает светодиод на плате 2
18:17 - Вспыхивает светодиод на плате 1

Устройство 1 получает время через GNSS, оно имеет крайне высокую точность. Устройство 2 идет в интернет на NTP-сервер по Wi-Fi, возникают ассиметрия и джиттер. Часы вперед на 0.100 / 8 (240f/30f) = 12.5 мс. Далее устройство два передает по тому же Wi-Fi sync-пакет, сеть локальная, пакет широковещательный, джиттера нет, но передача пакета по воздуху занимает 0.070 / 8 = 8.75 мс. Стало интересно, а сколько времени займет NTP на компе.

59 мс — немало, т. е. 12,5 мс — и есть та самая ассиметричность интернет-маршрутов, про которую я писал выше. Какие из этого выводы? Как будто бы то, что если в сети будет имеется несколько точек синхронизации с NTP UTC, это может приводить к довольно ощутимому рассинхрону на очень коротких слотах. Промах в 10–20 мс для TDMA — это ощутимо. В общем, исследование получилось весьма любопытным. Код, который всё это делал, можно изучить тут.

Показать полностью 4 1

[моё] Инженерия Длиннопост Интернет вещей Компьютерные сети Rust Embedded Микроконтроллеры Esp32 Видео Короткие видео

vyalkin.oleg

Как я сенсорную сеть изобретал ч.2⁠⁠

24 дня назад

Продолжаю тему с исследованием сенсорных сетей. Как я рассказал в прошлой части, я реализовал драйвер меш-сети, который прошел успешное тестирование в среде эмулятора и был назван идиоматичным условиям его применения названием 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-Hop. Прямая связь между двумя устройствами. Тут всё просто: A отправил пинг на устройство в радиовидимости (B), получил ответ. Доказывает то, что сеть работает на уровне линка.
2-Hop Routing. Это проверка AODV-маршрутизации. Задача тут усложняется, сети нужно найти маршрут до узла от узла А до узла С, при том, что они находятся вне прямой радиовидимости. Для этого по сети должен пройти Routing Request и простроить маршрут на промежуточном узле B. Доказывает, что сеть умеет выполнять динамическую маршрутизацию.
Multihop. Узел A отправляет пакет на узел C. Сеть должна простроить маршрут через два промежуточных узла B, С. Каждый узел сети виден только соседнему узлу. Доказывает, что сеть может транслировать данные в режиме mesh.

Условие 1

Условие 2

Условие 3

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

Тестировал я всё это дело в три этапа. Первым этапом было создание звезды, чтобы было понимание, что у узлов 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.

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

Показать полностью 9

[моё] Инженер Длиннопост Интернет вещей Rust Embedded Микроконтроллеры Программирование Беспроводные технологии Esp32 Компьютерное железо

vyalkin.oleg

Как я сенсорную сеть изобретал ч.1⁠⁠

29 дней назад

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

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

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

Электроэнергия это очень дефицитный ресурс. Всё что мы имеем в распоряжении это дай бог 5-15 вт солнечную панельку, которая кое-как проработав полдня, должна накопить достаточно энергии что что бы устройство проработало… Да бог знает сколько, может завтра снег пойдет и панелька окажется в сугробе. Соотвенно вся электронная база должна иметь минимальные паразитные токи. Тут счет идет на микроамперы, если использовать на в устройстве широко распространенные компоненты общего назначения, оно не проживет в таком режиме пары дней.
Устройство будет печься под зноем, заливаться дождями, и леденеть в тридцатиградусный мороз. Из этого следует что у него в составе должны быть компоненты которые поддерживают такие режимы эксплуатации (пламенный привет Li Ion аккумуляторам…).
Мы имеем дело с очень плохой радиосвязью и большими площадями. Наличие на пути сигнала леса, холмов/гор, представляют для него очень серьезное препятствие. Также нужно понимать что даже квадрат 10x10 км, это 100 кв. км площадей. И даже если повтыкать узлы через каждый километр, это непреодолимая дистанция для решений применяющихся в городской среде (к примеру в том же городском ZigBee). Поэтому мы вплотную сталкиваемся с вопросами усиления сигналов через внешние антенны и его трансляции на значительные дистанции.
Неустойчивость инфраструктуры. В таких жестких условиях эксплуатации любой узел в любой момент времени может приказать долго жить. Получить доступ к нему может оказаться задачей экспедиционного уровня (если это например узел находящийся на каком нибудь горном перевале или в глубокой тайге. Поэтому необходима предельная устойчивость сети к локальным травмам.

В общем-то с последнего пункта требований я и решил начать изобретать свой велосипед. Для решения таких задач применяются беспроводные сети с топологией - 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.

Показать полностью 1

[моё] Инженер Длиннопост Интернет вещей Rust Embedded Микроконтроллеры Программирование Беспроводные технологии Esp32

user12227879

Кроссплатформенная графическая библиотека для AVR и STM32⁠⁠

1 месяц назад

Библиотека написана с нуля на чистом языке C в GCC и AC6 используя только целочисленную математику и не используя сторонние коды.

На данный момент библиотекой поддерживается два микроконтроллера ATmega128 и STM32F407 на уровне графического интерфейса пользователя GUI (KVB_LCD.h). Графические объекты, написанные на основе GUI библиотеки, будут работать как на 8 ми битном микроконтроллере ATmega128 так и на 32 х битном STM32F407.

Для разработки программного кода библиотекой поддерживаются три среды разработки IDE; Atmel Studio 7.0, STM32CubeIDE v2 и Keil MDK v5.43. Для просмотра тестового презентационного кода под STM32 поддерживаются три платы разработки с разъемом FSMC;

Open407V-D stm32f4-discovery микроконтроллер STM32F407VGT6.

ST STM32F4XX Black v3.0 1606 микроконтроллер STM32F407ZGT6.

ST STM32F4XX Black v2.0 1509 микроконтроллер STM32F407VET6.

Кроссплатформенная графическая библиотека для AVR и STM32

Для просмотра тестового презентационного кода под ATmega128 используются порты ввода / вывода;

PORTC порт (D0-D7) младшего байт шины данных LCD панели.

PORTA порт (D8-D15) старшего байт шины данных LCD панели.

PORTD бит 4 (CS) передача сигнала доступа к LCD панели.

PORTD бит 5 (RD) передача сигнала чтения из LCD панели.

PORTD бит 6 (WR) передача сигнала записи в LCD панель.

PORTD бит 7 (RS) передача сигнала команда/данные LCD панели.

PORTG бит 0 (RST) передача сигнала сброса LCD панели.

PORTG бит 1 (BL) передача сигнала подсветки LCD панели.

Панели LCD

На данный момент написаны драйвера для пяти LCD панелей:

ILI9325 разрешение 320 x 240

ILI9341 разрешение 320 x 240

ILI9481 разрешение 480 x 320

ILI9484 разрешение 480 x 320

OTM8009A разрешение 800 x 480

Расположение выводов разъемов плат и панелей прилагаются в папке “FSMC LCD” в виде документов в формате .xlsx. Вполне возможно, что у Вас могут отличатся разъемы LCD панелей, но разъемы плат должны соответствовать.

Уникальный функционал и авторские алгоритмы

Основной задачей при создании библиотеки ставилось, кроме кроссплатформенности, максимально быстрая отрисовка графических объектов. В отличие от классических библиотек, использующих стандартный по пиксельный вывод, в данном проекте реализованы собственные оптимизированные алгоритмы, разработанные с учетом архитектуры графической памяти (GRAM) дисплеев:

Скоростная отрисовка линий. Используется авторский алгоритм, который рассчитывает сплошные прямые отрезки в наклонных линиях. Это позволяет минимизировать количество команд переключения адресов GRAM LCD панели и осуществлять быструю блочную заливку, что кратно увеличивает скорость отрисовки (FPS).

Отрисовка градиентным цветом. Используется авторский алгоритм, который рассчитывает и заполняет градиентное окрашивание в вертикальном и горизонтальном направлении с линейной или центральной ориентацией за счет аппаратного ускорения GRAM матрицей LCD панели.

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

Графические примитивы

Три формы отображения и регулируемый бордюр. Графические примитивы имеют две независимые поверхности и три формы отображения: 1 = весь примитив, 2 = только регулируемый бордюр, 3 = только внутренняя поверхность. Это позволяет выбирать на экране LCD панели объект, изменяя цвет бордюра, не тратя время на перерисовку внутренний поверхности. Примитивы типа треугольник (равносторонний и равнобедренный) имеют четыре ориентации вершины: 1 = левая, 2 = правая, 3 = вверх, 4 = вниз.

Продвинутая подсистема вывода текста

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

Привязка к базовой линии. Все шрифты привязываются к единой горизонтальной направляющей, нижняя полка символов. Это позволяет собирать одну строку из слов разного размера и цвета, гарантируя идеальную ровность текста.

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

Поддержка табуляции.

Установка кернинга шрифта (меж символьное расстояние) с коррекцией длины пробелов и табуляции.

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

Коэффициент увеличения шрифта.

Выравнивание текста. Выравнивание задается по левому краю, правому краю или центру.

Эффект тени. Тень символа имеет четыре установки. 1 = тень низ справа, 2 = тень низ слева, 3 = тень верх справа, 4 = тень верх слева. Тем самым создается эффект выпуклости или вдавленности шрифта и лучшем образом влияет на читаемость текста.

Круговой контур символов. Четкий контур вокруг каждого символа для читаемости на любом фоне. Можно задать отображение только контура без символа.

Градиентный текст. Плавное окрашивание в горизонтальном или вертикальном направлении с помощью линейной или центральной заливки строки и применению тени или кругового контура.

Графический редактор шрифтов (Windows IDE)

Для создания и кастомизации экранных шрифтов разработано полноценное Windows-приложение, автоматизирующее весь цикл подготовки графических ресурсов:

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

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

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

Сохранение в Си-формат. Генерация готовых `.c` файлов с ультра-компактной последовательной упаковкой данных (символ 9x16 занимает всего 18 байт), полностью совместимых как с `PROGMEM` во Flash-памяти ATmega128, так и с обычными константными массивами в STM32F407.

Авторский пак. С помощью данного редактора создано 23 уникальных русско-английских шрифта (5 базовых включены в презентацию для демонстрации, полный набор и редактор доступны по запросу).

В демонстрационной версии редактора убрана возможность сохранения в Си-формате, полноценный редактор доступен по запросу.

Видео ролик можно посмотреть, оценить скорость работы:

https://rutube.ru/video/80140af8b045d20b939240ea3dab1d8b/

https://dzen.ru/video/watch/6abef71fe272f975e1608878

https://vkvideo.ru/video-241941150_456239018

Полный код проекта и описания можно скачать:

https://github.com/Konstantin-kvb/KVB-Microcontroller-GUI-Library/

Показать полностью 14 2

Stm32 Embedded Микроконтроллеры Программирование Gui Atmega Градиент Lcd дисплей Видео RUTUBE Видео ВК Яндекс Дзен (ссылка) Длиннопост

alex0x08

Arduino & Pi

Ruby и встраиваемые системы⁠⁠

Серия Жестокие эксперименты

3 месяца назад

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

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

Картинка для привлечения внимания, была <a href="https://pikabu.ru/story/ruby_i_vstraivaemyie_sistemyi_14168805?u=https%3A%2F%2Fwww.linux.org.ru%2Fgallery%2Fscreenshots%2F17359154&t=%D0%B2%D1%8B%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B0&h=9a8a66b46743b7807efe1138a0bf4288dbeeea6c" title="https://www.linux.org.ru/gallery/screenshots/17359154" target="_blank" rel="nofollow noopener">выложена</a> на ЛОР.

Картинка для привлечения внимания, была выложена на ЛОР.

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

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

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 среде?

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

2 Мегабайта на все про все.

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

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

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

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

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

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

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

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

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

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

Внешний вид платы <a href="https://pikabu.ru/story/ruby_i_vstraivaemyie_sistemyi_14168805?u=https%3A%2F%2Fwww.elecbee.com%2Fru-23470-ESP32-Development-Board-WiFi-bluetooth-Ultra-Low-Power-Consumption-Dual-Cores-ESP-32-ESP-32S-Board&t=ESP32&h=12a93a311822828b9c62c8f0ac3f4522cf8697f0" title="https://www.elecbee.com/ru-23470-ESP32-Development-Board-WiFi-bluetooth-Ultra-Low-Power-Consumption-..." target="_blank" rel="nofollow noopener">ESP32</a>.

Внешний вид платы ESP32.

RP2040 (Raspberry Pi), пример проекта находится тут.
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.

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

Показать полностью 5

[моё] IT Программирование Разработка Ruby Embedded Интернет вещей Длиннопост

Посты не найдены

1 2 3 4 5 6 7

Паразитные токи

Узел 1

Узел 2

Бекенд

Фронтенд

Что дальше?

Ссылки

Железо

Сетевой слой

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

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

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

P. S.

Панели LCD

Уникальный функционал и авторские алгоритмы

Графические примитивы

Продвинутая подсистема вывода текста

Графический редактор шрифтов (Windows IDE)

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

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

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

Эпилог

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги

Популярные авторы

Сообщества

Теги