![]() |
China DOS Union-- Unite DOS · Advance DOS · Grow DOS --Union site: www.cn-dos.net Forum site: www.cn-dos.net/forum |
| Guest | Log in | Register | Members | Search | China DOS Union |
|
中国DOS联盟论坛 The time now is 2026-09-15 00:56 |
47,812 topics / 349,917 posts / today 0 new / 48,268 members |
| DOS开发编程 & 发展交流 (开发室) » [Discussion] Interrupt response time in protected mode? |
| Printable Version 1,313 / 0 |
| Floor1 ATLaS | Posted 2003-07-09 00:00 |
| 初级用户 Posts 29 Credits 169 | |
|
The program is based on DJGPP V2.03 and GCC 3.23. The DPMI HOST used is CWSDPMI r5 and PMODE 1.3.
Problem description: assuming the program runs in pure protected mode, I want to measure the system's response time to hardware interrupts, because I hope this time can be <10 microseconds. In fact, this can be guaranteed under watcom c + dos4g/w. Interrupt signal source: signal generator, 4 KHz square wave. Connected to the machine's IRQ7. Test program: pure protected mode, using _go32_dpmi_allocate_iret_wrapper(), _go32_dpmi_set_protected_mode_inerrupt_vector() to set the ISR in protected mode. The ISR is very simple: it only writes 1 to the parallel port when entering the ISR, and writes 0 when leaving, with only one COUNTER++ in between. In the main program, all maskable interrupts except IRQ7 (IRQ0~IRQ15) are masked off, leaving only an infinite loop: for (; {}. Also, when the dpmi host is cwsdpmi, virtual memory was disabled through cwsparam.exe.Measurement: both the interrupt signal source and the output signal from the parallel port are connected to a logic analyzer to measure the time difference. This kind of test was done under watcom c + dos4g/w. After running all night, the maximum time difference was around 10 microseconds. But when testing under djgpp + cwsdpmi or pmode, for the vast majority of the time the time difference is <6 microseconds, but sometimes it suddenly increases to 20, 30, or even 60~80 microseconds! My test program today ran for about 7 hours, and there was one 20-microsecond case and one 80-microsecond case! This kind of situation is unsatisfactory in any setting with even slightly demanding real-time requirements. I don't know where the problem could be. If there is one, could it probably be a problem with the dpmi host? Has anyone done a similar experiment? And what were the results? I posted to ask on the comp.os.msdos.djgpp newsgroup, but no one has replied to me yet. ![]() |
|
|
[ Contact the Union admin team -
中国DOS联盟 -
Standard version ] Sponsored by ifanr Inc | © 2001–2023 |