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

[Vamos]

Но к работе с портом -065 это большого отношения не имеет, потому что ( из-за огромного буфера приёма ) Windows никогда не снимает RTS при приёме и из-за этого нет практической разницы между RTS_CONTROL_HANDSHAKE и RTS_CONTROL_ENABLE.

А 065 снимает.

Аппаратное квитирование приёма в COM-порт активируется только при RTS_CONTROL_HANDSHAKE.

Настройки RTS_CONTROL_ENABLE и RTS_CONTROL_DISABLE отключают аппаратное квитирование приёма в COM-порт и напрямую задают неизменное состояние линии RTS.

Это при приеме в РС, а при передаче из РС должна быть реакция на RTS снятием CTS и прекращением передачи, а уж в буфер Windows или в аппаратный буфер это уже вторично.

Понятно что это программа терминал и ей нужно отправлять символы, чтобы пользователь не ждал. Но раз уж она используется для загрузки другого компа, может сделаете специальный режим или в HANDSHAKE моде, а я проверю на эмуляторе загрузку со сжатием.

- - - Добавлено - - -

RTS_CONTROL_HANDSHAKE Включает процедуру установления связи RTS. Драйвер поднимает линию RTS, когда (входной) буфер "опережающего ввода с клавиатуры" заполнен меньше, чем на половину и понижает линию RTS, когда буфер заполнен больше, чем на три четверти.

потому что ( из-за огромного буфера приёма ) Windows никогда не снимает RTS при приёме и из-за этого нет практической разницы между RTS_CONTROL_HANDSHAKE и RTS_CONTROL_ENABLE

Немного сумбурно излагаю уж извините . Я пытаюсь объяснить что за выходным буфером Windows не следит и если HX_Server продолжает слать байты не смотря на сигнал CTS (порт на выход закрыт), то и буфера в 4К может не хватить, в итоге потери информации и ошибки загрузки. Как-то так.

- - - Добавлено - - -

вот что происходит, как раз в момент передачи блока в 16К на 1-2 сек. гаснет CTS но поскольку HX_Server продолжает слать байты выходной буфер переполняется и потом загрузка встает из-за неверно переданной информации (ошибок переполнения сейчас нет)