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

[Patron]

Принимается столько нулевых байтов сколько их отправлено.

Фокус в том, что передающий порт передаёт "непрерывный ноль" вне зависимости от наличия байта для передачи в сдвиговом регистре. Поэтому принимающий порт будет получать нули даже тогда, когда сдвиговый регистр передающего порта пуст. Даже если принимающий порт имеет отличающиеся настройки - он будет принимать нули в режиме BREAK.

Или когда сдвиговый регистр пуст - порт в режиме BREAK будет передавать единицы (стоповые биты) ?

[form]

Фокус в том, что передающий порт передаёт "непрерывный ноль" вне зависимости от наличия байта для передачи в сдвиговом регистре. Поэтому принимающий порт будет получать нули даже тогда, когда сдвиговый регистр передающего порта пуст. Даже если принимающий порт имеет отличающиеся настройки - он будет принимать нули в режиме BREAK.

Именно так. Передаваемые при установленном BREAK байты нжны исключительно чтобы вычислить длительности BREAK. А что касается принимающего порта, как я и говорил, BREAK гарантированно идентифицируется и принятое значение само по себе не имеет значения.
Достаточно принимать из TKB не байт, а слово, чтобы следующей командой поставить BMI, а там куда BMI передается проверить frame error.

[Patron]

BREAK гарантированно идентифицируется и принятое значение само по себе не имеет значения

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

[form]

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

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

[Patron]

com0com только один нулевой байт принимает вне зависимости от продолжительности BREAK, а что реальный COM-порт - сколько нулевых байтов принимает при непрерывном нуле на входе ?

[form]

com0com только один нулевой байт принимает вне зависимости от продолжительности BREAK, а что реальный COM-порт - сколько нулевых байтов принимает при непрерывном нуле на входе ?

Столько сколько полных посылок передается.

[Advertiser]

[Patron]

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

Т.е. обнулятся даже те биты, которые были приняты до установки BREAK ?

Но если установить BREAK на время передачи только одного бита - только он, наверное, и окажется обнулённым.

[Alex_K]

Т.е. обнулятся даже те биты, которые были приняты до установки BREAK ?

В каком смысле? Как я понял сначала послать байт на выдачу, а затем установить бит подачи BREAK во время его посылки?

Но если установить BREAK на время передачи только одного бита - только он, наверное, и окажется обнулённым.

Возможно, если не стартовым.

[Patron]

В каком смысле? Как я понял сначала послать байт на выдачу, а затем установить бит подачи BREAK во время его посылки?

Ну, да - это же общий случай. Допустим, 7 битов передаваемого байта из 8 уже попали в сдвиговый регистр принимающего порта, как вдруг программа на передающей стороне установила в передающем порту бит BREAK. Что окажется в регистре данных принимающего порта после установки бита готовности его приёмника ?

[Alex_K]

Ну, да - это же общий случай. Допустим, 7 битов передаваемого байта из 8 уже попали в сдвиговый регистр принимающего порта, как вдруг программа на передающей стороне установила в передающем порту бит BREAK. Что окажется в регистре данных принимающего порта после установки бита готовности его приёмника ?

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

При нормальном BREAK, который устанавливает линию в это состояние, когда она пустая, естественно принимаются все нулевые биты.