khach 33 12 марта Опубликовано 12 марта · Жалоба Добрый день. Возникла необходимость замедлить передачу данных из переходника USB- UART Для общения с древней периферией без FIFO в приемном UART. Как известно, переходники USB "лепят" байты в пакете с минимальным задержками между ними. Приемная часть от такого захлебывается. Передавть по одному байту на 1 мс на одну транзакцию USB получается совсем томозно. Возникла идея использовать hardware flow control для введения задержек между байтами. Вот нашел такую схему Но тут одновибратор, формирующий задержку имхо переусложнен. Есть подобные схемы на 555 таймере для переключения направления RS485. А теперь вопрос- некторые схемы USB UART не успевают задержать передачу до начала второго байта. Кто -нибудь изучал требования к CTS сигналу для надежной отсечки по одному байту? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Точка Опоры 30 12 марта Опубликовано 12 марта · Жалоба Лучшие результаты достигал на Exar'овских (MaxLinear) конвертерах, ЕМНИП. FTDI - похуже. Поищу записи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khach 33 12 марта Опубликовано 12 марта · Жалоба FTDI вроде высылает еще один байт после пропадания RTS ( наверно обсуждают управляющий сигнал, а не вход CTS) https://community.silabs.com/s/article/x-reference-using-or-bypassing-flow-control-with-uart-communication?language=en_US а у prolific PL2303HX Rev. D вроде этого бага нет. Пока что ищу подобную же инфу для CH340 и CP2102 - пусть уж будет все в одном месте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 4 13 марта Опубликовано 13 марта · Жалоба 21 час назад, khach сказал: А теперь вопрос- некторые схемы USB UART не успевают задержать передачу до начала второго байта. Кто -нибудь изучал требования к CTS сигналу для надежной отсечки по одному байту? В ПК если использовать типовые UART не бывает отсечки 1 байта по CTS. Совсем!!! Классические 16550-compatible UART выдают все содержимое FIFO а у современных это 64...128 байт, USB переходники могут творить все что угодно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 13 марта Опубликовано 13 марта · Жалоба Нет никаких проблем по быстрому слепить переходник UART<->UART на любом удобном МК. В котором один из UART-ов будет передавать с паузами. На это времени нужно даже меньше, чем на написание постов здесь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khach 33 13 марта Опубликовано 13 марта · Жалоба 57 минут назад, _3m сказал: Классические 16550-compatible UART выдают все содержимое FIFO а у современных это 64...128 байт Откуда это следует? Как раз наоборот при hard flow у классики. Другое дело что интерированные в чипсет 16550 подобные ведит себя тоже непонятно как. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 4 13 марта Опубликовано 13 марта · Жалоба 35 минут назад, khach сказал: Откуда это следует? Как раз наоборот при hard flow у классики. Другое дело что интерированные в чипсет 16550 подобные ведит себя тоже непонятно как. Оттуда что древнее гавно 16550 аппаратно не обрабатывает сигналы flow control. Их проверяет драйвер и если сигнал готовности снят - перестает грузить fifo а передачу того что уже легло в fifo не остановить. Электроника давно ушла вперед но с упорством баранов продолжают лепить "Industrial standart 16550-compatible UART" причем не только в ПК но и в разнообразные Arm-SOC и даже в некоторые МК, в части случаев даже прерывание TX Complete "забывают" завести. [beep-beep-beep!!!] Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 13 марта Опубликовано 13 марта · Жалоба 38 минут назад, _3m сказал: Оттуда что древнее гавно 16550 аппаратно не обрабатывает сигналы flow control. Их проверяет драйвер и если сигнал готовности снят - перестает грузить fifo а передачу того что уже легло в fifo не остановить. Насколько помню: В некоторых МК, в которых UART вроде как имеет аппаратный FC, это никак не влияет на передачу из TX-FIFO ранее туда уже загруженных данных. Т.е. - даже если выставлен внешний стоп CTS-ом, но в TX-FIFO уже имеются ранее загруженные данные, они продолжат передаваться до опустошения. Только драйвер (прошивка МК) может остановить передачу из TX-FIFO. Т.е. - нужна программная обработка для такого останова. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khach 33 13 марта Опубликовано 13 марта · Жалоба Я же привел цитату из даташита как можно более оригинального 16550 от ТИ. Они и стоят на профессиональных картах RS232-485 MOXA и прекрасно режут передачу по CTS. То что древний NS16550 не умел в аппаратный CTS так кто его видел тот NS в живую, я с трудом даташит на него нашел. Неудобство там только одно- надо преобразовать обратно TXD в ТТЛ, потом запустить таймер-одновибратор задержки, потом обратно в +/- 12В СTS превратить. 1 час назад, jcxz сказал: Нет никаких проблем по быстрому слепить переходник UART<->UART на любом удобном МК. Во отссылки на такой проект чтобы по быстрому слепить и задать задержку для нужного baudrate был бы благодарен. Только чтобы порт не отваливался при засыпании винды, а то уже были такие исходники с нулевой практической пользой Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
