Хорошие протоколы на основе RS232 для встраиваемых в компьютерную связь

Я работаю над проектом, который предусматривает обмен данными между удаленным Arduino и компьютером. Беспроводное соединение осуществляется через пару XBees, поэтому у нас есть связь RS232 между Arduino и компьютером. Для небольших объемов данных достаточно просто собрать несколько простых протоколов связи. Для больших проектов, каковы хорошие простые протоколы связи?

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

ОП запрашивает последовательный протокол для ситуации, когда « не так много [данных] и скорости не является большой проблемой ». MODBUS упоминается в OP MODBUS через RS-485 не является быстрым протоколом. Хотя это не спецификация, это дает представление о нише.

Я могу думать только о двух общих стандартных протоколах для этой ниши:

• НЕМА 0183 . Простой текстовый протокол ASCII. Человек читаемый. Точка-точка только. Не поддерживает многоканальную шину.
• MODBUS, который уже упоминался в ОП

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

Некоторые встроенные системные протоколы, некоторые из которых чрезвычайно просты, перечислены в разделе «Встроенные системы: общие протоколы» , в том числе:

• Tiny Embedded Network (TEN)
• Интерпретатор микроконтроллера для сетевых встраиваемых систем (MINES)
• Еще один масштабируемый протокол (YASP)
• Локальная сеть связи (LIN)
• Serial Servo Controller (SSC)
• Серийный номер операционной системы робота (rosserial)
• netstring
• различные полевые автобусы
• Modbus
• Сеть контроллеров (CAN)
• Firmata (Спасибо, Джиппи!)

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

Я бы проголосовал за себя, и сделал бы это как можно проще.

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

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

В качестве очень простого примера вы можете преобразовать ваши данные в символы ASCII и вставить их в символы запуска / остановки, например:

Чтобы отправить значение байта 0x7A, отправленные данные должны быть (7A), где () - выбранные начальные / конечные символы, а 7 и A - два ascii-символа. ОК, это добавляет много накладных расходов, но это означает, что вы можете отлаживать с помощью основного программного обеспечения терминала.

Если ваши данные проходят через XBees, вы должны перевести модули в режим API с помощью escape-символов, разделить ваши данные на логические пакеты и воспользоваться тем фактом, что в режиме API пакет, который передается XBee, либо прибудет нетронутым, либо не за что. Создайте свой протокол, передавая блоки по 1-255 байт, и позвольте модулям XBee беспокоиться о том, как доставлять данные внутри каждого блока. Не беспокойтесь о сохранении целостности отдельных пакетов или подразделений между ними. Модули Digi позаботятся об этом. Самое большое, о чем вам нужно беспокоиться, это тот факт, что даже если узел, который передает пакет, считает, что он не был доставлен и отправляет замену, получатель может в конечном итоге получить его в любом случае - возможно, даже после получения замены. Все может быть проще, если вы спроектируете свой протокол так, чтобы одна сторона была «главной»; если мастер запрашивает кусок данных, ведомый должен отправить его один раз и не беспокоиться о том, получит ли мастер его. Если мастер не получает данные, которые ему нужны, он может запросить их снова.

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

Как насчет Фирмата ? Имеет поддержку различных операционных систем и языков программирования. Поддерживаются контроллеры Arduino и PICduino, но это не должно быть слишком сложно портировать на голый микроконтроллер.

У меня был похожий вопрос к этому, и я никогда не находил ничего простого и достаточно маленького для небольших AVR и т. Д. Поэтому я сделал что-то вдохновленное CAN. Он называется MIN (сеть межконтроллерного соединения):

https://github.com/min-protocol/min

Я написал об этом здесь:

https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

Есть блоки для данных блока, но в основном они предназначены для сигналов датчиков / исполнительных механизмов. Я определил формат JSON для описания сигналов и их упаковки в кадрах MIN и надеюсь получить анализатор Wireshark, который его использует.