Последовательный перенос задержки UART

В настоящее время у меня встроенное устройство, подключенное к ПК через последовательный порт. У меня возникают проблемы с получением данных на ПК. Когда я использую свою карту последовательного порта PCI, я могу сразу получить данные (без задержек). Когда я использую свой USB-To-Serial разъем или материнские платы, встроенные в последовательный порт, мне приходится задерживать чтение данных (40 мс для 32-байтных пакетов).Последовательный перенос задержки UART

Единственное различие, которое я могу найти между оборудованием, - это UART. Плата PCI использует 16650, а плагин/материнская плата использует стандартный 16550A. Плата PCI установлена на прерывание с 28 байтами, а штепсельная вилка установлена на прерывание с 14 байтами.

Я подключен к 56700 бод (если это помогает).

Задержка становится большей частью рабочего цикла и действительно увеличивает время передачи. (10 минут передачи через 1 час передачи).

У кого-нибудь есть объяснение, почему я должен использовать задержку со штекером/материнской платой? Может ли кто-нибудь предложить возможное решение для минимизации или устранения этой задержки?

источник

2010-07-20 Matthew Alley

У вас есть аппаратное управление потоком? Является ли ваше встроенное устройство использующим 16650? – nmichaels

Нет, аппаратное управление потоком не включено. В настоящее время я использую только RX/TX и наземную линию. Встраиваемое устройство использует atmega atmega 128L и кристалл 7,3728 МГц. Я предполагаю, что это считается «совместимым с 16650». Peter: Да, я могу настроить точку прерывания материнской платы. Однако его диапазон также составляет 1-14 байтов из-за него с использованием 16550 UART (16-байтовый FIFO-буфер). Задержка фактически помогла минимизировать ошибки несоответствия в подключении материнской платы от сотен до менее 10 во время передачи в течение часа. –

У Linux есть флаг ASYNC_LOW_LATENCY для серийного драйвера, который может помочь. Какой бы драйвер вы ни использовали, может быть что-то подобное.

Однако латентность не должна влиять на массовую передачу. Он должен добавить 40 мс в самом начале передачи, и это все, поэтому водители не беспокоятся об этом в первую очередь. Я бы рекомендовал реорганизовать ваш протокол передачи, чтобы использовать sliding window protocol с размером окна около 100 пакетов, если вы делаете 32-байтовые пакеты с этой скоростью и латентностью. Другими словами, вы хотите прекратить передачу, если вы не получили ACK для пакета, который вы отправили 100 пакетов назад.

источник

2010-07-20 13:40:42

Я увеличил размер пакета с 32-байтовых до 256-байтов, и мне нужно было увеличить задержку с 40 мс до 65 мс. Это привело к сокращению времени моего общения с 1 часа до 14 минут. –

Возможно, вы обнаружите, что различные преобразователи USB-Serial дают разные результаты. Мы обнаружили, что FTDI работают хорошо для общения со встроенными устройствами. Некоторые конвертеры, похоже, долгое время заполняют данные и/или фрагментируют их.

Я никогда не видел проблемы с подключением к материнской плате - не уверен, что там происходит! Можете ли вы изменить точку прерывания для последовательного порта материнской платы?

источник

2010-07-20 12:48:45

Подключен к последовательным/USB-преобразователям. Я видел много работы, которые работают весь день для данных ascii, но поврежденных двоичных данных при высоких (115 200) битовых скоростях. – nmichaels

Конвертер USB-Serial, который я использую, - это Trendnet TU-S9, который использует чип Prolific. Карта PCI - это марка Sunix. –

У меня есть последовательный конвертер usb. Когда я подключаю его к своему блоку breakout и создаю loopback, я могу без проблем получать/получать с близкого расстояния до 1 Мбит/с. Последовательный порт отправляет двоичные данные, которые могут быть переведены в данные ascii.

Использование .Net Я установил свое программное обеспечение для запуска события на каждом байте (ReceivedBytesThreshold = 1), хотя это не значит, что он будет.

источник

2010-07-21 13:23:18 dbasnett

Последовательный перенос задержки UART

ответ

Смежные вопросы