Android Dashboard Generator
Интегрированная среда разработки операторских панелей для мобильных устройств
  • Главная
  • Загрузить
  • Блог
  • Документация
  • Личный кабинет разработчика
  • Контакты
  • Главная
  • Загрузить
  • Блог
  • Документация
  • Личный кабинет разработчика
  • Контакты
Android
  • Главная
  • Загрузить
  • Блог
  • Документация
  • Личный кабинет разработчика
  • Контакты

Генерация реализации протокола для микроконтроллера

21.08.2017 Добавить комментарий Написал Александр Петров

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

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

Такой инструмент мы и хотим добавить в пакет MCU Blocks.

Известно, что тема взаимодействия распределенных компонент изучается со времен появления первого программируемого радиокомпонента (а возможно и до этого момента). Есть методы формальных описаний (МФО), есть стандарты ITU (в реализации SDL, MSC, ASN, …), есть модель OSI, есть много еще чего. Всего этого мы обязательно коснемся в других статьях, чтобы сравнить и понять что мы можем использовать, что не можем и где наше место под солнцем. Если вам есть что подсказать нам, прошу оставить комментарий к этой заметке.

Среди прочих работ, посвященных генерации реализаций протоколов, нам попался исследовательский проект LaBRI – University of Bordeaux под названием z2z (презентация, статья, диссертация). Задача проекта — автоматическая генерация кода, реализующего протокольный шлюз. Рассматривается область телекоммуникационных систем. Конкретно в статье рассматривается проблема необходимости реализации шлюза, объединяющего различные протоколы (SIP for telephones, RTSP for televisions, X2D for thermostats, and X10 for lamps), в системах типа Умный дом. В принципе, если мы рассматриваем ситуацию, когда нужно объединить в одну сеть устройства разных производителей и общаться с ними по одному протоколу такая проблема может иметь место. Предлагается использовать 3 разных DSL для описания «protocol behaviors, message structures, and the gateway logic» и последующая кодогенерация в Си + рантайм. Тестирование проводилось на ARM 200Mhz и решение заняло ~200Кб памяти.

Отмечается, что компилятор из DSL в Си производит проверку корректности свойств протоколов (checks essential correctness properties)

  • DSL PS (Protocol spec) описывает свойства протокола (tcp\upd, unicast\multicast, sync\async), описывает маппинг хэндлеров в зависимости от значений, определенных полей входящих сообщений и описывает конструктор исходящих сообщений. Есть отдельная секция для обработки сессий (определяет как идентифицировать запросы в рамках одной сессии)
  • DSL MS (Message spec) позволяет описывать шаблон для разбора приходящих сообщений и шаблон для генерации исходящих сообщений
  • DSL MT (Message translation) — Си-подобный язык для оперирования с входящими и исходящими сообщениями, задания логики работы шлюза

Мы можем представить нашу задачу аналогично данной (см. схему)

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

К этим описаниям (исходным данных для генератора) относятся:

  1. Описание свойств стэка протокола устройства (аналогично DSL PS, но дополнительно еще и указание интерфейса и его свойств)
  2. Описание форматов сообщений, которые “приходят” от устройства (сообщения прикладного уровня стэка протоколов устройства)
  3. Описание API для кода программиста (описание функций и структур данных), через которое код программиста будет взаимодействовать с шлюзом
  4. Описание логики трансляции сообщений (аналог DSL MT).

При этом очевидным, на мой взгляд, развитием подхода является выделение в DSL MT типовых схем трансляции — например, по типам внешних устройств (работа с АЦП, работа с драйвером шагового двигателя, работа с сервером) или по типам взаимодействий (REST или RPC или….) Тем самым мы можем еще больше повысить уровень DSL и подойти вплотную к тому, что сейчас делают в области генерации реализации протоколов в области распределенных высокопроизводительных сервисов (смотри, например, проекты AERON, AJRPC, Aconite — два последних разрабатываются командой проекта Acapella).

  • Презентация проекта
Без рубрики
protocols, z2z
MCU Blocks на выставках в Китае и Германии
Интегрированная среда разработки операторских панелей для мобильных устройств

Добавить комментарий Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Адрес: 152931, Ярославская область,
г. Рыбинск, ул. Карякинская, д. 64
Телефон: 8(980)740-09-01
E-mail: petrov@nppsatek.ru
  • Главная
  • Загрузить
  • Блог
  • Документация
  • Личный кабинет разработчика
  • Контакты

Copyright © 2015 ООО "НПП САТЭК плюс". Все права защищены. Политика конфиденциальности