Как (почти) предотвратить потерю данных при приеме FT232R (uart)?

Если вам нужна надежная передача данных, нет абсолютно никакого способа правильно использовать любой мост USB-последовательный порт без аппаратного управления потоком данных и без выделения по крайней мере всей оставшейся оперативной памяти в микроконтроллере в качестве последовательного буфера ( или, по крайней мере, до тех пор, пока вы не сможете хранить данные на ~ 1 с).

Я использую устройства FTDI с тех пор, как FT232AM был модной новинкой, и вот как я их реализую:

1. (По крайней мере) четыре линии проходят между мостом и MCU: RXD, TXD, RTS #, CTS #.

2. Управление потоком включено на стороне ПК.

3. Управление потоком включено на стороне MCU.

4. Код MCU отправляет сообщения только тогда, когда он может вместить полный ответный пакет в буфер. В противном случае он дает возможность ПК по тайм-ауту и ​​повторяет запрос. Для запросов, передающих данные обратно, весь кадр отбрасывается, если он не может поместиться в буфере передачи в то время, когда кадр готов.

5. Если вы хотите, чтобы ПК надежно уведомлялся о новых данных, скажем, о каждом количестве полных выборок / кадров, вы должны использовать символы событий для сброса буферов FTDI в hist и кодирования ваших данных. HDLC отлично подходит для этой цели и документирован в бесплатных стандартах (RFC и серии ITU X и Q - все бесплатно!).

6. Драйвер VCP или запуск порта D2XX настроен так, чтобы размеры передачи и задержки были установлены в соответствии с потребностями приложения.

7. Протокол связи оформлен с помощью CRC. Я обычно использую урезанную версию, если X.25 / Q.921 / HDLC, ограниченный режимом SNRM (E) для простых «глупых» устройств команд и ответов, и SABM (E) для устройств, которые передают данные.

Размер буферов FTDI не имеет значения, ваш MCU должен иметь как минимум на порядок больше памяти, доступной для буферизации вещей.

Если вы работаете с кодом реального времени, например, с обработкой сигналов, убедитесь, что вы учитываете накладные расходы, связанные с множеством прерываний передачи, выполняемых «спина к спине». Как только устройство FTDI очищает свои буферы после передачи USB и указывает, что оно готово к приему дополнительных данных от вашего MCU, ваш код потенциально может передать данные всего буфера FTDI за один раз.

Если у вас почти закончились циклы в вашем коде реального времени, вы можете использовать таймер в качестве источника прерываний передачи вместо прерывания UART. Затем вы можете установить частоту таймера намного ниже, чем скорость UART. Это позволяет замедлить темп передачи без снижения скорости передачи. Если вы работаете в режиме настройки / подготовки к работе или с более низкой нагрузкой на задачи в реальном времени, вы можете тривиально увеличить скорость передачи без изменения скорости передачи. Вы можете использовать аналогичный трюк для ускорения приема, переключая выход RTS # на MCU под управлением таймера. Конечно, это не проблема, если вы используете DMA или достаточно быстрый MCU.

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

Этот совет применим независимо от того, что является хостом USB.

^{Боковая панель: По общему признанию, "архитектура" последовательного USB-драйвера Linux находится в состоянии приостановленной анимации, насколько я могу судить, поэтому для получения разумных результатов может потребоваться много работы. Боюсь, дело не в простом изменении приоритета потока ядра. Частично причина в том, что финансирование многих работ по Linux сосредоточено на серверных / корпоративных приложениях, и там производительность USB в лучшем случае является второстепенным вопросом. Он работает достаточно хорошо для USB-накопителя, но последовательный USB-порт - это беспорядок, на который никто не обращает внимания, и на то, чтобы это исправить. Вы только посмотрите, сколько копи-макарон в этом отделе ...}