Date: Thu, 14 May 1998 14:38:39 +0300 (IDT) From: Eli Zaretskii To: Javier Calleja cc: djgpp AT delorie DOT com Subject: Re: Interrupt, interrupt,... why am I using DOS? In-Reply-To: <01bd7f16$08ce7c80$0100a8c0@dismuntel.ctv.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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).