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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Для дополнительного кредита:

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

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

Update:

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

Удачи!

Ответ 5

Если у вас должен быть собственный протокол,

Пожалуйста, пожалуйста, используйте пакетное оформление.

SLIP Создание только нескольких строк кода. Указывается в (RFC 1055)

Итак, теперь все пакеты всегда могут выглядеть так:

 <slip packet start>
 message
 message crc
 <slip packet start>

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

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

Множество простых двухбайтовых CRC; Xmodem легко. Вы можете просто xor все байты в пакете, в котором вы должны.

Если вы хотите быть действительно приятным человеком, используйте PPP, DDNS и HTTP-REST для своих реальных команд. Прекрасная книга о том, как это сделать на процессоре PIC 16 серии в C Джереми Бентамом, TCP/IP Lean.

Затем вы можете использовать веб-браузер, чтобы поговорить с ним, или что-то вроде libcurl из кода C. Поскольку почти на каждом языке программирования есть библиотеки для работы с http, каждый может поговорить с вашим устройством.

Ответ 6

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

• Держите его простым. Я нашел наибольший успех с простым заголовком основанные на команде "ответы".

• Не беспокойтесь о читаемом человеком ASCII. Это полезно только в течение нескольких часов, которые вы фактически отлаживаете свой протокол. После этого ограничивать всегда кодирование данных как ASCII и очень неэффективно, если вы передаете большое количество данных.

• Используйте проверку ошибок. Я предпочитаю 16-битный CRC, поскольку он обеспечивает порядок защиты по контрольной сумме и по-прежнему прост и эффективен по более тяжелым алгоритмам, таким как MD5 или SHA1.

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

• Используйте 8-битные данные без контроля четности. Последовательный бит четности не добавляет никакой защиты, если вы уже используете проверку целостности данных CRCor и, в лучшем случае, плохой проверки ошибок.

• Таким образом, в простейшей форме заголовок пакета представляет собой команду или ответ, размер пакета, нуль или больше данных и код проверки ошибок (CRC).

Ответ 7

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

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

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

Ответ 8

Посмотрите Firmata в качестве примера протокола.

Ответ 9

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