Протоколы, используемые для разговора между встроенным ЦП и ПК

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

В настоящий момент я думаю о синхронном протоколе с полным хостом: запросы на отправку компьютеров, ответы встроенного процессора. Любые другие идеи?

Ответ 1

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

Смотрите FreeModBus для окон и встроенного источника.

Ответ 2

Там многое можно сказать о архитектуре клиент-сервер и синхронных протоколах. Простота и надежность, чтобы начать. Если скорость не является проблемой, вы можете рассмотреть компактный, удобочитаемый протокол, который поможет при отладке. Я думаю по линиям модемных AT-команд: последовательность "пробуждения", за которой следует команда set/get, а затем терминатор.

Host -->  [V02?]      // Request voltage #2
AVR  -->  [V02=2.34]  // Reply with voltage #2
Host -->  [V06=3.12]  // Set voltage #6
AVR  -->  [V06=3.15]  // Reply with voltage #6

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

В зависимости от требований скорости и надежности вы можете кодировать команды в один или два байта и добавлять контрольную сумму.

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

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

Ответ 3

Мое голосование для человека, читаемого.

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

Ответ 4

Я делал такие вещи с помощью простого двоичного формата

struct PacketHdr
{
  char syncByte1;
  char syncByte2;
  char packetType;
  char bytesToFollow;  //-or- totalPacketSize
};

struct VoltageSet
{ 
   struct PacketHdr;
   int16 channelId;
   int16 voltageLevel; 
   uint16 crc;
};

struct VoltageResponse
{
   struct PacketHdr;
   int16 data[N];  //Num channels are fixed
   uint16 crc;
}

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

Тип должен быть перечислением, указывающим, как проинтегрировать пакет. Размер может быть выведен из типа, но если вы отправляете его явно, тогда приемник может обрабатывать неизвестные типы без удушения. Вы можете использовать "общий размер пакета" или "байты для последующего"; последний может сделать код приемника немного чище.

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

Отправитель и получатель должны иметь таймауты, начиная с момента получения первого байта пакета, в случае удаления байта. Стороне ПК также требуется тайм-аут для обработки случая, когда встроенная система не подключена и ответа вообще нет.

Если вы уверены, что на обеих платформах используются поплавки IEEE-754 (PC do) и имеют одинаковую определенность, то вы можете использовать float как тип данных. В противном случае безопаснее использовать целые числа, либо необработанные биты A/D, либо заданную шкалу (то есть 1 бит =.001V дает диапазон +/- 32,267 В)

Ответ 5

Адам Лисс делает много замечательных моментов. Простота и надежность должны быть в центре внимания. Передаваемые пользователем ASCII-передачи помогают LOT во время отладки. Отличные предложения.

Они могут быть излишними для ваших нужд, но HDLC и/или PPP добавляют концепцию уровня канала передачи данных и все преимущества (и затраты), которые поставляются с уровнем канала передачи данных. Управление ссылками, обрамление, контрольные суммы, порядковые номера, повторные передачи и т.д.... все помогают обеспечить надежную связь, но добавляют сложность, обработку и размер кода и могут не понадобиться для вашего конкретного приложения.

Ответ 6

Шина USB ответит на все ваши требования. Это может быть очень простое USB-устройство с только контрольной трубкой для отправки запроса на ваше устройство или вы можете добавить прерыватель, который позволит вам уведомлять хост об изменениях на вашем устройстве. Существует несколько простых USB-контроллеров, которые можно использовать, например Cypress или Microchip.

Протокол поверх передачи действительно касается ваших требований. Из вашего описания кажется, что простой синхронный протокол определенно достаточно. Что заставляет вас бродить и искать дополнительный подход? Поделитесь своими сомнениями, и мы постараемся помочь:).

Ответ 7

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

Если я хочу сделать бинарный формат пакета, я, как правило, использую что-то свободно на основе формата PPP byte-asnc HDLC, который чрезвычайно прост и удобен для отправки, в основном:

Пакеты начинаются и заканчиваются 0x7e Вы избегаете char путем префикса его с помощью 0x7d и переключающего бита 5 (т.е. Xor с 0x20) Итак, 0x7e становится 0x7d 0x5e и 0x7d становится 0x7d 0x5d

Каждый раз, когда вы видите 0x7e, тогда, если у вас есть какие-либо данные, вы можете его обработать.

Я обычно использую синхронный материал, управляемый хостом, если у меня нет оснований для этого. Это технология, которая простирается от простого точечного RS232 до многоточечного RS422/485 без хлопот - часто это бонус.

Ответ 8

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

Итак, это заставило меня думать и хорошо, вот несколько моих мыслей -

Учитывая, что этот чип имеет 6 каналов АЦП, скорее всего, вы используете серийный номер Rs-232 (предположение из вашего вопроса), и, конечно же, ограниченное пространство кода, определяющее простую структуру команд, поможет, как указывает Адам - Возможно, вы захотите сохранить обработку ввода до минимума на чипе, поэтому бинарные звуки привлекательны, но компромисс в легкости разработки и обслуживания (вам, возможно, придется беспокоиться о съемке мертвого ввода через 6 месяцев) - гипертерминал является мощным инструментом отладки, поэтому я подумал о том, как реализовать простую структуру команд с хорошей надежностью.

Несколько общих соображений -

сохранить команды того же размера - упрощает декодирование.

Обрамление команд и необязательная контрольная сумма, как указывает Адам, можно легко обернуть вокруг ваших команд. (с небольшими командами простая контрольная сумма XOR/ADD быстрая и безболезненная)

Я бы порекомендовал анонс запуска на хост с версией прошивки на reset - например, "HELLO; Firmware Version 1.00z" - сообщил хосту, что цель только началась и что работает.

Если вы в основном контролируете, вы можете рассмотреть режим "свободного прохода", где цель будет просто циклически выполнять аналоговое и цифровое считывание - конечно, это не обязательно должно быть непрерывным, оно может быть разнесено на 1, 5, 10 секунд или только по команде. Ваш микро всегда слушает, поэтому отправка обновленного значения является самостоятельной задачей.

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

например, ваш микро может просто выводить строки;

  V0=3.20
  V1=3.21
  V2= ...
  D1=0
  D2=1
  D3=...
  and then start over --

Кроме того, команды могут быть очень простыми -

? - Прочитайте все значения - их не так много, поэтому получите их все.

X = 12.34 - Чтобы установить значение, первым байтом является порт, затем напряжение, и я бы рекомендовал сохранить "=" и ".". как обрамление, чтобы обеспечить действительный пакет, если вы откажетесь от контрольной суммы.

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

5=0 
6=9
2=5

который установил бы порт 5, порт 6 полностью включен, а порт 2 - половину значения. При таком подходе данные ascii и двоичные данные находятся на одной и той же основе в отношении ресурсов вычислений/декодирования на микро. Или для большей точности сделайте вывод 2 байта, например, 2 = 54 - ИЛИ, добавьте таблицу xref и значения даже не должны быть линейными, где байт данных является индексом в справочной таблице..

Как я люблю говорить; простой обычно лучше, если только это не так.

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

Была еще одна мысль при повторном чтении; добавление команды "*" может запрашивать данные, обернутые тегами html, и теперь ваше хост-приложение может просто перенаправить вывод с вашего микро в браузер и wala, браузер готов -