HX_Server не анализирует сигналы порта - это делает драйвер Windows, настройки для которого содержатся в файле Terminal_ComPort_Adapter.iniOriginally Posted by Vamos
За реакцию драйвера на сигнал CTS отвечает параметр fOutxCtsFlow ( FALSE - не реагировать, TRUE - реагировать ).
Без сжатия проблем с переполнением быть не может, потому что задержек при приёме байтов нет.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Да настройки здесь не причем, я же привел ссылки на посты. Ситуация следующая, при передаче одного байта из окна "телетайп" HX_Server и при условии что он не прочитан из регистра приемника, лампочка CTS гаснет (на панели HX_Server) т.е. реакция на RTS есть. НО если продолжать печатать символы в телетайпе они окажутся в буфере драйвера передатчика Windows, что в принципе не правильно, правильно не передавать байты до снятия сигнала RTS.
Поэтому и происходит либо переполнение (если принимающая сторона начинает читать буфер) или ошибка пакета из-за чтения байтов из буфера и не приемом их во регистр приемника.
До снятия квитирования порт -065 может принять два байта. Один байт при этом находится в буфере приёмника, а другой - в сдвиговом регистре приёмника. Квитирование снимается при невозможности переписать из сдвигового регистра в буфер.
В цепочке порт - драйвер - программа на RTS должен реагировать порт ( у COM-порта есть внутренний буфер на несколько байтов ). Драйвер настраивает порт, принимает данные от программы в буфер драйвера ( 4К ) и передаёт в буфер порта. Если COM-порт не может правильно отреагировать на квитирование - работа невозможна, потому что данные передаются COM-портом не из буфера программы и даже не из буфера драйвера, а из собственного аппаратного буфера COM-порта.
Наоборот - именно так и надо делать. Буфер драйвера у Windows очень большой, а за работу с квитированием отвечают не программа и не драйвер, а настроенная драйвером аппаратура COM-порта.
RTS_CONTROL_ENABLE Включает в работу линию RTS, когда устройство открывается и оставляет ее включенной.
RTS_CONTROL_HANDSHAKE Включает процедуру установления связи RTS. Драйвер поднимает линию RTS, когда (входной) буфер "опережающего ввода с клавиатуры" заполнен меньше, чем на половину и понижает линию RTS, когда буфер заполнен больше, чем на три четверти.
То как сейчас сделано справедливо для HANDSHAKE, но так нельзя делать для ENABLE ибо это режим для аппаратного квитирования и буферы Windows не должны влиять на эмуляцию работы порта.
Аппаратное квитирование приёма в COM-порт активируется только при RTS_CONTROL_HANDSHAKE.
Настройки RTS_CONTROL_ENABLE и RTS_CONTROL_DISABLE отключают аппаратное квитирование приёма в COM-порт и напрямую задают неизменное состояние линии RTS.
Но к работе с портом -065 это большого отношения не имеет, потому что ( из-за огромного буфера приёма ) Windows никогда не снимает RTS при приёме и из-за этого нет практической разницы между RTS_CONTROL_HANDSHAKE и RTS_CONTROL_ENABLE.
Last edited by Patron; 8th February 2016 at 21:24.
А 065 снимает.
Это при приеме в РС, а при передаче из РС должна быть реакция на RTS снятием CTS и прекращением передачи, а уж в буфер Windows или в аппаратный буфер это уже вторично.
Понятно что это программа терминал и ей нужно отправлять символы, чтобы пользователь не ждал. Но раз уж она используется для загрузки другого компа, может сделаете специальный режим или в HANDSHAKE моде, а я проверю на эмуляторе загрузку со сжатием.
- - - Добавлено - - -
Немного сумбурно излагаю уж извините. Я пытаюсь объяснить что за выходным буфером Windows не следит и если HX_Server продолжает слать байты не смотря на сигнал CTS (порт на выход закрыт), то и буфера в 4К может не хватить, в итоге потери информации и ошибки загрузки. Как-то так.
- - - Добавлено - - -
вот что происходит, как раз в момент передачи блока в 16К на 1-2 сек. гаснет CTS но поскольку HX_Server продолжает слать байты выходной буфер переполняется и потом загрузка встает из-за неверно переданной информации (ошибок переполнения сейчас нет)
Тот RTS, поведение которого настраивает RTS_CONTROL_HANDSHAKE - не имеет ни малейшего отношения к тому RTS, который снимает 065.
RTS от 065 приходит в COM-порт на вход CTS и за его обслуживание отвечает настройка fOutxCtsFlow ( FALSE - не реагировать, TRUE - реагировать ).
Сейчас заглянул в код - адаптер COM-порта, создаваемый сервером HX, имеет выходной буфер 128К и передаёт оттуда по одному байту в ответ на прерывание "предыдущий байт передан" от драйвера Windows. Если при передаче возникают ошибки - это аппаратная проблема COM-порта. Обвинять драйвер Windows в неумении работать с COM-портом бессмысленно. Когда COM-порт работает нормально - ни малейших проблем не возникает.
Угу. Если ДВК/УКНЦ успевает все забрать. Мгновенно остановить передающий писюшный компорт, как этого требует логика работы -065, невозможно. Так, что, получив на писюшной стороне CTS, можно быть уверенным: данные на стороне ДВК/УКНЦ уже потеряны.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Это так только на кривых портах. На нормальных COM-портах всё работает без проблем.
Кроме того ( насколько я понимаю ), обсуждаемая проблема вообще не относится к работе портов, а вызвана отсутствием гальванической развязки сигналов квитирования. На сигнале приёма 065 при работе нет постоянной составляющей, поэтому при 3-проводной схеме соединения портов всё отлично работает без гальванической развязки ( как и должно ), но при добавлении в кабель линий квитирования - присутствующий на линии квитирования приёма в PC во время работы постоянный уровень вызывает сбои приёма 065 примерно для 1 байта из 10000.
- - - Добавлено - - -
Поскольку линия квитирования приёма в PC при работе не используется и единственная её роль - вызывать сбои в работе 065 - мною ранее уже предлагался вариант кабеля без этой линии, но до сих пор никто из владельцев сбоящих 065 не решился опробовать такой кабель.
Last edited by Patron; 9th February 2016 at 13:17.
Попытка привести к классическому или упрощенному кабелю всегда будет наталкиваться на "ну должно же работать". В электрике народ в основном не силен - доводы даже приводить бессмысленно, остается надеятся, что хотя бы никто не столкнется с попытками связать между этажами
Трехжилка (как и положено в DL(V)11 [при прямой связке]) наше все
- - - Добавлено - - -
Жаль, что не так много народу пробовало подключить нстоящий терминал к настоящему железу - помогает
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote
