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

[Patron]

RABBIT-1 грузил с HANDSHAKE плюс на древнем 486 РС.

HANDSHAKE на практике ни с чем не связан - Windows не снимает RTS, поэтому наличие/отсутствие линий квитирования на приём COM-порта не влияет.

Загрузка шла только с кабелем без квитирования. После добавления в кабель линий квитирования ( без изменения любых настроек ) загрузка уже не шла.

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

утверждает, что квитирование в РС аппаратное

Конечно, аппаратное - в каждом COM-порту PC есть аппаратный буфер FIFO, глубину которого можно настраивать:



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

вылет в СТОП по переполнению на втором байте при снятом CTS после приема 1 байта

До снятия CTS порт 065 принимает ДВА байта - иначе синхронная работа порта ( когда байты принимаются один за другим "без промежутков" ) была бы невозможна. Это легко проверить, запустив в пульте программу, крутящуюся минуту в пустом цикле, а потом читающую все байты, какие успел принять порт - если после запуска программы отправить в порт несколько байтов, то после обращения программы к порту - будут выведены первый и последний из переданных байтов.

[Advertiser]

[Alex_K]

Конечно, аппаратное - в каждом COM-порту PC есть аппаратный буфер FIFO, глубину которого можно настраивать:

Наличие буфера никоим образом с квитированием не связано. Стандартные чипы на PC аппаратно не обрабатывают квитирование, только возможно вызвать прерывание при изменении уровней сигнала CTS/RTS/DTR/DSR, всё остальное ложиться на программу.

[Patron]

Наличие буфера никоим образом с квитированием не связано. Стандартные чипы на PC аппаратно не обрабатывают квитирование, только возможно вызвать прерывание при изменении уровней сигнала CTS/RTS/DTR/DSR, всё остальное ложиться на программу.

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

[Vamos]

До выставления CTS порт 065 принимает ДВА байта - иначе синхронная работа порта ( когда байты принимаются один за другим "без промежутков" ) была бы невозможна

СTS выставляется после приема первого байта, если в момент выставления CTS начал приниматься следующий байт, то он будет принят. Иначе пофигу сколько байт принимать два или двадцать два.

[Alex_K]

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

Вот поэтому со стандартным портом у меня работало только тогда, когда я ставил в настройках два стоп-бита. С одним стоп-битом у меня работало с портом на чипе Oxford, но он довольно крутой, может там есть и аппаратное квитирование.

[Patron]

СTS выставляется после приема первого байта, если в момент выставления CTS начал приниматься следующий байт, то он будет принят.

Квитирование снимается после начала приёма первого стопового бита второго байта, если первый принятый байт к этому моменту ещё не прочитан из буфера. У передающей стороны есть два битовых интервала, чтобы отреагировать на снятие квитирования и прекратить передачу.

[Vamos]

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

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

http://zx-pk.ru/showthread.php?t=160...l=1#post564966

[Patron]

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

HX_Server отправляет байты в поток байтов. Поток байтов отправляет байты в буфер адаптера COM-порта размером 128К. Адаптер COM-порта отправляет байты в буфер драйвера Windows размером 4К, а драйвер Windows отправляет байты в буфер FIFO размером 16 байтов.

Такая длинная цепочка приводит к тому, что если какая-то из инстанций отказывается принимать байты - байты накапливаются в буфере предыдущей инстанции. Так и должно быть - если на каком-то этапе передающей цепочки возникла заминка - передача должна остановиться ( без потери байтов ) до возможности продолжения. Что и происходит - всё отлично работает и ни один байт не теряется. Сброс содержимого буферов происходит, если терминал передаёт BREAK. Те байты, которые не успели покинуть PC до сигнала BREAK - будут потеряны, чтобы "очистить дорогу" для свежих байтов.

[Vamos]

Ну не знаю что Вам еще сказать. Сделал так что CTS снят постоянно, подключил гипер терминал виндовый, в настройках "управление потоком" указал "аппаратное" ни одного байта посланного из гипер терминала не попало в UKNCBTL, подключил HX_Server, сигнал CTS не зеленый, отправил 4 байта в UKNCBTL прилетел 1-й потом переполнение и потом 3-й и 4-й, и так несколько раз. Думаю что и на железе происходит тоже самое, проверить смогу позже.
Так что ищите ошибку в своей длинной цепочке.

[AFZ]

Конечно, аппаратное - в каждом COM-порту PC есть аппаратный буфер FIFO, глубину которого можно настраивать:

Виноват, подзабыл. А Вы не забыли его отключить? В смысле, урезать глубину до 1? А то я вспомнил, откуда мои утверждения про компорты берут начало. Мне так и не удалось заставить MSM-PC 3.10 обслуживать терминалы через любые мульти-комы, кроме тех, которые были на чипах 8250. (Это единственный писюшный компорт без FIFO. ) А MSM 3.xx ничего не знал про эти FIFO, староват был. И, естественно, при попытке притормозить поток (в том числе и аппаратной, когда, допустим, включишь на терминале плавный скроллинг) данные терялись. Я тогда попытался выключить это FIFO, но не справился, где-то там оно восстанавливалось, а где - я не нашел, ядро MSM слишком уж толстое.