Я работаю над протоколом связи между встроенными устройствами. Протокол, безусловно, потребует новых команд и полей в будущем. Что мне нужно сделать, чтобы я не рисовал себя в углу?Рекомендации по разработке передовых совместимых протоколов связи?
Это широко открытый вопрос. Вот некоторые случайные мысли о нем:
Таким образом, Оставьте запасные части.
Вопрос слишком общий для четкого ответа. Есть много аспектов, которые может потребоваться для встроенной системы;
Сколько пэров нужно будет с ними связаться? Сколько данных требуется для связи? Насколько жестко синхронизированы системы? Каковы физические носители протокола и каковы ограничения пропускной способности и соображения восприимчивости к ошибкам?
Все эти требования и ограничения ресурсов, безусловно, сдерживают систему, а затем вы можете приступить к выяснению, что потребуется протоколу. После того, как вы узнаете эти проблемы, вы можете спрогнозировать, как некоторые требования могут измениться/расшириться в будущем. Оттуда вы можете разработать протокол для размещения (или нет) наихудших случаев использования.
Я бы использовал HDLC. Мне повезло с ним в прошлом. Я бы хотел, чтобы серийный номер просто использовал Asynchronous framing и забыл обо всех других элементах управления, поскольку это, вероятно, будет излишним.
В дополнение к использованию HDLC для обрамления пакета. Я отформатирую свой пакет следующим образом. Это, как передаются параметры с помощью 802,11
U8 cmd;
U8 len;
u8 payload[len];
Общий размер каждого пакета командного Len +2
Затем определить команды, как
#define TRIGGER_SENSOR 0x01
#define SENSOR_RESPONSE 0x02
Другим преимуществом является то, что вы можете добавить новые команды, и если вы правильно спроектируете свой парсер для игнорирования неопределенных команд, вы получите некоторую обратную совместимость.
Таким образом, все вместе пакет будет выглядеть следующим образом.
// total packet length minus flags len+4
U8 sflag; //0x7e start of packet end of packet flag from HDLC
U8 cmd; //tells the other side what to do.
U8 len; // payload length
U8 payload[len]; // could be zero len
U16 crc;
U8 eflag; //end of frame flag
Система будет контролировать последовательный поток для 0x7E флага и когда там вы проверить длину, чтобы увидеть, если она pklen> = 4 и pklen = Len + 4 и что КРР действует. Примечание. Не полагайтесь только на crc для небольших пакетов, вы получите много ложных срабатываний, а также проверьте длину.Если длина или crc не совпадают, просто сбросьте длину и crc и начните с декодирования нового фрейма. Если это совпадение, скопируйте пакет в новый буфер и передайте его в свою функцию обработки команд. Всегда возвращайте длину и crc при получении флага.
Для вашей функции обработки команд возьмите cmd и len, а затем используйте переключатель для обработки каждого типа команды. Я также требую, чтобы определенные события отправляли ответ, поэтому система ведет себя как удаленный вызов процедуры, который управляется событиями.
Так, например, сенсорное устройство может иметь таймер или отвечать на команду для считывания. Затем он отформатировал пакет и отправил его на ПК, и ПК ответит, что он получил пакет. Если нет, то сенсорное устройство может выполнить повторную передачу по таймауту.
Также, когда вы выполняете сетевую передачу, вы должны проектировать ее как сетевой стек, такой как OSI modle. HDLC - это data link layer и RPC and command handling is the Application Layer.
Если возможно, позвольте человеку на одном конце кабеля выяснить, что находится на другом конце кабеля. В идеале человек мог бы подключить немой терминал и трижды нажать на клавиатуру (введите Enter-mark Enter), затем вернется длинное подробное сообщение с описанием того, что это за машина, каков ее номер модели, имя и номер телефона и веб-сайт организации, который построил его, «официальный» номер версии протокола, и неофициальное время сборки:
__DATE__ ": " __TIME__
Также отправить то же подробное сообщение каждый раз, когда машина загружается.
Если возможно, попробуйте разработать протокол, чтобы человек с немым терминалом мог разговаривать с вашим устройством. HTTP - один из таких протоколов для чтения человеком, и я подозреваю, что это одна из причин его популярности. удобочитаемое предполагает, среди прочего:
Возможно, вам также стоит взглянуть на список common protocols for embedded systems. Возможно, один уже соответствует вашим требованиям? Есть ли причина использовать что-то более сложное для декодирования, чем стандартное Netstring format?
Я не прошу совета по всему дизайну, просто ищу совет о том, чтобы сделать его надежным. Может быть, лучший вопрос: «Какие конкретные вещи я должен избегать, чтобы сделать передовой совместимый протокол связи?» –