Разработка модели SDK для реального устройства

Доброго времени суток, уважаемые читатели! В этом посте я продолжу начатые ранее рассуждения и затрону сразу 2 задачи из поста: разработка собственного SDK. Этими задачами было: порассуждать о будущем протокола, что его ждёт, куда он будет развиваться и с учётом этого спроектировать модель будущего SDK.

Как я упоминал ранее: устройство общается с компьютером через последовательный порт с помощью специального набора команд. Стандартная посылка выглядит следующим образом: «Xyyyy zzzz\r», где X – действие, yyyy – шестнадцатеричный номер параметра, затем пробе, затем zzzz – шестнадцатеричное значение параметра и, наконец, \r – символ возврата каретки. Действие X это символ, который говорит о том, как надо воспринимать ту или иную посылку. Символ P – означает, что вы хотите установить параметр yyyy в значение zzzz. Символ J – означает, запрос значения параметра у драйвера. Да, драйвер никогда ничего не отправляет на компьютер автоматически. Все действия происходят по инициативе компьютера или ведущего устройства, а драйвер лишь отвечает на запросы. И, наконец, символ K – означает, что эта посылка – ответ драйвера. Драйвер отвечает только на команды типа J ответом типа K. По просьбам заказчиков, для улучшения качества взаимодействия и облегчения взаимодействия драйвера с другими устройствами напрямую были введены дополнения к протоколу обмена данными.

  • Возможность включения возврата нового значения параметра после команды установки нового значения
  • Возможность включения 8-ми битной контрольной суммы в формате CCITT.
  • Возможность переключения устройства из текстового в двоичный протокол.

Рассмотрим подробнее эти режимы. В первом случае всё ясно – после включения опции драйвер возвращает ответ типа K не только на команды типа J, но и на команды типа P. В случае включения контрольной суммы структура посылки выглядит следующим образом «Xyyyy zzzz\rCC\n». CC – контрольная сумма всех предыдущих символов, включая \r; \n – символ конца строки. Драйвер высчитывает контрольную сумму и сравнивает её с CC. В случае их совпадения посылка обрабатывается далее, иначе возвращается ошибка. Ах да, совсем забыл – ещё есть команды типа Exxxx – это ошибка и её код в формате xxxx. Все команды передаются в текстовом режиме, т.е. вы можете набирать их с клавиатуры в консоли. А вот при переключении устройства в двоичный режим, протокол немного меняется: «Xyyzz\rCC\n». Где X – это та же буква, что и ранее, а вот yy и zz – теперь пишутся слитно и имеют тот же смысл, что и ранее, но теперь это 16-битные значения. Они по прежнему вмещают от 0 до 0xffff значений. Контрольная сумма в двоичном протоколе является обязательной. Вот так выглядит наш протокол.

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

Таким образом, я вижу SDK, как набор инструментов, которые позволяют работать как напрямую с драйвером через последовательный (COM) порт; с несколькими драйверами через разные порты или через корзину. Кроме того, должна быть возможность использования контрольной суммы, если это необходимо, режим ответа или бинарный протокол я решил не включать в SDK по некоторым причинам. Я считаю, что автоматически считывать ответ не целесообразно. Пусть у программиста будет возможность выбора – в какой момент какой параметр запрашивать. Кроме того, бинарный протокол при работе с библиотекой не имеет смысла, т.к. пользователь всё равно не участвует напрямую в процессе передачи команд, а значит этот протокол необходим только для управления драйвера от другого микроконтроллера, а не от ПК. И наконец, переход между режимом контрольной суммы и её отсутствия должен быть максимально простым для пользователя – конечно не стоит заставлять программиста считать контрольную сумму самому. А кроме того, надо избавиться от всех этих префиксов и номеров команд, ввести человеко-понятные обозначения, например, set_current и значение yyyy вместо P0300 yyyy.

Ну что-же, приступим? Вперёд к созданию динамической библиотеки!

Разработка модели SDK для реального устройства: 1 комментарий

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

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