PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Исходник теста даёт все ответы
При каждом приёме 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...
Последний раз редактировалось form; 07.02.2013 в 21:37.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Точно!
Учитывая, что один бит в порту С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 длиной хоть целый час![]()
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Посылается чистый BREAK - это хорошо видно, когда время его установки меньше времени приёма байта - тогда вместо BREAK принимается фиктивный байт.
---------- Post added at 20:51 ---------- Previous post was at 20:50 ----------
Если настроить порты на 2400, то при получении BREAK длиной 1 мс или 2 мс - тоже будут приняты фиктивные байты.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Байты принимаются в течении 65000 циклов SOB - если после фиктивного байта не пришёл "дополнительный" ноль - значит посылался чистый BREAK.
Убедившись, что в том пункте, где принимается 2 мс BREAK, всё без обмана - переключаем порты обратно на 9600 и принимаем нулевой байт.
Новый тест - BRKT3 должен делать дамп последовательных состояний регистра статуса приёмника при приёме сигнала BREAK.
Главная тонкость там - так настроить задержки, чтобы захватить как раз интересующий интервал. Интересно, насколько это удалось.
...
Так это он и есть. Принятый байт ведь передаётся в младшем байте регистра данных, а раз при установке бита готовности там ноль - значит был принят ноль. А с брейком этот байт был принят или без брейка - это уже подробности ( вот, например, ВП1-065 при приёме брейка устанавливает бит брейка только через 100 мкс после установки бита готовности - а до того отличить приём брейка от приёма обычного нулевого байта вообще невозможно ).
...
Последний раз редактировалось Patron; 07.02.2013 в 23:24.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)