Сообщение от code-by
|
|
....лучше их передавать в виде символов (т.е. вместо 1 отправлять не 0x01, а 0x31 - код цирфы 1)?
|
Передача в виде символов - избыточна и ее следует применять только в целях:
• Побайтовой проверки посылки по содержимому - коды из "чужого" диапазона значений намекают на порчу посылки (сбой в линии);
• Передачи данных не сплошным потоком, а с разбивкой, с помощью символов-разделителей, на сообщения - каждое сообщение начинается идентификатором сообщения (хидером), а заканчивается признаком конца. Коды разделителей выбираются из диапазона значений, не используемого для кодирования цифр. (Для признака конца хорошо подходит спец-символ LF – информацию хорошо принимать и легко опознавать на компьютере любой программой-терминалом).
Кроме того, разбивка на сообщения позволяет легко восстанавливать синхронизацию данных на приеме (исключать влияние потерянных или испорченных байтов) и дополнительно контролировать сообщения по длине.
|
Сообщение от code-by
|
|
....стоит ли делать реализацию обмена данными по уарт (прием и отправка) с применением кольцевого буфера?
|
Если делать обстоятельно, то надо вводить два буфера (входной и выходной), а задачу – разделить:
• Отдельный драйвер UART'а, работающий по прерываниям от него, считывает данные из приемника UART'а во входной буфер, оповещая основную программу о приходе каждого полного сообщения, и отправляет сообщения из выходного буфера (по мере готовности передатчика UART'а) до его опустошения.
• Основная программа считывает из входного буфера полные сообщения когда ей заблагорассудится (а не суматошно-срочно побайтово) и заносит в выходной буфер свои сообщения по мере их формирования. Единственная дополнительная забота – спровоцировать старт драйвер UART'а, если на момент занесения в буфер сообщения для передачи драйвер бездельничал (например, имитацией прерывания от UART'а).
Организация буферов может быть разная:
• Кольцевой байтовый – звучит красиво, универсален, но уж очень суетно побайтово отслеживать текущий занятый объем (начало/конец свободного места) и контролировать переполнение буфера.
• Буфер на несколько полных сообщений (несколько строчек с длиной, превышающей длину максимального по размеру сообщения. Организация похожа на FIFO – читаются сообщения из буфера всегда из "первой" строчки, потом "первая" строчка переназначается (кольцевой буфер сообщений) или информация в буфере сдвигается в сторону фиксированной первой строчки (перемещение массива при таком объеме информации много времени не займет). Объем буфера определяется скоростью обработки сообщения и трафиком. Учет свободного/занятого места – построчный.
• Удобно двойное буферирование на приеме микропроцессором – буфер на одну строчку, куда собирает сообщение драйвер UART'а и откуда посылка, по завершению приема, перемещается в основной входной буфер сообщений. Такая структура дает выигрыш, если микропроцессор может адресовать память с помощью нескольких разных адресных регистров (меньше шансов драйверу UART'а и основной программе спотыкаться друг о друга).
|
Сообщение от code-by
|
|
....стоит ли делать проверку по таймеру на прием, если пакеты и так идут каждые 2-3 секунды?
|
Вопрос абсолютно мутный. Что проверять по таймеру?
• При передаче от микропроцессора в компьютер можно не париться, слать непрерывно – компьютер принять всегда успеет. Причем неважно, понимает посылки компьютер или он уже давно выключен. Отправляемые посылки линию передачи не протрут.
• При приеме микропроцессор может не успевать обрабатывать сообщения в темпе, доступном копьютеру для их отправки. Для предотвращения переполнения буфера и потери информации можно модифицировать протокол. Например, считать, что абонент всегда способен принять сообщение полностью (не застревает в середине сообщения), а линия (абонент) занята после передачи в нее каждого сообщения и перед отправкой следущего надо дождаться ответного статусного сигнала готовности. Сигналом готовности может быть либо спец-символ (при символьном кодировании информации) либо сигнал статусного бита COM-порта (сигнал с отдельного порта микропроцессора подается на статусные входы COM-порта компьютера – DSR и/или CTS, как удобнее уговорить драйвер COM-порта).
Если еще договориться, что спец-символ готовности всегда изымается из потока драйвером принимающей стороны, то и посылать его можно в любой момент, то есть даже вставлять его между символами передаваемого сообщения.
А уж сверх того, можно завести таймер с большим (200-500 мсек) интервалом и считать, что по его окончании отправлять посылки уже можно (может кто-нибудь что-нибудь услышит). Такой большой интервал не страшен – в нормальной работе отправка будет производиться по реальной готовности и таймер и не потребуется, и не помешает. Но при неработающей системе можно будет проверять (осциллографом), до какого места безответный сигнал доходит.
Re: Кольцевой буфер uart
(смысл тот-же - с нюансами)
