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

[Patron]

а если попробовать такой алгоритм

Объективная реальность такова, что даже при самой высокой скорости в порту С2 - драйвер HX.SYS прекрасно справляется на синхронных участках. Проблемы возникают только тогда, когда нужно распаковать сильно упакованный пакет. Однако, благодаря особенностям протокола HX - драйвер узнаёт о "приближении распаковки" за два байта до того, как ему придётся плотно заняться делом.

В этот момент драйвер вполне может попробовать "инспирировать" снятие сигнала квитирования, но всё же в последний момент прочитать следующий байт из порта и не дать ему пропасть. Сервер же, зная, что сигнал квитирования приходит только перед "большим затыком" - тут же начнёт "цедить байты" по одному, пока драйвер не освободится от забот и не восстановит синхронный обмен.

Всё, что для этого нужно - научить драйвер HX.SYS вытаскивать байт из порта "за один бит до оверрана" - когда стоповый бит уже пришёл, а стартовый ещё не начался.

---------- Post added at 03:25 ---------- Previous post was at 03:22 ----------

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

---------- Post added at 04:06 ---------- Previous post was at 03:25 ----------

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

Таким образом можно будет на любой скорости работать с любым контроллером порта по обычной двухпроводной линии без сигналов квитирования..

[Vamos]

Таким образом можно будет на любой скорости работать с любым контроллером порта по обычной двухпроводной линии без сигналов квитирования..

Вот это правильно, ибо на УКНЦ сигналы квитирования не выведены на С2.

[Alex_K]

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

Таким образом можно будет на любой скорости работать с любым контроллером порта по обычной двухпроводной линии без сигналов квитирования..

Согласен, я это тоже предлагал. К тому же квитирование делается внутри самой Windows, и делается это не совсем корректно.

Вот это правильно, ибо на УКНЦ сигналы квитирования не выведены на С2.

Vamos, а вот здесь я с Вами не соглашусь. Сами сигналы выведены на стык С2, и квитирование в 1801ВП1-065 аппаратное, программно им нельзя управлять. Если Вы соедините пару 1801ВП1-065, используя выводы RR и BSYD, то сможете обмениваться без всякой потери данных.

[Patron]

Интересно, что про скорость процессора и порта С2 скажет программа CPS_v1.8..

На эмулируемой ДВК-1 результат такой:

.RU CPS
 
CPS - Check Terminal Output Speed - v1.8
 
TEST ENGINE RATE FOR THIS CPU
    CPS: 9'005
 
Press ANY KEY to EXIT..
 
PORT 0176576 TESTED SPEED
    CPS: 937
 
Program completed.

[Alex_K]

Интересно, что про скорость процессора и порта С2 скажет программа CPS_v1.8..

Скорость процессора у меня показывает 11940-11990. Скорость порта - 868. При этом в HX-сервере показывается скорость на чтение около 940 символов. Тут еще не стоит забывать, что у 1801ВП1-065 всегда два стоп-бита, ну и в HX-сервере я тоже поставил два стоп-бита.

[Patron]

Скорость порта - 868. При этом в HX-сервере показывается скорость на чтение около 940 символов.

Если порт передаёт 10 битов на байт - его "техническая" скорость на 9600 BPS составляет - 960 CPS, а если 11 битов - 872 CPS.

Если сервер при приёме байтов устойчиво показывает 940 в секунду - это странно. Откуда он может получить столько байтов при 11 битах на байт..

в HX-сервере я тоже поставил два стоп-бита.

А когда мы вчера квитирование тестировали - COM-порт сервера уже был настроен на 2 стоповых бита ?

[Alex_K]

А когда мы вчера квитирование тестировали - COM-порт сервера уже был настроен на 2 стоповых бита ?

Да, уже стояло. Я обычно сразу новую версию и настраиваю.

Я тут достал старую литературку, там описан UART 8250. В описании порта 0x3FD есть такие слова - "Бит 5 - регистр хранения передатчика пуст, в него можно записать новый байт для передачи. Бит 6 - регистр сдвига передатчика пуст. Этот регистр получает данные из регистра хранения и преобразует их в последовательный вид для передачи". Это получается в UART можно сразу запихнуть два байта, один будет передаваться, а второй находится в регистре хранения. У меня так и было, когда я был в пультовом отладчике, читался регистр данных, следом HX-сервер передавал два байта и останавливался. Так что квитирование работает, но слишком поздно.

[Patron]

получается в UART можно сразу запихнуть два байта

Насколько я понимаю, у 1801ВП1-065 ситуация почти такая же. Если сдвиговый регистр пуст - бит готовности устанавливается сразу после копирования байта из регистра данных в сдвиговый, поэтому первое прерывание готовности вывода возникает почти сразу после помещения байта в регистр данных.

Это так?

[Alex_K]

Насколько я понимаю, у 1801ВП1-065 ситуация почти такая же. Если сдвиговый регистр пуст - бит готовности устанавливается сразу после копирования байта из регистра данных в сдвиговый, поэтому первое прерывание готовности вывода возникает почти сразу после помещения байта в регистр данных.

Это так?

Да, у 1801ВП1-065 есть и буферный регистр и сдвиговый регистр. Действительно после записи в буферный регистр при свободном сдвиговом, этот буферный регистр сразу копируется в сдвиговый и начинается передача. Во время этой передачи можно записать очередной байт. Но есть одно НО - это аппаратное квитирование, после передачи из буферного регистра также произойдет копирование в сдвиговый, но если на входе BSYD неактивный уровень, то передача не начнется. После появления активного уровня на входе BSYD передача возобновится.

[Patron]

Это я больше к тому, что у меня в "Эмуляторе ДВК" такая 2-ступенчатая буферизация передаваемого байта не эмулируется, поэтому результаты прогона CPS.SAV сильно отличаются от запусков на реальной ДВК.