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

Существует много, чтобы быть сказанным для клиент-серверной архитектуры и синхронных протоколов. Простота и устойчивость, для запуска. Если скорость не является проблемой, Вы могли бы полагать, что компактный, человекочитаемый протокол помог с отладкой. Я думаю вроде модема ПРИ командах: последовательность "пробуждения" сопровождается установить/получить командой, сопровождаемой разделителем.

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

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

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

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

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

Я сделал материал как это с простым двоичным форматом

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;
}

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

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

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

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

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

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

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

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

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

Adam Liss делает много больших точек. Простота и устойчивость должны быть фокусом. Человекочитаемые передачи ASCII помогают МНОГО при отладке. Большие предложения.

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

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

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

Пакеты запускаются и заканчиваются 0x7e, Вы выходите из символа путем добавления префикса его 0x7d и переключения бита 5 (т.е. xor с 0x20), Таким образом, 0x7e становится 0x7d 0x5e, и 0x7d становится 0x7d 0x5d

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

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

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

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

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

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

сохраняют команды, тот же размер - делает декодирование легче.

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

, я рекомендовал бы объявление запуска хосту с версией микропрограммного обеспечения в сбросе - например, "ПРИВЕТ; Версия микропрограммного обеспечения 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 - Для устанавливания значения первый байт является портом, затем напряжение, и я рекомендовал бы оставаться "=" и "." как структурирующий для обеспечения допустимого пакета, если Вы воздерживаетесь от контрольной суммы.

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

5=0 
6=9
2=5  

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

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

Hope это помогает немного.

Имел другую мысль при перечитывании; при добавлении "*" команда могла запросить данные, перенесенные с тегами HTML, и теперь приложение хоста могло просто перенаправить вывод от микро до браузера и wala, готовый браузер -

:)