Руководство по разработке протоколов, совместимых с прямой связью? - PullRequest
4 голосов
/ 23 июня 2010

Я работаю над протоколом связи между встроенными устройствами. Протокол определенно потребует новых команд и полей в будущем. Что мне нужно сделать, чтобы убедиться, что я не рисую себя в угол?

Ответы [ 4 ]

6 голосов
/ 24 июня 2010

Это широко открытый вопрос. Вот несколько случайных мыслей по этому поводу:

  1. Оставь запчасти.
  2. Используйте очень простой заголовок с полем «число байт для следования».
  3. Если есть перечисленные типы сообщений, убедитесь, что поле типа может вместить рост.
  4. Если вы используете битовые флаги, оставляйте запасные.
  5. Возможно, включить сообщение «необработанные данные», которое можно использовать для переноса любого протокола, придуманного будущими поколениями.

В итоге, Оставьте запчасти.

1 голос
/ 03 июля 2010

Если это вообще возможно, позвольте человеку на одном конце кабеля выяснить, что находится на другом конце кабеля. В идеале человек мог бы подключить немой терминал и трижды нажать на клавиатуру (введите вопросительный знак Enter), а затем вернулось бы длинное подробное сообщение с описанием, что это за машина, каков ее номер модели, название и номер телефона и веб-сайт организации, которая его создала, «официальный» номер версии протокола и неофициальное время сборки:

__DATE__ ": " __TIME__

Также отправляйте одно и то же подробное сообщение при каждой загрузке машины.

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

  • Ограничьте себя символами, которые человек может читать и печатать. Избегайте специальных управляющих символов. Воспользуйтесь силой простого текста .
  • Всегда отправлять CR + LF в конце каждого пакета (как предписано многими интернет-протоколами).
  • Принимайте символы с любой скоростью, от максимальной скорости загрузки файлов с ПК до человека, не набирающего текст, медленно клюющего на клавиатуру.

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

0 голосов
/ 24 июня 2010

Я бы использовал HDLC .Я имел удачу с этим в прошлом.Я бы для последовательного соединения просто использовал Асинхронное кадрирование и забыл обо всех других элементах управления, поскольку это, вероятно, было бы излишним.

В дополнение к использованию HDLC для кадрированияпакет.Я форматирую свой пакет следующим образом.Вот как параметры передаются с использованием 802.11

U8 cmd;
U8 len;
u8 payload[len];

Общий размер каждого пакета команд составляет len + 2

Затем вы определяете команды, такие как

#define TRIGGER_SENSOR 0x01
#define SENSOR_RESPONSE 0x02

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

Поэтому, собрав все вместе, пакет будет выглядеть следующим образом.1018 *

Затем система будет следить за последовательным потоком для флага 0x7e, и когда он будет там, вы проверяете длину, чтобы увидеть, является ли он pklen> = 4 и pklen = len + 4, и является ли crc действительным.Примечание: не полагайтесь только на crc для небольших пакетов, вы получите много ложных срабатываний, также проверьте длину.Если длина или crc не совпадают, просто сбросьте длину и crc и начните с декодирования нового кадра.Если это совпадение, скопируйте пакет в новый буфер и передайте его в вашу функцию обработки команд.Всегда сбрасывайте длину и crc при получении флага.

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

Так, например, сенсорное устройство может иметь таймер или отвечать на команду, чтобы выполнить чтение.Затем он отформатирует пакет и отправит его на ПК, и ПК ответит, что получил пакет.В противном случае сенсорное устройство может повторно отправиться по тайм-ауту.

Также, когда вы выполняете передачу по сети, вы должны проектировать его как сетевой стек, такой как OSI modle .HDLC - это канальный уровень , а RPC и обработка команд - прикладной уровень .

.
0 голосов
/ 24 июня 2010

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

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

Все эти требования и ограничения ресурсов, безусловно, будут ограничивать систему, и тогда вы сможете начать выяснять, что протокол будетнеобходимость.Как только вы узнаете эти проблемы, вы сможете спроектировать, как некоторые требования могут измениться / расшириться в будущем.Оттуда вы можете разработать протокол для учета (или нет) наихудших вариантов использования.

...