Хороші протоколи, засновані на RS232, для вбудовування в комп'ютерну комунікацію

Я працюю над проектом, який передбачає хороший обмін даними між віддаленим Arduino та комп'ютером. Бездротове з'єднання здійснюється через пару XBees, тому у нас є зв'язок RS232 між Arduino та комп'ютером. Для невеликої кількості даних досить просто зібрати разом простий протокол зв'язку. Хоча для великих проектів є які хороші прості протоколи зв'язку?

Я подивився на MODBUS, який здається життєздатним варіантом, але хотів дізнатися, чи є інші кращі варіанти.

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

Я можу придумати лише два звичайних стандартних протоколи для цієї ніші:

• NEMA 0183 . Простий текстовий протокол ASCII. Людина читана. Тільки точка-точка. Не підтримує багатопроменеву шину.
• MODBUS, який вже згадувався в ОП

Дуже часто, коли вбудовані програмісти опиняються в такій ситуації, як ОП, вони розробляють власні протоколи послідовного зв'язку з нуля.

Деякі вбудовані системні протоколи, кілька з них надзвичайно прості, перелічені у вбудованих системах: загальні протоколи , зокрема:

• Крихітна вбудована мережа (TEN)
• Інтерпретатор мікроконтролерів для вбудованих мережевих систем (MINES)
• Ще один масштабований протокол (YASP)
• Локальна мережа взаємозв'язку (LIN)
• Послідовний сервоконтролер (SSC)
• Серія операційної системи роботів (розсеріальна)
• плетіння
• різні польові автобуси
• Модбус
• Мережа областей контролерів (CAN)
• Фірма (Дякую, джиппі!)

Можливо, один із цих протоколів був би достатнім для вашої програми як такої, або лише з незначним налаштуванням.

Я хотів би проголосувати своє і тримати це максимально просто.

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

• Запуск та зупинка символів, які не використовуються в іншому місці
• Якась контрольна сума / перевірка помилок
• Деякий спосіб управління / сигналізації потоку, особливо якщо вам потрібні двонаправлені кому.

Як дуже базовий приклад, ви можете перетворити свої дані в символи ASCII і вставити їх у символи старту / зупинки, як це:

Щоб надіслати значення байта 0x7A, надіслані дані були б (7A), де () - обрані символи початку / зупинки, а 7 і A - дві символи ascii. Гаразд, це додає багато накладних витрат, але це означає, що ви можете налагоджувати за допомогою базового термінального програмного забезпечення.

Якщо ваші дані проходять через XBees, вам слід перевести модулі в режим API з символами втечі, розділити свої дані на логічні пакети і скористатися тим, що в режимі 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, який його використовує.