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

[Patron]

Для сигналов RTS и CTS на роль логического анализатора должен хорошо подойти обычный вольтметр.

...

В принципе - при установке

fRtsControl  = RTS_CONTROL_HANDSHAKE

Windows как раз должна выставлять сигнал RTS, когда свободна хотя бы половина приёмного буфера FIFO, и снимать его, когда приёмный буфер FIFO заполнен больше, чем на 3/4.

Очевидно, что при отключенных буферах FIFO эта опция нормально работать не может.

[Advertiser]

[Alex_K]

Насколько я понял - в режиме RTS_CONTROL_ENABLE квитирование на приём в Windows отключено и независимо от заполненности приёмного буфера FIFO - сигнал разрешения передачи ( RTS ) не снимается.

Если это так и, не запуская сервер - дать какую-нибудь команду чтения HX ( например DIR HX0: ) - то драйвер выдаст запрос и когда приёмный буфер FIFO активен - запрос закешируется и прочтётся сервером после запуска, а когда приёмный буфер FIFO выключен - запрос должен пропасть.

Кстати - если запрос пропал и драйвер HX.SYS висит в ожидании ответа - он отвалится по ошибке, если ему вручную послать Ctrl/C.

Покурив более подробно доки, я тоже пришел к этому выводу. При RTS_CONTROL_ENABLE сигнал RTS устанавливается и остается на все время обмена, но состояние линии RTS можно менять с помощью EscapeCommFunction.
Тут я не думаю, что это связано с буферами FIFO, скорее со своими внутренними в Windows.

---------- Post added at 19:14 ---------- Previous post was at 19:12 ----------

В принципе - при установке

fRtsControl  = RTS_CONTROL_HANDSHAKE

Windows как раз должна выставлять сигнал RTS, когда свободна хотя бы половина приёмного буфера FIFO, и снимать его, когда приёмный буфер FIFO заполнен больше, чем на 3/4.

Очевидно, что при отключенных буферах FIFO эта опция нормально работать не может.

А вот сейчас я выставил fRtsControl = RTS_CONTROL_HANDSHAKE и провожу тест. Уже идет копирование с HX0: на HX7:, пока все нормально. Буфера FIFO в настройках UART включены.

[Patron]

А вот сейчас я выставил fRtsControl = RTS_CONTROL_HANDSHAKE и провожу тест.

Тут главная фишка в том, что когда в Windows никто не читает порт - после заполнения входного буфера должен автоматически сниматься сигнал RTS.

Чтобы это проверить - я написал драйвер C2.SYS, который позволяет копировать текстовые файлы из RT-11 в порт C2.

Новый вариант - HX_Server 2.0 - UKNC_09.01.13_19-35, где добавлено окно Teletype, на которое выводится терминальный обмен в порту C2.

Если загрузить RT-11 с драйвером C2.SYS не через HX, завершить HX-сервер и дать в УКНЦ команду копирования на C2: какого-нибудь довольно большого ASCII-файла ( больше, чем входной буфер COM-порта в Windows ), то после запуска HX-сервера в окно Teletype должен выйти весь отправленный текст без потери байтов.

...

[Alex_K]

Тут главная фишка в том, что когда в Windows никто не читает порт - после заполнения входного буфера должен автоматически сниматься сигнал RTS.
...
Если загрузить RT-11 с драйвером C2.SYS не через HX, завершить HX-сервер и дать в УКНЦ команду копирования на C2: какого-нибудь довольно большого ASCII-файла ( больше, чем входной буфер COM-порта в Windows ), то после запуска HX-сервера в окно Teletype должен выйти весь отправленный текст без потери байтов.

Ну грузиться с дискеты мне пока влом. Но провел такой опыт. Порт по умолчанию в менеджере устройств настроен на 9600,8N2, аппаратный контроль, буфера FIFO включены. Захожу в пультовый отладчик, смотрю регистр 176574, стоит 0200, т.е. готовность есть. Записываю байт 041 в регистр 176576, далее смотрю регистр 176574, в регистре 0, бит готовности не установлен. Т.е. либо посылка не ушла, либо линия RTS неактивна, а значит неактивный уровень на входе BSYD 1801ВП1-065, тогда посылке не уйти.
После запуска HX-сервера готовность в регистре 176574 устанавливается и все, что заносится в 176576, отображается в окне Teletype. Но посланный ранее байт 041 не отображается.

[Patron]

После запуска HX-сервера готовность в регистре 176574 устанавливается и все, что заносится в 176576, отображается в окне Teletype. Но посланный ранее байт 041 не отображается.

Похоже, пока Com-порт не открыт в программе для чтения/записи - Windows не копирует данные из буфера FIFO в потоковый буфер подсистемы ввода-вывода.

Посмотрел код написанных мною полгода назад функций чтения и записи порта (в исходнике адаптера COM-порта модульного API) и понял, что без потоковых буферов Windows эти функции читали бы и писали не больше 60 байтов в секунду. Переписал этот код - теперь и чтение, и запись должны работать немного быстрее.

Новый вариант - HX_Server 2.0 - UKNC_09.01.13_21-02 с изменёнными алгоритмами чтения и записи COM-порта.

...

[Alex_K]

Похоже, пока Com-порт не открыт в программе для чтения/записи - Windows не копирует данные из буфера FIFO в потоковый буфер подсистемы ввода-вывода.

Вообще-то похоже, что пока COM-порт не открыт, то не установлены сигналы DTR и RTS, а без установленного RTS у меня с моим кабелем не уходят посылки, т.к. на входе BSYD неактивный уровень. И даже если есть возможность записать один байт, то он все равно не получается HX-сервером при запуске. Видно при открытии идет инициализация COM-порта и очистка всех буферов Windows.

---------- Post added at 21:19 ---------- Previous post was at 21:14 ----------

Посмотрел код написанных мною полгода назад функций чтения и записи порта (в исходнике адаптера COM-порта модульного API) и понял, что без потоковых буферов Windows эти функции читали бы и писали не больше 60 байтов в секунду.

Откуда такая уверенность, что не более 60-ти? Все версии HX-сервера, которые выкладывались, использовали COM-порт под полную катушку на скорости порта 9600,8N2. Проблем не возникло ни при чтении, ни при записи (проводил же тест командой COPY/DEV HX0: HX7:).

[Patron]

Откуда такая уверенность, что не более 60-ти?

Это я слегка утрировал. При записи больших проблем не было. Но при чтении вызов Read производился только 60 раз в секунду, причём без ожидания дополнительных данных. Если бы не потоковые буфера Windows - таким манером нельзя было бы прочитать очень много байтов, а так - 60 раз в секунду адаптер принимал из Windows сразу по нескольку десятков байтов.

В реальной ситуцации ( в которой и старая версия смотрелась неплохо ) новая версия имеет следующие преимущества:

1. Первый байт, поступивший в COM-порт - попадает в байтовый поток модульного API немедленно, а не с задержкой в 15 мс.

2. Если поступили новые байты для вывода за то время, пока адаптер передавал байты в потоковый буфер Windows - новый вывод в потоковый буфер Windows начинается сразу же, а не через 15 мс ( понятно, что это не очень критично, когда в буфер Windows уже "напихано" байтов на минуту передачи ).

[Alex_K]

Посмотрел код написанных мною полгода назад функций чтения и записи порта (в исходнике адаптера COM-порта модульного API) и понял, что без потоковых буферов Windows эти функции читали бы и писали не больше 60 байтов в секунду. Переписал этот код - теперь и чтение, и запись должны работать немного быстрее.

Увы. Практический опыт показывает обратное. Копирую диск в диск командой COP/DEV HX0: HX7:. Копируется по 38400 байт.
В новейшей версии HX_Server 2.0 - UKNC_09.01.13_21-02 чтение идет 73 сек в среднем, а запись около 45 секунд. А в предыдущей версии HX_Server 2.0 - UKNC_09.01.13_19-35 и чтение и запись выполнялись за 44 секунды. Так что в предыдущей версии порт использовался на пределе своих возможностей.

[palsw]

да работает же все нормально.зачем еще мучать?

---------- Post added at 20:59 ---------- Previous post was at 20:58 ----------

Alex_K, вп1-065 переключил на укнц на скорость выше 9600?можно фото где эти перемычки искать?

[Patron]

в предыдущей версии порт использовался на пределе своих возможностей.

Прикольно.

Вернём предыдущие коды чтения в адаптер порта и добавим туда возможность блокировки чтения: HX_Server 2.0 - UKNC_09.01.13_23-19

Теперь в окне Teletype есть кнопка [Stop Reading], при нажатии которой сервер вообще перестаёт обращаться в Windows за байтами из COM-порта.

На случай, если потоковые буфера Windows имеют размер под сотню килобайт - написана специальная программа SPAM.SAV, посылющая в порт С2 УКНЦ столько байтов - что мало не покажется.

...