Как Вы разрабатываете последовательный командный протокол для встроенной системы? [закрытый]

Мне нравятся ответы Брюса МакГи. Поработав с подобными интерфейсами, я могу предложить несколько других указателей:

• При возврате числовых типов в пакете данных, пожалуйста, ПОЖАЛУЙСТА, постарайтесь сделать все в одном формате. Не используйте одинарный для одних чисел и двойной для других. И не делайте его произвольным!

• Приведите примеры пакетов данных в вашем ICD. Ужасно неприятно угадывать порядок байтов или даже порядок битов (MSByte первый или последний? Что первый и последний?). Предоставьте диаграмму, показывающую зависимости пакетов от времени (т.е. сначала отправляется 0x02, затем байт адреса, затем идентификатор сообщения и т. Д.)

• Не переключайтесь между форматами данных, если это вообще возможно. Я работал в системах, которые используют "числа в кодировке ASCII" для некоторых сообщений, где вам нужно удалить начальную тройку байтов, а затем собрать их вместе, чтобы получить действительное число. (Обычно кодирование ASCII используется, когда у вас есть последовательность байтов, которую нужно избегать, например 0x02, 0x04 и т. Д. Кодированные числа будут 0x30, 0x32, 0x30, 0x34. Используйте поле длины, если возможно, чтобы этого избежать, или по крайней мере, делайте это все время!)

• Определенно определенно определенно документируйте скорость передачи, четность и т. д. Если вы используете RS-485, задокументируйте режим шины (2-проводной? 4-проводной?) или любые другие настройки, которые появятся на машине, на которой вы собираетесь это использовать. Если нужно, дайте скриншоты.

Этот интерфейс, вероятно, будет очень полезен для отладки. Я работал с некоторыми системами, в которых были функции отладки, такие как:

• Система, в которой программист составлял список «регистрируемых параметров» (внутренних переменных). Вы должны сообщить системе, о каких из них вы хотите сообщить (до 8), а затем, когда вы запросите у системы зарегистрированные параметры, она вернет их в одном пакете данных. Мне это понравилось, но в зависимости от сложности системы вы можете или не сможете указать их во время выполнения (или вы можете сделать что-нибудь простое и отправить системе маску, которая выберет те, которые вы хотите вернуть).

• Пакеты данных, которые «нарушают» поведение и позволить частям системы быть протестированы независимо (то есть, на D / A выдает это напряжение, на DIO-порту стимулирует этот байт и т. д.)

Удачи!

Вы смотрели Modbus ( http: //www.modbus.org/)? Это довольно простой протокол, который включает контрольную сумму для каждого сообщения. Он также отправляет ответ на каждую команду, даже на те, которым не требуется «возвращаемое значение», поэтому вы знаете, правильно ли была получена ваша команда. Единственный выбор, который у вас будет после выбора Modbus, - это адреса регистров для хранения ваших данных и формат любых определяемых пользователем функций (что позволяет протокол MODBUS).

Взгляните на Firmata в качестве примера протокола.

У меня есть некоторые предпочтения (и неприятные моменты) в отношении написания программного обеспечения для управления мультимедиа и устройствами отображения с использованием RS232. В зависимости от вашего оборудования некоторые из них могут не применяться:

• Я думаю, что было бы неплохо сделать ваш протокол более удобным для автоматизации. Если вам нужен интерактивный интерфейс (командная строка или другой), создайте его отдельно и используйте протокол автоматизации. Я бы не стал слишком беспокоиться о том, чтобы сделать его понятным для человека, но решать вам.

• Всегда возвращайте ответ, даже (особенно), если вы получили недопустимую команду. Что-то простое, вроде 06 долларов за ACK и 15 долларов за NAK. Или произнесите его по буквам, если хотите, чтобы оно было немного более читабельным.

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

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

• Никогда не отвечайте ошибкой для действительной команды. Можно подумать, что это очевидно ...

• Говоря об очевидном, задокументируйте настройки последовательного порта, которые поддерживает ваше оборудование. Особенно, если им будет пользоваться кто-то другой, кроме вас, и вы не хотите, чтобы они потратили первые 30 минут на попытки выяснить, не могут ли они поговорить с устройством из-за последовательного порта, подключений, кабеля или их программное обеспечение. Не то чтобы я горький ...

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

• Ответы должны включать информацию о команде, на которую они отвечают. Таким образом, любой программе не нужно запоминать последнее, что она запрашивала, чтобы обработать ответ (см. Опцию дополнительного кредита ниже).

• Если ваше устройство поддерживает режим ожидания (выключен, но не совсем выключен), убедитесь, что запросы по-прежнему работают, пока вы в этом состоянии.

В зависимости от того, насколько вы параноидально относитесь к полноте данных:

• Оберните ваше сообщение в конверт. Заголовок может включать начальный символ, длину сообщения и закрывающий символ. На всякий случай получаются частичные или искаженные сообщения. Может быть, 02 доллара за начало и 03 доллара за конец.

• Если вы действительно параноик по поводу целостности сообщения, включить контрольную сумму. Однако они могут быть немного неприятными.

Для дополнительной благодарности:

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

Надеюсь, это поможет.

Обновление:

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

Это хорошее практическое правило, разрабатываете ли вы командный протокол, веб-службу,

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

Мне нравятся протоколы, которые отправляют сообщение, а затем четкий символ конца сообщения (например, «возврат каретки»). Я обычно не считаю, что начало пакетных сигналов так полезно (что еще на этом проводе?) Использование CR для конца сообщения также упрощает тестирование с помощью терминальной программы.

Обновление: Брюс указал (в комментариях) ), что символ начала пакета позволяет вам находить пакеты немного быстрее в случае повреждения. Без символа начала пакета потребуется до конца следующего пакета, прежде чем вы узнаете, где находитесь, и в этот момент вы выбросите 2 пакета вместо одного.

FTP - это пример протокола, который достаточно хорошо работает как в интерактивном режиме, так и с автоматизацией. Одним из ключевых моментов является то, что ответы начинаются с кода, который указывает, должен ли автоматизированный клиент платить за уведомление или нет. То же самое и для POP3.

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

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

There are a lot of good suggestions and ideas here and notice that there are different ways to tackle it for different purposes. Having used many serial protocols both good and bad as well having made several of my own (both good and bad...) here are a few of my suggestions and comments.

• Keep it simple. I have found the greatest success with simple header based command-response "packets".

• Don't worry about human readable ASCII. It is only useful for the few hours you actually debug your protocol. After that it is restrictive to always encode data as ASCII and very inefficient if you transfer a lot of data.

• Use error checking. I prefer a 16 bit CRC as it provides orders of magnitude of protection over a checksum and is still simple and efficient over heavier algorithms like MD5 or SHA1.

• Use the same packet format for the commands as the responses.

• Use 8 bit data with no parity. Serial parity bit doesn't add anyprotection if you already use a CRCor other data integrity check and isa poor error check at best.

• So in the simplest form the packet header is the Command or Response, size of the packet, zero or more dataand the error checking code (CRC).

Здесь - отличная статья Эли Бендерски о формировании последовательного протокола. Какой бы формат пакета вы ни выбрали, обязательно используйте escape-символы. Это позволяет вам иметь такие символы внутри реальных данных и упрощает повторную синхронизацию в случае повреждения пакета.