УКНЦ загрузка через стык С2

[form]

то у него не будет установлен бит готовности. Как-то вот так ...

Да, это я проверял когда свой драйвер писал.
Так, что остается просто кривой драйвер который всегда держит прерывания разрешенными. Ну или в FB можно в теории нарваться

[Patron]

В самом начале тестирования HX-сервера с УКНЦ - квитирование, помнится, не хотело работать.

А что если HX-сервер не всё сетапит в COM-порту, что надо - и поэтому нормально работает только тогда, когда между включением PC и его запуском не запускались другие программы, работающие с тем же COM-портом..

Возможно, есть смысл это проверить, запустив на этом же COM-порту сначала эмулятор TU58 или HyperTerminal и только затем - HX-сервер.

[form]

Эмулятор TU58 работает только на полноценных портах. На моем ST-Labовском USBшном двойнике к примеру работать не будет из-за кривой реализации break (подозреваю, что драйвера такие [у всех pci, usb железок]). А HX вполне пашет несмотря на то, что порт плюется громадными пакетами символов за раз

[Alex_K]

В самом начале тестирования HX-сервера с УКНЦ - квитирование, помнится, не хотело работать.

А что если HX-сервер не всё сетапит в COM-порту, что надо - и поэтому нормально работает только тогда, когда между включением PC и его запуском не запускались другие программы, работающие с тем же COM-портом..

Возможно, есть смысл это проверить, запустив на этом же COM-порту сначала эмулятор TU58 или HyperTerminal и только затем - HX-сервер.

Квитирование не хотело работать по другой причине. Первое - передача с УКНЦ уходила всегда, потому что всегда на входе 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, и гипертерминал, но попозже.

[Alex_K]

Возможно, есть смысл это проверить, запустив на этом же COM-порту сначала эмулятор TU58 или HyperTerminal и только затем - HX-сервер.

Ну, как и предполагалось все нормально работает и после запуска TU58, и после запуска гипертерминала. Ну а собственно и не могло быть иначе, ведь HX-сервер программирует COM-порт через структуру DCB.

[Patron]

с одним стоп-битом Windows не успевала обрабатывать CTS и умудрялась послать очередной байт, в связи с чем на УКНЦ возникала ошибка переполнения, если предыдущий байт не был считан.

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

[Alex_K]

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

Кажется неправильно. С одним стоп-битом работает, если не используется сжатие. Со сжатием сразу проблемы, если передаваемый блок большой и хорошо запакован.

[Patron]

Новый вариант сервера ( HX_Server 2.1_-_UKNC_13.01.13_18-28 ) с загрузчиком Boot_RT-11_from_HX0.bin, который (якобы):

1. При обнаружении любой ошибки протокола - входит в режим пропуска байтов, из которого выходит только тогда, когда за 12 выводов байта 015 в порт терминала - в порт HX не поступит ни одного байта от сервера.

2. При входе в первичный драйвер запоминает параметры вызова процедуры чтения и, в случае ошибки передачи - после процедур, описанных выше - повторяет ошибочно завершившийся запрос.

...

[Patron]

С одним стоп-битом работает

Теперь понятно, почему предыдущие попытки наладить управление потоком между PC и 1801ВП1-065 кончались печалью.

Байты от PC проходили и с одним стоповым битом, поэтому в ходе экспериментов никто не сподобился переключить COM-порт на два стоповых бита.

[Alex_K]

Попробовал провести опыт с 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-порты, интересно как с ними будет?