Будут при условии поступления в порт данных. При BREAK их не поступает.
Я уже попробовал замерять длительность BREAK, но все уперлось в то, что символов в порт не поступает и регистрируется только сам BREAK.
Исходник теста даёт все ответы
При каждом приёме BREAK порт PDP-11 принимает ровно один нулевой байт.Код:NewVTest:
MovB (R4), (R5)+
RtI
START:
Mov #TKB, R4
Mov #ResBuf, R5
Tst (R4)
Ask_For_Break_And_Wait
Mov #ResBuf, R3
Sub R3, R5
31$:
TstB @#TTPS
BPl .-4.
MovB (R3)+, @#TTPB
SOB R5, 31$
Я исходник тоже публиковал - попробуй найти в нем почему (правильно) принимается только сам BREAK. Могу дать исходник попроще - в котором делалась попытка замерить длительность BREAK - чем она кончилась сказано выше - никаких символов не поступает.
---------- Post added at 00:28 ---------- Previous post was at 00:28 ----------
Ну это может быть - про 1801 ничего не скажу.
---------- Post added at 00:32 ---------- Previous post was at 00:28 ----------
Вот собственно исходник - часть которая "меряет" BREAK короткая.
Никакого нулевого символа на DLV11-J не принимается (если не считать приема символа для которого установлен FE).
Код:.TITLE BRKT
.IDENT /V01.00/
PSW == 177776
TKS == 177560
FERR == 20000
LKS == 177546
IE == 100
BCSR == 177520
C800 == 6000
EHOB == 1000
CR == 15
LF == 12
$TTKS:: .WORD TKS
START:: MOV #SYSTM,@#20
MOV #340,@#22
IOT
TIMER:: ADC $TIME+2
ADC $TIME
RTI
$TIME:: .BLKW 2
SYSTM:: MOV #START,SP
RESET
MOV #TIMER,@#100
MOV #341,@#102
MOV $TTKS,R5
MOV #IDENT,R1
CALL PRSTR
BIS #C800,@#BCSR
.IIF EQ TKS-177560 BIC #HOB,@#BCSR
CLR @#PSW
10$: CLR $TIME+2
CLR $TIME
20$: BIT #20000,2(R5)
BEQ 20$
BIS #IE,@#LKS
30$: BIT #20000,2(R5)
BNE 30$
CLR @#LKS
MOV $TIME,R2
MOV $TIME+2,R3
MOV #125.,R0
CALL $DMUL
MOV R1,R2
MOV R0,R1
MOV #100.,R0
CALL $DDIV
MOV R1,R3
MOV R0,-(SP)
CALL PRDEC
MOV #'.,R0
CALL PRCHR
MOV (SP)+,R2
CLR R3
CALL PRDEC
MOV #CR,R0
CALL PRCHR
MOV #LF,R0
CALL PRCHR
BR 10$
PRSTR:: MOVB (R1)+,R0
BEQ 10$
CALL PRCHR
BR PRSTR
10$: RETURN
PRCHR:: TSTB 4(R5)
BPL .-4
MOVB R0,6(R5)
RETURN
PRDEC:: MOV #POWER,R4
CLR R1
10$: MOV #'0,R0
20$: SUB @R4,R2
SBC R3
SUB 2(R4),R3
BLT 30$
INC R0
INC R1
BR 20$
30$: ADD @R4,R2
ADC R3
ADD 2(R4),R3
TST R1
BNE 40$
TST 4(R4)
BNE 50$
40$: CALL PRCHR
50$: CMP (R4)+,(R4)+
TST @R4
BNE 10$
RETURN
POWER:: .WORD 145000,35632 ;1000000000.
.WORD 160400,2765 ;100000000.
.WORD 113200,230 ;10000000.
.WORD 41100,17 ;1000000.
.WORD 103240,1 ;100000.
.WORD 23420,0 ;10000.
.WORD 1750,0 ;1000.
.WORD 144,0 ;100.
.WORD 12,0 ;10.
.WORD 1,0 ;1.
.WORD 0
IDENT:: .ASCIZ /BREAK TIMING TEST V1.0/<CR><LF>
.END START
---------- Post added at 00:34 ---------- Previous post was at 00:32 ----------
Хотя прошлый пример лучше - там готовность проверялась, а здесь бит FE...
Точно!
Учитывая, что один бит в порту С2 принимается больше чем за 100 мкс - вполне можно написать "дампер состояния", который будет копировать регистр состояния в буфер каждые 50 мкс, а затем "сливать" весь дамп в битовом виде в лог сервера HX.
---------- Post added at 20:42 ---------- Previous post was at 20:35 ----------
Если там используется прерывание и оно происходит - значит в статусе принимающего порта устанавливается бит готовности, т.е. принимается байт.
У меня исходник проще - там сначала делается большая задержка, потом читается регистр данных, чтобы сбросить бит готовности, потом у сервера запрашивается BREAK и ожидаются прерывания, при каждом из которых из регистра данных копируется принятый байт.
Ну так вот тебе простейший тест который уже делали:
Тут видно, что как происходит прерывание, сохраняется весь TKB. Тест показал, что BREAK длиной в 8 символов выдает только одно прерывание при котором принимается FE и ничего больше. Так что если твой HX Server шлет еще что-то, надо говорить о том, что (из виндовса) посылается еще нулевой байт, а не о том, что он принимается.Код:RINT:: MOV @#RDA,(R5)+
DEC R4
BNE 20$
10$: CLR @#LCS
CLR @#TCS
CLR @#RCS
MOV #TDONE,@SP
MOV #340,2(SP)
20$: RTI
---------- Post added at 00:47 ---------- Previous post was at 00:44 ----------
PS. Тестил BREAK из SecureCRT (windows) и VT220 - аналогично - регистрируется BREAK и никакого нуля.
---------- Post added at 00:47 ---------- Previous post was at 00:47 ----------
Могу для интереса CM7209 проверить = там можно послать BREAK длиной хоть целый час :)
Посылается чистый BREAK - это хорошо видно, когда время его установки меньше времени приёма байта - тогда вместо BREAK принимается фиктивный байт.
---------- Post added at 20:51 ---------- Previous post was at 20:50 ----------
Если настроить порты на 2400, то при получении BREAK длиной 1 мс или 2 мс - тоже будут приняты фиктивные байты.
Байты принимаются в течении 65000 циклов SOB - если после фиктивного байта не пришёл "дополнительный" ноль - значит посылался чистый BREAK.
Убедившись, что в том пункте, где принимается 2 мс BREAK, всё без обмана - переключаем порты обратно на 9600 и принимаем нулевой байт.
Новый тест - BRKT3 должен делать дамп последовательных состояний регистра статуса приёмника при приёме сигнала BREAK.
Главная тонкость там - так настроить задержки, чтобы захватить как раз интересующий интервал. Интересно, насколько это удалось.
...
Так это он и есть. Принятый байт ведь передаётся в младшем байте регистра данных, а раз при установке бита готовности там ноль - значит был принят ноль. А с брейком этот байт был принят или без брейка - это уже подробности ( вот, например, ВП1-065 при приёме брейка устанавливает бит брейка только через 100 мкс после установки бита готовности - а до того отличить приём брейка от приёма обычного нулевого байта вообще невозможно ).
...