Вид для печати
HX_Server не анализирует сигналы порта - это делает драйвер Windows, настройки для которого содержатся в файле Terminal_ComPort_Adapter.iniЦитата:
Сообщение от Vamos
За реакцию драйвера на сигнал CTS отвечает параметр fOutxCtsFlow ( FALSE - не реагировать, TRUE - реагировать ).
Без сжатия проблем с переполнением быть не может, потому что задержек при приёме байтов нет.Цитата:
Сообщение от Vamos
Да настройки здесь не причем, я же привел ссылки на посты. Ситуация следующая, при передаче одного байта из окна "телетайп" HX_Server и при условии что он не прочитан из регистра приемника, лампочка CTS гаснет (на панели HX_Server) т.е. реакция на RTS есть. НО если продолжать печатать символы в телетайпе они окажутся в буфере драйвера передатчика Windows, что в принципе не правильно, правильно не передавать байты до снятия сигнала RTS.
Поэтому и происходит либо переполнение (если принимающая сторона начинает читать буфер) или ошибка пакета из-за чтения байтов из буфера и не приемом их во регистр приемника.
До снятия квитирования порт -065 может принять два байта. Один байт при этом находится в буфере приёмника, а другой - в сдвиговом регистре приёмника. Квитирование снимается при невозможности переписать из сдвигового регистра в буфер.Цитата:
Сообщение от Vamos
В цепочке порт - драйвер - программа на RTS должен реагировать порт ( у COM-порта есть внутренний буфер на несколько байтов ). Драйвер настраивает порт, принимает данные от программы в буфер драйвера ( 4К ) и передаёт в буфер порта. Если COM-порт не может правильно отреагировать на квитирование - работа невозможна, потому что данные передаются COM-портом не из буфера программы и даже не из буфера драйвера, а из собственного аппаратного буфера COM-порта.Цитата:
Сообщение от Vamos
Наоборот - именно так и надо делать. Буфер драйвера у Windows очень большой, а за работу с квитированием отвечают не программа и не драйвер, а настроенная драйвером аппаратура COM-порта.Цитата:
Сообщение от Vamos
RTS_CONTROL_ENABLE Включает в работу линию RTS, когда устройство открывается и оставляет ее включенной.Цитата:
Сообщение от Patron
RTS_CONTROL_HANDSHAKE Включает процедуру установления связи RTS. Драйвер поднимает линию RTS, когда (входной) буфер "опережающего ввода с клавиатуры" заполнен меньше, чем на половину и понижает линию RTS, когда буфер заполнен больше, чем на три четверти.
То как сейчас сделано справедливо для HANDSHAKE, но так нельзя делать для ENABLE ибо это режим для аппаратного квитирования и буферы Windows не должны влиять на эмуляцию работы порта.
Аппаратное квитирование приёма в COM-порт активируется только при RTS_CONTROL_HANDSHAKE.Цитата:
Сообщение от Vamos
Настройки RTS_CONTROL_ENABLE и RTS_CONTROL_DISABLE отключают аппаратное квитирование приёма в COM-порт и напрямую задают неизменное состояние линии RTS.
Но к работе с портом -065 это большого отношения не имеет, потому что ( из-за огромного буфера приёма ) Windows никогда не снимает RTS при приёме и из-за этого нет практической разницы между RTS_CONTROL_HANDSHAKE и RTS_CONTROL_ENABLE.
А 065 снимает.Цитата:
Сообщение от Patron
Это при приеме в РС, а при передаче из РС должна быть реакция на RTS снятием CTS и прекращением передачи, а уж в буфер Windows или в аппаратный буфер это уже вторично.Цитата:
Сообщение от Patron
Понятно что это программа терминал и ей нужно отправлять символы, чтобы пользователь не ждал. Но раз уж она используется для загрузки другого компа, может сделаете специальный режим или в HANDSHAKE моде, а я проверю на эмуляторе загрузку со сжатием.
- - - Добавлено - - -
Цитата:
Сообщение от Vamos
Немного сумбурно излагаю уж извините :) . Я пытаюсь объяснить что за выходным буфером Windows не следит и если HX_Server продолжает слать байты не смотря на сигнал CTS (порт на выход закрыт), то и буфера в 4К может не хватить, в итоге потери информации и ошибки загрузки. Как-то так.Цитата:
Сообщение от Patron
- - - Добавлено - - -
вот что происходит, как раз в момент передачи блока в 16К на 1-2 сек. гаснет CTS но поскольку HX_Server продолжает слать байты выходной буфер переполняется и потом загрузка встает из-за неверно переданной информации (ошибок переполнения сейчас нет)
Тот RTS, поведение которого настраивает RTS_CONTROL_HANDSHAKE - не имеет ни малейшего отношения к тому RTS, который снимает 065.Цитата:
Сообщение от Vamos
RTS от 065 приходит в COM-порт на вход CTS и за его обслуживание отвечает настройка fOutxCtsFlow ( FALSE - не реагировать, TRUE - реагировать ).
Сейчас заглянул в код - адаптер COM-порта, создаваемый сервером HX, имеет выходной буфер 128К и передаёт оттуда по одному байту в ответ на прерывание "предыдущий байт передан" от драйвера Windows. Если при передаче возникают ошибки - это аппаратная проблема COM-порта. Обвинять драйвер Windows в неумении работать с COM-портом бессмысленно. Когда COM-порт работает нормально - ни малейших проблем не возникает.Цитата:
Сообщение от Vamos
Угу. Если ДВК/УКНЦ успевает все забрать. Мгновенно остановить передающий писюшный компорт, как этого требует логика работы -065, невозможно. Так, что, получив на писюшной стороне CTS, можно быть уверенным: данные на стороне ДВК/УКНЦ уже потеряны.Цитата:
Сообщение от Patron
Это так только на кривых портах. На нормальных COM-портах всё работает без проблем.Цитата:
Сообщение от AFZ
Кроме того ( насколько я понимаю ), обсуждаемая проблема вообще не относится к работе портов, а вызвана отсутствием гальванической развязки сигналов квитирования. На сигнале приёма 065 при работе нет постоянной составляющей, поэтому при 3-проводной схеме соединения портов всё отлично работает без гальванической развязки ( как и должно ), но при добавлении в кабель линий квитирования - присутствующий на линии квитирования приёма в PC во время работы постоянный уровень вызывает сбои приёма 065 примерно для 1 байта из 10000.
- - - Добавлено - - -
Поскольку линия квитирования приёма в PC при работе не используется и единственная её роль - вызывать сбои в работе 065 - мною ранее уже предлагался вариант кабеля без этой линии, но до сих пор никто из владельцев сбоящих 065 не решился опробовать такой кабель.
Попытка привести к классическому или упрощенному кабелю всегда будет наталкиваться на "ну должно же работать". В электрике народ в основном не силен - доводы даже приводить бессмысленно, остается надеятся, что хотя бы никто не столкнется с попытками связать между этажами :)Цитата:
Сообщение от Patron
Трехжилка (как и положено в DL(V)11 [при прямой связке]) наше все :)
- - - Добавлено - - -
Жаль, что не так много народу пробовало подключить нстоящий терминал к настоящему железу - помогает :)
Вопросы у меня возникли не в связи с последними сообщениями (это частный случай), решил доделать эмуляцию -065 в UKNCBTL.Цитата:
Сообщение от Patron
Мы можем долго теоретизировать и приводить контраргументы по поводу буферизации в Windows, но UKNCBTL то стыкуется через com0com.
Добавить одно условие "не отправлять байт при снятии CTS" и можно мне в личку такую версию HX_Server, чтобы не распространять неправильно работающую программу :) , а я ее уже погоняю и с железом тоже. О результатах доложу.
- - - Добавлено - - -
А чего пробовать, свежи воспоминания, нажал на клавишу и ждешь пока символ появится :)Цитата:
Сообщение от form
ждешь до бесконечности всмысле? :)Цитата:
Сообщение от Vamos
Мне с СМ7209 проще было - он сразу информировал - первый раз пискнет на клавишу, а потом просто игнорирует клавиатуру... Это началось на старых E11 еще с прямым пробросом порта - тогда кусал лишнее. Позже в E11 добавили фичу ручной установки сигналов. Потом на железе (не PDPшном). С PDP-шным стало проще - на DL(V)11 куда его обычно нужно было подключить других сигналов просто нет по определению :)
Ну дык и я Patronу говорю что не должен байт без разрешения уходить, и не только я, еще Alex_K в начале темы на это указывал.Цитата:
Сообщение от form
Я скажу проще. В DL(V)11 никогда не было никаикх разрешений. Всегда были три (четыре) провода. И никакого контроля. Я согласен, советские инженеры лет через 10-20 попытались сориентироваться на аппаратный контроль, но вся беда, что IBM и последователи на это никак не ориентировались, а уж в последующие годы и вовсе все шло к тому, что нужно написать вручную контроллер (считай у УКНЦ идею сперли [хотя и раньше была])... Так что наш ответ чемберлену - использовать только то, что штатно положено. Обкусанные "управляющие" сигналы к счастью приравниваются к правильно выставленным :)Цитата:
Сообщение от Vamos
Это лишено смысла из-за того, что: 1) синхронная работа COM-порта возможна только при заполненном аппаратном буфере передачи ( за заполнение буфера передачи COM-порта отвечает драйвер Windows ) ; 2) нормальная работа драйвера Windows возможна только при заполненном буфере передачи драйвера.Цитата:
Сообщение от Vamos
Поэтому обычная работа выглядит так - ещё до завершения передачи первого байта драйвер Windows сообщает программе, что передана куча байтов, с таким расчётом, чтобы заполнить два буфера - свой и COM-порта. Поэтому, когда происходит снятие CTS - дёргаться уже поздно - аппаратный буфер передачи COM-порта заполнен и поэтому именно COM-порт должен остановить передачу.
И всё это без проблем работает на нормальных COM-портах. Обсуждаемые же нами проблемы вообще не имеют отношения к алгоритму работы портов и вызваны конкретными особенностями схемотехники некоторых УКНЦ.
Наличие таковых сигналов в принципе - особенность УКНЦ или ДВК (я имею в виду именно порт типа DL[V]11). Эти сигналы в принципе есть, комп их никак не контролирует, результат - загадка...Цитата:
Сообщение от Patron
На УКНЦ с нормальной схемотехникой ( где все линии связи с COM-портом настроены на +/-12в ) - 065 без проблем работает с квитированием, но на УКНЦ с TTL-уровнями на линиях квитирования - приход от COM-порта постоянного уровня [-12в] по линии CTS вызывает сбои при приёме 065.Цитата:
Сообщение от form
Почему никто из владельцев проблемных УКНЦ до сих пор не попробовал убрать из кабеля эту линию, которая даром не нужна и только вредит - вот это настоящая загадка.
А где есть такие УКНЦ? Единственно в УКНЦ с СЭМЗ-овской схемотехникой на TTL-уровне сидит один сигнал DCD, который открывает вход для посылок извне, всё остальное честно сделано на +/- 12В.Цитата:
Сообщение от Patron
Но при получении от COM-порта постоянного уровня "TRUE" по линии RTS эти УКНЦ всё равно сбоят при приёме.Цитата:
Сообщение от Alex_K
"Не правильно Вы бутерброд держите, дядя Федор" :) Без проблем работала только УКНЦ Alex_K с одним TTL-уровнем и то он не подключался к кабелю.Цитата:
Сообщение от Patron
НО читаем пост http://zx-pk.ru/showthread.php?t=160...l=1#post565490
Вот сейчас сделал специальную версию UKNCBTL где переполнение возникает сразу если передающая программа не отреагировала на снятие CTS, HX_Server успел насыпать в буфер Windows или com0com 25 байт и встал, что там и насколько заполняет это еще вопрос.Цитата:
Сообщение от Patron
Неужто таки все? И именно СЭМЗ-овские?Цитата:
Сообщение от Patron
Хотелось бы узнать, какая схемотехника УКНЦ у Vamos-а?
Огромная просьба - навсегда забыть про дурацкие, никому не нужные, бесполезные CTS/RTS/DSR/DTR. Они интересны когда в тему. В данном случае это не в тему - это привязка к конкретной и убогой (ц) реализации. Так может проще отказаться от поддержки убогой реализации исделать универсально?Цитата:
Сообщение от Vamos
КВАНТЦитата:
Сообщение от Alex_K
У меня все УКНЦ с КВАНТ-овской схемотехникой и там нет никаких TTL-уровней. А что же у меня не подключалось к кабелю?Цитата:
Сообщение от Vamos
TTL-уровеньЦитата:
Сообщение от Alex_K
Где-то показалось в начале темы :)Цитата:
Сообщение от Alex_K
Где и какой-такой TTL-уровень?Цитата:
Сообщение от Vamos
Неизвестно.Цитата:
Сообщение от Alex_K
Точно выяснена причина сбоев для УКНЦ palsw / RABBIT-1 - там проблемы при приёме возникают именно при добавлении в кабель линий квитирования ( при полной неизменности всех настроек ).
http://zx-pk.ru/attachment.php?attachmentid=55218
- - - Добавлено - - -
И конечно же проблем при работе не возникает.Цитата:
Сообщение от Vamos
Если на реальной УКНЦ ошибки приёма появляются при работе без сжатия - это 100% признак "электрических" проблем.
По началу темы мне показалось что у Вас СЭМЗ, из-за того что часто упоминали что при СЭМЗ-овской схемотехнике нужно +5В на 7(109) подключать, +5В в УКНЦ и 7(109) в УКНЦ в кабель к РС ничего не идет.Цитата:
Сообщение от Alex_K
Отвлекусь немного, моя УКНЦ (КВАНТ) в которой не работало квитирование в варианте +5В на 7(109) через короткое время вышла из строя полностью, поэтому испытать другие варианты подключения я не успел и эти тесты можно не учитывать при обсуждении проблемы.
Абсолютно не точно. Вот же ссылка http://zx-pk.ru/showthread.php?t=160...l=1#post565490 , RABBIT-1 грузил с HANDSHAKE плюс на древнем 486 РС.Цитата:
Сообщение от Patron
Ну как, вылет в СТОП по переполнению на втором байте при снятом CTS после приема 1 байта, а HX насыпал в буфер еще 25 байт и только потом остановился, а должен был остановится сразу по снятию CTS.Цитата:
Сообщение от Patron
Да я упоминал по сигнал 109(DCD). Он, в УКНЦ, открывает вход для посылок. В схемотехнике СЭМЗ он сделан на TTL-логике, уже после преобразования сигнала Rx в TTL-уровень. В схемотехнике КВАНТ он сделан на преобразователях уровня. А сажал я туда 5В от УКНЦ, исходя из того, что сигнал должен быть от +3В до +18В. Т.к. у меня УКНЦ питается от AT-источника, то проблем с просадкой напряжения не возникало. Альтернативный вариант кабеля, который я выкладывал, так и не попробовал, сказать ничего не могу.Цитата:
Сообщение от Vamos
А квитирование мне нужно было, чтобы не было ошибок переполнения. У PC квитирование не поддерживается на аппаратном уровне, драйвер в Windows должен обрабатывать всё это программно, соответственно важно и быстродействие PC.
Как я понял Patron утверждает обратное, что квитирование в РС аппаратное поэтому программе пофиг есть буферы.Цитата:
Сообщение от Alex_K
На той УКНЦ которая у меня сейчас просадки напряжения тоже нет, при том что блок питания от вышедшей из строя.Цитата:
Сообщение от Alex_K
HANDSHAKE на практике ни с чем не связан - Windows не снимает RTS, поэтому наличие/отсутствие линий квитирования на приём COM-порта не влияет.Цитата:
Сообщение от Vamos
Загрузка шла только с кабелем без квитирования. После добавления в кабель линий квитирования ( без изменения любых настроек ) загрузка уже не шла.
- - - Добавлено - - -
Конечно, аппаратное - в каждом COM-порту PC есть аппаратный буфер FIFO, глубину которого можно настраивать:Цитата:
Сообщение от Vamos
http://vana.nvtc.ee:89/evara/SysAdmi...es/4621125.JPG
- - - Добавлено - - -
До снятия CTS порт 065 принимает ДВА байта - иначе синхронная работа порта ( когда байты принимаются один за другим "без промежутков" ) была бы невозможна. Это легко проверить, запустив в пульте программу, крутящуюся минуту в пустом цикле, а потом читающую все байты, какие успел принять порт - если после запуска программы отправить в порт несколько байтов, то после обращения программы к порту - будут выведены первый и последний из переданных байтов.Цитата:
Сообщение от Vamos
Наличие буфера никоим образом с квитированием не связано. Стандартные чипы на PC аппаратно не обрабатывают квитирование, только возможно вызвать прерывание при изменении уровней сигнала CTS/RTS/DTR/DSR, всё остальное ложиться на программу.Цитата:
Сообщение от Patron
Тогда понятно, почему квитирование в Windows нормально работает только с теми портами, которые умеют передавать два стоповых бита. Пока порт передаёт второй стоповый бит - драйвер успевает обработать прерывание и запретить передачу.Цитата:
Сообщение от Alex_K
СTS выставляется после приема первого байта, если в момент выставления CTS начал приниматься следующий байт, то он будет принят. Иначе пофигу сколько байт принимать два или двадцать два.Цитата:
Сообщение от Patron
Вот поэтому со стандартным портом у меня работало только тогда, когда я ставил в настройках два стоп-бита. С одним стоп-битом у меня работало с портом на чипе Oxford, но он довольно крутой, может там есть и аппаратное квитирование.Цитата:
Сообщение от Patron
Квитирование снимается после начала приёма первого стопового бита второго байта, если первый принятый байт к этому моменту ещё не прочитан из буфера. У передающей стороны есть два битовых интервала, чтобы отреагировать на снятие квитирования и прекратить передачу.Цитата:
Сообщение от Vamos
Вот это правильно, а теперь зайдем в пульт и начнем из HX_Server с вкладки телетайп отправлять байты, то после обращения к порту в пульте мы прочитаем последовательно все отправленные байты из HX_Server - а это не правильно.Цитата:
Сообщение от Patron
http://zx-pk.ru/showthread.php?t=160...l=1#post564966
HX_Server отправляет байты в поток байтов. Поток байтов отправляет байты в буфер адаптера COM-порта размером 128К. Адаптер COM-порта отправляет байты в буфер драйвера Windows размером 4К, а драйвер Windows отправляет байты в буфер FIFO размером 16 байтов.Цитата:
Сообщение от Vamos
Такая длинная цепочка приводит к тому, что если какая-то из инстанций отказывается принимать байты - байты накапливаются в буфере предыдущей инстанции. Так и должно быть - если на каком-то этапе передающей цепочки возникла заминка - передача должна остановиться ( без потери байтов ) до возможности продолжения. Что и происходит - всё отлично работает и ни один байт не теряется. Сброс содержимого буферов происходит, если терминал передаёт BREAK. Те байты, которые не успели покинуть PC до сигнала BREAK - будут потеряны, чтобы "очистить дорогу" для свежих байтов.
Ну не знаю что Вам еще сказать. Сделал так что CTS снят постоянно, подключил гипер терминал виндовый, в настройках "управление потоком" указал "аппаратное" ни одного байта посланного из гипер терминала не попало в UKNCBTL, подключил HX_Server, сигнал CTS не зеленый, отправил 4 байта в UKNCBTL прилетел 1-й потом переполнение и потом 3-й и 4-й, и так несколько раз. Думаю что и на железе происходит тоже самое, проверить смогу позже.
Так что ищите ошибку в своей длинной цепочке.
Виноват, подзабыл. А Вы не забыли его отключить? В смысле, урезать глубину до 1? А то я вспомнил, откуда мои утверждения про компорты берут начало. Мне так и не удалось заставить MSM-PC 3.10 обслуживать терминалы через любые мульти-комы, кроме тех, которые были на чипах 8250. (Это единственный писюшный компорт без FIFO. ) А MSM 3.xx ничего не знал про эти FIFO, староват был. И, естественно, при попытке притормозить поток (в том числе и аппаратной, когда, допустим, включишь на терминале плавный скроллинг) данные терялись. Я тогда попытался выключить это FIFO, но не справился, где-то там оно восстанавливалось, а где - я не нашел, ядро MSM слишком уж толстое.Цитата:
Сообщение от Patron