[Мур 1]

Право не ловко... :wub:

Привык XON\XOFF на RS232 гонять (перемычками обманывая РС)

Смотрю в доке на FT232R п.8.4 введены для контроллера дополнительные сигналы CTS\RTS.

Догадываюсь, что в скоростном обмене они просто необходимы..

CTS-готовность к приёму,а

RTS-запрос на передачу. Знак# означает инверсию,-т.е. активен лог нулём..

Подскажите, от кого должна инициатива исходить, а проще подскажите протокол для тандема USB-MK???

[AlexBoss 0]

Управление потоком RTS/CTS простое, как палка, точнее, как две палки, поскольку сигналов всетаки два.

 

RTS - это Ваш выходной сигнал, который подключен к входному пину CTS на стороне Вашего абонента. Имея возможность и желание принимать данные Вы устанавливаете RTS в активное состояние, а абонент, анализируя CTS понимает, что Вы готовы и если у него есть, что сказать - передает данные. Если Вы не успеваете переваривать поток данных, которым Вас кормят и буфер у Вас не резиновый, то установив RTS в неактивное состояние, даете абоненту понять, что надо-бы остановиться.

 

CTS - это Ваш входной сигнал, который подключен к выходному пину RTS на стороне Вашего абонента. Ну и все точно так-же, но наоборот - этой линией Вы не управляете, но обязательно анализируете.

 

Т.о. схема проста:

- можете принимать -> установите RTS;

- не можете принимать -> сбросьте RTS;

 

- хотите передавать -> проверьте CTS:

- активен -> передавайте;

- не активен -> надо ждать.

[zltigo 1]

Т.о. схема проста:

- можете принимать -> установите RTS;

- не можете принимать -> сбросьте RTS;

 

- хотите передавать -> проверьте CTS:

- активен -> передавайте;

- не активен -> надо ждать.

Не забудьте только, что в общем случае при установке RTS к Вам еще может прибежать все содержимое FIFO передатчика ну или как минимум текущий байт :-))) Вышескаэанное относится к большинству чипов, хотя бывают и исключения:

На передающей стороне аппаратно заблокируется передача после завершения текущего байта (правильный, но безмерно редкий случай) или _сбросится_ все содержимое передатчика не дожидаясь даже конца передачи текущего байта...

 

В общем все не так красиво....

[AlexBoss 0]

To zltigo!

 

Ваша ошибка в следующем:

>На передающей стороне аппаратно заблокируется передача ...

Ни какая аппаратная блокировка передачи в UART-ах не используется! Все чипы, начиная с 8251, 8250, .... 16550A и их клоны, а также приемо-передатчики однокристалок для "аппаратного управления потоком" (так обычно называют RTS/CTS) используют программное управление этими сигналами. Аппаратным его назвали только потому, что для его реализации используется аппаратура - пара портов ввода/вывода и проволока их соединяющая. Да и еще в пику чисто программному XON\XOFF.

Таким образом ни какими ухищрениями ни приемник ни передатчик не смогут остановить передачу, которая уже началась - будь то байт в сдвиговом регистре или набитый буфер FIFO передатчика. Остановить поток может только алгоритм, управляющий передачей, который перед очередной закладкой байтов в FIFO обнаружит сброшенный CTS.

 

> _сбросится_ все содержимое передатчика ....... по лини связи на вход приемника и только после этого остановится поток. Да такую ситуацию принимающий алгоритм должен учитывать и сбрасывать RTS не когда петух клюнет, а заранее - когда в приемном буфере еще есть небольшой резерв (как правило не менее 16 байт) для размещения еще пока недопринятых байт, которые могут уже сидеть в FIFO передатчика. Так он и поступает.

 

Если даже предположить, что UART-ы с аппаратной блокировкой передачи существуют, что моей 20-летней практикой почему-то не подтверждается, то они просто обязаны:

a) не прерывать передаваемый байт;

б) сохранять недопереданное содержимое FIFO до возобновления передачи - то, что оно придет приемнику потом, после того, как он установит RTS, очеть даже хорошо, т.к. мы же этого и добивались - приостановить передачу.

А если чип не выполняет эти требования, то это исключительное г..... (извините за грубость), с которым просто невозможно работать, которое никто применять, а значит и производить не будет.

 

To Мур!

Не бойтесь - все именно так красиво.

[zltigo 1]

To zltigo!

Ваша ошибка в следующем:

>На передающей стороне аппаратно заблокируется передача ...

Ни какая аппаратная блокировка передачи в UART-ах не используется!

Читать умеем? Читаем ПОЛНОСТЬЮ:

Вышескаэанное относится к большинству чипов, хотя бывают и исключения:

На передающей стороне аппаратно заблокируется передача после завершения текущего байта (правильный, но безмерно редкий случай)

Черным по белому написано это исключение в большинстве случаев по причине указанной Вами:

Все чипы, начиная с 8251, 8250, .... 16550A и их клоны, а также приемо-передатчики однокристалок для "аппаратного управления потоком" (так обычно называют RTS/CTS) используют программное управление этими сигналами.

Дело обстоит не так. C чем спорим?

 

Теперь про сбросится:

> _сбросится_ все содержимое передатчика ....... по лини связи на вход приемника и только после этого остановится поток.

Нет сбросится, это сбросится нахрен - потеряется.

Если даже предположить, что UART-ы с аппаратной блокировкой передачи существуют, что моей 20-летней практикой почему-то не подтверждается,

Существуют, существуют - это не 8250 а 8251. Более того именно они выпускались отечественной промышленностью долгие годы.

то они просто обязаны:

a) не прерывать передаваемый байт;....

Увы, их разработчика поступили иначе :(

А если чип не выполняет эти требования, то это исключительное г..... (извините за грубость), с которым просто невозможно работать, которое никто применять, а значит и производить не будет.

Однако западники их производят до сих пор :) и ставятся они у меня произведенные фирой NEC в одну старую железку до сих пор.

 

To Мур!

Не бойтесь - все именно так красиво.

Все не красиво по причине необходимости принять в общем случае все содержимое FIFO передатчика.

 

P.S.

У меня сейчас в РС стоят 550 совместимые UART-ы с 128 байтами FIFO. Вот так даже "красиво" взмахнув CTS, будте добры получить все сполна. Посему в общем случае тормознув передачу CTS, будьте добры продолжать принимать до тех пор, пока не появися пауза в приеме, если не уверены в том, что у Вас на приемной строне FIFO больше, чем на передающей строне.

[AlexBoss 0]

Губокоуважаемый 'zltigo', кто Вам дал право поучать окружающих (напр. как надо читать даташиты) и хамить им (нап. "Чтать умеем?")?

Кто-то из мудрых сказал: "Человек заслуживает такого к себе отношения, какое он проявляет по отношению к окружающим." Видимо это тот случай.

Ну что ж, будем общаться на Вашем языке.

 

Читать умеем? Читаем ПОЛНОСТЬЮ:

Черным по белому написано это исключение в большинстве случаев по причине указанной Вами:

Читать вообще учились? Черным по белому написано:

Ни какая аппаратная блокировка передачи в UART-ах не используется!

Поэтому ни каких исключений и безмерно редких случаев !

Дело обстоит не так. C чем спорим?

Дело обстоит не KAK?

Теперь про сбросится:

Нет сбросится, это сбросится нахрен - потеряется.

Нет не сбросится, а будет продолжать передаваться и не нахрен а по линии передачи.

Во всем мире миллионы систем используют асинхронные приемопередатчики, а у Вас нахрен - потеряется. Ну что тут сказать, может оно так и есть, но в этом сучае это исключительно Ваша проблема.

Существуют, существуют - это не 8250 а 8251. Более того именно они выпускались отечественной промышленностью долгие годы.

Читать умеем? Черным по белому написано:

Все чипы, начиная с 8251, 8250, .... для "аппаратного управления потоком" ... используют программное управление ...

8251 и Более того именно КР580ВВ51 никогда не имели ни каких _аппаратных_средств_ прерывания передачи от принимающей стороны.

Увы, их разработчика поступили иначе :(

Если это Ваше личное, и надеюсь скромное мнение, то так и пишите, а еще лучше держите при себе.

Все не красиво по причине необходимости принять в общем случае все содержимое FIFO передатчика.

Все очень красиво, дстаточно лишь учесть необходимость принять в общем случае все содержимое FIFO передатчика.

P.S.

У меня сейчас ... UART-ы с 128 байтами FIFO ... тормознув передачу CTS, будьте добры продолжать принимать ...

Свершенно верно будьте добры, снять свой RTS когда обнаружите, что в Вашем приемном буфере осталось свободного места на 128 байт. И все будет очень красиво! И ни чего не потеряется нахрен! Не хотите (не можете себе позволить) - уменьшайте размер FIFO на передающей стороне (хоть вообще его отключите). Увы, их разработчика сделали все необходимое, чтобы Вы имели и такую возможность.

[Shamil 2]

8251 и Более того именно КР580ВВ51 никогда не имели ни каких _аппаратных_средств_ прерывания передачи от принимающей стороны.

Ну это Вы зря. Я хоть и работал с ними, последний раз, лет 12 назад,

и то помню, что там был как раз аппаратный запрет передачи, как

впрочем и у наших 1002ХЛ1 .

Вот нашел даже даташит от Intel i8251A.

Как там указано сигнал CTS запрещает передачу (но не прерывает ее) аппаратно.

Более того, нет возможности считать состояние этого сигнала (CTS), для программной

реализации останова передачи.

[zltigo 1]

8251 и Более того именно КР580ВВ51 никогда не имели ни каких _аппаратных_средств_ прерывания передачи от принимающей стороны.

Если это Ваше личное, и надеюсь скромное мнение, то так и пишите, а еще лучше держите при себе

.

8251 - Имели CTS я с (ними работал :) ), да и мануал найти не сложно, и нынешние контроллеры, например LPC23xx (я с ними работаю :) )имеют реально железное управление потоком. Посему все предыдущие Ваши речи я позволю себе не принимать во внимание.

Все очень красиво, дстаточно лишь учесть необходимость принять в общем случае все содержимое FIFO передатчика.

Я именно на это дважды указывал. Это есть очень большое ограничение для маленького контролера, особенно в случае, когда глубина FIFO передатчика заранее не известна. Если это для Вас мелочь, не портящая общей красоты картины, то спорить не буду :)

Свершенно верно будьте добры, снять свой RTS когда обнаружите, что в Вашем приемном буфере осталось свободного места на 128 байт.

Про неизвестную глубину FIFO уже писал :(. Необходимость иметь гарантированный прием тех-же 128 байт в каком-нибудь мелком контроллере красивым назвать трудно, согласитесь.

уменьшайте размер FIFO на передающей стороне (хоть вообще его отключите).

Именно для случая отключения, я упоминал необходимость принять минимум один байт.

Увы, их разработчика сделали все необходимое, чтобы Вы имели и такую возможность.

Разработчики, сделали, что могли себе позволить. То, что получилось в наиболее массовом случае вполне удовлетворительно работает при равноглубоких аппаратных FIFO. В противном случае описанная Вами простая схема:

Т.о. схема проста:

- можете принимать -> установите RTS;

- не можете принимать -> сбросьте RTS;

 

- хотите передавать -> проверьте CTS:

- активен -> передавайте;

- не активен -> надо ждать.

Неработоспособна, впрочем, как и даже в случае отсутствия FIFO на приеме и передаче, ибо после установки RTS Вы будете обязаны принять один байт.

 

Именно этим были вызваны мои слова "В общем все не так красиво". Возражать еще будем?

 

За мои слова "читать умеем" - прошу прощения. Однако прошу Вас перечитать внимательно и мой первый пост и совершенно не справедливый Ваш ответ "Ваша ошибка в следующем:..."

 

 

Как там указано сигнал CTS запрещает передачу (но не прерывает ее) аппаратно.

За давностью лет я уже не помню, возможно это были советcкие клоны, или без 'A', но передачу они рвали конкретно в любом месте :(.