2009-05-02 3 views
11

Я работаю со встроенным устройством, подключенным к ПК с помощью rs232 (rs232 через USB).Способ преобразования потока байтов в поток пакетов в C89 на встроенном устройстве

Я думаю о разработке своего собственного протокола:

<MAGIC><LENGTH><BINARY DATA><CRC>

, но я не хочу, чтобы изобретать колесо.

примечание что: Я думаю об ограниченном устройстве: 4 КБ ОЗУ, ни ядре, ни стандартном C lib.

Можете ли вы подумать о стандартном способе сделать это (возможно, библиотеку с открытым исходным кодом)?

Если у вас есть собственное решение, у вас есть какие-либо рекомендации?

  • Вы используете байты MAGIC также в конце пакетов?
  • Возможно, лучше использовать временные промежутки вместо разделителей?
  • Как вы находите начало пакетов в двоичных данных потока?
  • Возможно, лучше использовать текстовые протоколы?

UPDATE: Пожалуйста повторно зачитать вопрос. Я не должен просить библиотеку, но для хорошей практики.

+0

Похоже на: http://stackoverflow.com/questions/815758/ –

+0

Должен ли 3-й пункт маркировать: «как вы находите начало пакетов в потоке двоичных данных»? –

+0

Спасибо Steve :) –

ответ

3

См. this answer I gave to a very similar question относительно деталей простого протокола.

Чтобы ответить на ваши конкретные пункты:

  1. «Мэджик» байты в конце пакетов не причинит никакого вреда, но они лишние, если вы уже знаете, как долго пакет должен быть , и имеют CRC.
  2. Может быть разумным указать время таймаута, поэтому, если между байтами внутри одного пакета слишком большой разрыв, тогда помечена ошибка. Используя Modbus, я не уверен в ценности использования ограничителей времени в других местах.
  3. Вы имеете в виду «как вы находите начало пакетов в потоке двоичных данных»? Если это так, возможно, укажите минимальный разрыв между пакетами и/или требуйте, чтобы получатель получил значение после каждого пакета.
  4. Делает это проще для отладки и не требует специального программного обеспечения на ПК, но не очень эффективно. Конечно, если юзабилити важнее эффективности, чем система на основе текста, вполне уместна.
+0

Ссылка, которую вы предоставили, отвечает на мой вопрос относительно начала пакетов. Чтение Асинхронное обрамление HDLC было очень полезным. –

+0

Одна точка, о которой я не упоминал, даже если предыдущий байт имеет ошибку кадрирования из-за линейного шума, байт после байтового значения $ 00, $ 80, $ C0, $ F0, $ F8, $ FC, $ FE, или $ FF всегда будут получены правильно. Если пакеты будут отправляться обратно без подтверждения (чтобы обеспечить максимальную пропускную способность, мы надеемся, что первый пакет будет получен во время передачи второго пакета), может быть полезно завершить каждый пакет одним из этих байтовых значений, так что кадрирование ошибка в одном пакете не повредит следующий. – supercat

0

О единственном, что есть за вашими примитивами ввода-вывода, будет расчет CRC. Там отличная статья с кодом here.

+0

Статья выглядит красиво :). Спасибо. Но CRC не проблема, как мы ее уже реализовали для передачи радиочастот. –

3

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

void buffer_packet(unsigned char rx_byte) 
{ 
    static unsigned char byte_count = 0; 
    static unsigned char packet[8]; 

    packet[byte_count++] = rx_byte; 
    if (byte_count == 8) 
    { 
     unsigned char crc = calculate_crc(packet, 8); 

     write_uart(0x55); 
     write_uart(8); 
     while (byte_count--) 
     { 
      write_uart(packet[7 - byte_count]); 
     } 
     write_uart(crc); 
    } 
} 

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

+0

Я недостаточно четко изложил свой вопрос. Задача выглядит легко, но я довольно новичок в встроенной программе, поэтому меня интересуют лучшие практики. –