Mail Archives: djgpp/1998/05/14/07:39:06
On Thu, 14 May 1998, Javier Calleja wrote:
> Hello all the world (specially people are going to answer my questions):
Hello to you, too, but please in the future try to avoid posting messages
with HTML tags in them, they make it hard to read the text. It's
probably some option in your mail client which needs to be changed.
> When I write this interrupt handler in C and I use the go32_ funcions
> (like go32_dpmi_set_protected_mode_interrupt_vector and similar) to
> place it and I use farpoke and farpeek , does the program change to
> real mode or it always work in protected mode?
Your code always runs in protected mode. GCC cannot generate real-mode
code. The farptr functions don't switch to real mode either, they just
access conventional memory from protected mode.
> And, what lattency can this handler work safely?
If the interrupt arrives while the CPU is in protected mode, you only see
the latency of interrupt handling by the DPMI server and the underlying
OS (this might be substantial for Windows).
If the interrupt arrives when the CPU is in real mode, you will have an
additional penalty of mode switch to protected mode. Conventional wisdom
holds it, though, that you should be able to serve up to 10,000 interrupts
per second without any significant slow-down, unless your CPU is 486/33
or less. See section 18.9 of the DJGPP FAQ list for more details.
> If I'm =
> inside a hardware interrupt handler (like my CAN interrupt handler), can =
> a software interrupt be activate and break the working of my CAN =
> handler?
Software interrupts cannot be asynchronous events. So they cannot
interrupt any code that is running, unless they are issued from another
hardware interrupt which has higher priority (in which case your handler
is actually interrupted by that hardware interrupt handler, not by a
software interrupt).
- Raw text -