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.
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.