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
В самом начале тестирования HX-сервера с УКНЦ - квитирование, помнится, не хотело работать.
А что если HX-сервер не всё сетапит в COM-порту, что надо - и поэтому нормально работает только тогда, когда между включением PC и его запуском не запускались другие программы, работающие с тем же COM-портом..
Возможно, есть смысл это проверить, запустив на этом же COM-порту сначала эмулятор TU58 или HyperTerminal и только затем - HX-сервер.
Эмулятор TU58 работает только на полноценных портах. На моем ST-Labовском USBшном двойнике к примеру работать не будет из-за кривой реализации break (подозреваю, что драйвера такие [у всех pci, usb железок]). А HX вполне пашет несмотря на то, что порт плюется громадными пакетами символов за раз
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
Квитирование не хотело работать по другой причине. Первое - передача с УКНЦ уходила всегда, потому что всегда на входе BSYD 1801ВП1-065 был активный уровень, связанный с настройками fRtsControl = RTS_CONTROL_ENABLE. После изменения на fRtsControl = RTS_CONTROL_HANDSHAKE все стало в этом плане нормально работать. В случае с приемом ситуация оказалась потяжелее. После получения очередного байта 1801ВП1-065 выставлял неактивный уровень на выходе RR. По идее Windows со своей стороны должна была это видеть и прекратить передачу со своей стороны. Решилось это следующими установками: fOutxCtsFlow = TRUE и StopBits = TWOSTOPBITS. Первая установка заставляет следить Windows за уровнем сигнала CTS, и не передавать, когда он неактивный. А вот два стоп-бита пришлось поставить потому, потому что с одним стоп-битом Windows не успевала обрабатывать CTS и умудрялась послать очередной байт, в связи с чем на УКНЦ возникала ошибка переполнения, если предыдущий байт не был считан.
Но попробую запущу и TU58, и гипертерминал, но попозже.
Новый вариант сервера ( HX_Server 2.1_-_UKNC_13.01.13_18-28 ) с загрузчиком Boot_RT-11_from_HX0.bin, который (якобы):
1. При обнаружении любой ошибки протокола - входит в режим пропуска байтов, из которого выходит только тогда, когда за 12 выводов байта 015 в порт терминала - в порт HX не поступит ни одного байта от сервера.
2. При входе в первичный драйвер запоминает параметры вызова процедуры чтения и, в случае ошибки передачи - после процедур, описанных выше - повторяет ошибочно завершившийся запрос.
...
Последний раз редактировалось Patron; 23.09.2014 в 15:18.
Попробовал провести опыт с USB-COM-портом. Чип Prolific PL2303-HXA, сейчас он уже не поддерживается производителем, драйвера старые. Использовал HX-сервер версии "HX_Server 2.1_-_UKNC_12.01.13_16-01".
Первоначально все шло замечательно, загрузка прошла с включенным сжатием, никаких зависаний и ошибок. Тест командой DIR/BAD/FIL прошел без всяких проблем, во время чтения данных выходил в пультовый отладчик и смотрел регистр 176570, никакого переполнения.
Проблемки начались при исполнении команды COP/DEV HX0: HX7:. При нажатии кнопки "Stop reading" посылка данных останавливалась, при отжатии - возобновлялась, проблем нет. Оставил исполняться команду до конца. Во время HX-WRITE появилась ошибка контрольной суммы. На этом завершилось. Перезапустил HX-сервер и УКНЦ, прогрузка с включенным сжатием не пошла - ошибки переполнения.
Ну чтож, передернул в USB COM-порт, далее все пошло как надо, но на команде COP/DEV HX0: HX7: на HX_WRITE опять встало, никаких ошибок и никакого обмена.
---------- Post added at 20:21 ---------- Previous post was at 20:20 ----------
Завтра возьму на работе PCI-COM-порты, интересно как с ними будет?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)