Is it possible to ignore interrupts?
Peter Carleson
Hello,
I have a small real-time program in MS C 5.1 (MS-DOS 3.3, 80386/387
16MHZ) with a medium sized problem. The timing loop is seventy
microseconds (done through my own count-down loop and timed with an
o-scope) at which time a new value is sent to a bus digital-to-analog
converter. From the results of the program, it appears the deadline is
not always met.
It is the boss-mans opinion that this is caused by some internal
interrupts that the processor is servicing.
The entire program and data are contained in memory, and as far as I
know, once the program is running it requires no servicing of
interrupts.
Is this a reasonable opinion? If so, is it possible to "turn off" or
ignore interrupts? No one I have asked yet seems to know....
I am willing to have to cycle the power to quit the program, if that
is what it is going to take.
Pete Carleson
carl...@apee.ogi.edu
Dave Mc Mahan
In a previous article, carl...@apee.ogi.edu (Peter Carleson) writes:
>
>Hello,
>
>I have a small real-time program in MS C 5.1 (MS-DOS 3.3, 80386/387
>16MHZ) with a medium sized problem. The timing loop is seventy
>microseconds (done through my own count-down loop and timed with an
>o-scope) at which time a new value is sent to a bus digital-to-analog
>converter. From the results of the program, it appears the deadline is
>not always met.
>
>It is the boss-mans opinion that this is caused by some internal
>interrupts that the processor is servicing.
Sounds like he might be right. There is a real-time clock interrupt on the
PC that will hit you about every 18 milliseconds or so, if you haven't messed
with the programming of the clock chip.
>The entire program and data are contained in memory, and as far as I
>know, once the program is running it requires no servicing of
>interrupts.
>
>Is this a reasonable opinion? If so, is it possible to "turn off" or
>ignore interrupts? No one I have asked yet seems to know....
Sure! When you write the program, you are in control. Just don't expect
things to happen if you make DOS calls to do certain things. When you
disable interrupts for extended periods of time, you loose things like
clock interrupts that maintain your PC clock for you (the batter backed up
version in CMOS RAM continues to run, however, and can be accessed if you
need to know the time. It also restores proper time when you reboot).
You also may loose things like the ability to write to floppy and hard
disks, since these may work on interrupts too. (I'm not sure about RAM
disks, but they might be affected too. I doubt it, though)
To turn off interrupts, I think all you have to do is make a call to
_disable(). This is supported in MS 'C' 6.0 and up, and I'll bet it is
also available in some form under version 5.x. A similiar call to _enable()
will turn interrupts back on and give you the ability to write to disk again.
What I suggest is the following classic solution:
main()
{
do_normal_stuff_until_critical_time_part_starts();
_disable();
do_cricical_section();
_enable();
do_the_rest_of_your_task();
}
If there are gaps between data gathering that you know can safely handle
an interrupt happening, it's a good idea for you to just quickly _enable()
and then _disable() again. That way, any pending interrupts get served and
you may not loose things like time-of-day. I would _always_ _enable()
interrupts before trying to get something from the keyboard, too. I think
a _disable() may also inhibit any future keystroke input until you have
again _enable() the code.
>I am willing to have to cycle the power to quit the program, if that
>is what it is going to take.
This shouldn't really be necessary.
>Pete Carleson
>carl...@apee.ogi.edu
-dave
--
Dave McMahan mcm...@netcom.com
{apple,amdahl,claris}!netcom!mcmahan
Mark Addinall
In <1991Nov14.0330...@netcom.COM> mcm...@netcom.COM (Dave Mc Mahan) writes:
> In a previous article, carl...@apee.ogi.edu (Peter Carleson) writes:
>>
>>Hello,
>>
>>I have a small real-time program in MS C 5.1 (MS-DOS 3.3, 80386/387
>>16MHZ) with a medium sized problem. The timing loop is seventy
[good stuff deleted for brevity]
>Sounds like he might be right. There is a real-time clock interrupt on the
>PC that will hit you about every 18 milliseconds or so, if you haven't messed
>with the programming of the clock chip.
>>Is this a reasonable opinion? If so, is it possible to "turn off" or
>>ignore interrupts? No one I have asked yet seems to know....
boy, are you hanging out with the wrong crowd.... ;-)
>Sure! When you write the program, you are in control. Just don't expect
>things to happen if you make DOS calls to do certain things. When you
>main()
>{
> do_normal_stuff_until_critical_time_part_starts();
> _disable();
> do_cricical_section();
> _enable();
> do_the_rest_of_your_task();
>}
Good enough solution for a _high_ level language ;-)
>If there are gaps between data gathering that you know can safely handle
>an interrupt happening, it's a good idea for you to just quickly _enable()
>and then _disable() again. That way, any pending interrupts get served and
[good advice deleted]
>>I am willing to have to cycle the power to quit the program, if that
>>is what it is going to take.
>This shouldn't really be necessary.
I'll say.
>>Pete Carleson
>>carl...@apee.ogi.edu
> -dave
>--
>Dave McMahan mcm...@netcom.com
> {apple,amdahl,claris}!netcom!mcmahan
erm...
let an old man have a go..
;; this would contain important stuff that does things
;; fast approaching critical <something>
;; nearly..
;; soooooo close
CLI ;; shut down interrupts !!!
;; do this stuff reeeaaallllyyyy fast
;; so we don't have a blind, dumb,
;; deaf machine for too long
STI ;; back on !! -Hello world-
;; we now carry on with more mundane programming tasks
;; ho hum
CLI - Clear Interrupt Flag
+-----------------+
|O|D|I|T|S|Z|A|P|C|
+-----------------+
| | |0| | | | | | |
+-----------------+
Have fun :-)
Mark....
------------------------------------------------------------------------------
Mark Addinall | NEWSFLASH: We interrupt show jumping at the ABC to
Software manager | bring you a newsflash. The Second World War has now
Stallion Technologies | entered a sentimental stage. This morning on the
Brisbane, QLD, Australia.| Ardennes Front, the Germans started spooning at
TEL 61 7 870 4999 | dawn, but the British Fifth Army responded by
FAX 61 7 371 8881 | gazing deep in their eyes, and the Germans are
...!uunet!mark@staltec | reported to have gone 'all coy'......
ma...@stallion.oz |----------------------------------------------------
mobile. 018 880 713 | { unlike onions, opinions are mine alone...}
-------------------------------------------------------------------------------
Duncan Murdoch
> In a previous article, carl...@apee.ogi.edu (Peter Carleson) writes:
>
>>The entire program and data are contained in memory, and as far as I
>>know, once the program is running it requires no servicing of
>>interrupts.
>>
>>Is this a reasonable opinion? If so, is it possible to "turn off" or
>>ignore interrupts? No one I have asked yet seems to know....
>
>Sure! When you write the program, you are in control. Just don't expect
>things to happen if you make DOS calls to do certain things. When you
>disable interrupts for extended periods of time, you loose things like
>clock interrupts that maintain your PC clock for you (the batter backed up
>version in CMOS RAM continues to run, however, and can be accessed if you
>need to know the time. It also restores proper time when you reboot).
>You also may loose things like the ability to write to floppy and hard
>disks, since these may work on interrupts too. (I'm not sure about RAM
>disks, but they might be affected too. I doubt it, though)
I have a vague memory from somewhere or other that the RAM refresh is
handled or triggered by the BIOS on timer ticks. If that's true, disabling
interrupts for more than a second or two would be fatal. Do you know
if it is?
Duncan Murdoch
Erik F. Andersen
Duncan Murdoch
If I remember correctly, _disable() only disables MASKABLE interrupts.
The RAM refresh request is a NONMASKABLE interrupt (IRQ 0). However It is
possible to slow down the rate of RAM refresh calls, and thus
making memory access faster!
Erik F. Andersen, Denmark
E-mail : e...@iesd.auc.dk
Duncan Murdoch
>
>In article <1991Nov14....@cunews.carleton.ca> dmur...@sol.carleton.ca (Duncan Murdoch) writes:
> I have a vague memory from somewhere or other that the RAM refresh is
> handled or triggered by the BIOS on timer ticks. If that's true, disabling
> interrupts for more than a second or two would be fatal. Do you know
> if it is?
>
>The RAM refresh request is a NONMASKABLE interrupt (IRQ 0). However It is
>possible to slow down the rate of RAM refresh calls, and thus
>making memory access faster!
You may be right. Last night I wrote a program on my old XT clone which
left interrupts disabled (using CLI) for a full minute and survived. It did
suggest some problems, though: when I tried to stop the program with Ctrl-Break
(stupid me, it wasn't listening), at the end of the minute when interrupts
were turned back on I got an "Internal Stack Failure" crash.
Duncan Murdoch
Rich M Moore
[original stuff deleted]
This comment may fall into the annoying category of "are you sure the
power cord is in the wall?", but do you have any 'terminate and stay
resident' (TSR) programs that are fired up in your autoexec.bat?
My understanding of the DOS 'timer tick' interrupt is that it points
to a dummy interrupt service routine (just a return) by default.
This shouldn't cause too much problems by itself unless some other program
is using that interrupt for its own purposes - many TSR's use this
periodic interrupt.
If you do have any, get rid of them and see what happens. If
your machine is running plain vanilla, then the suggestions of
turning off interrupts may be necessary (or get a cheap 286 upgrade board)
Rich
Robin Iddon
> Original thread deleted for brevity
I have a vague memory from somewhere or other that the RAM refresh is
handled or triggered by the BIOS on timer ticks. If that's true, disabling
interrupts for more than a second or two would be fatal. Do you know
if it is?
Luckily the PC isn't *THAT* bad - RAM refresh are handled totally by hardware
so no amount of software can break it (well almost :-). You are right in
thinking that refresh is handled by one of the timer channels (on some PC's at
least), but it doesn't cause an interrupt, so is unaffected by sti/cli. On
later PC's all this stuff is probably invisible behind a chip set bus
interface unit.
Duncan Murdoch
--
Robin Iddon (rob...@spider.co.uk)
Spider Systems Ltd
Edinburgh
Scotland
Arik Anderson
>If I remember correctly, _disable() only disables MASKABLE interrupts.
>The RAM refresh request is a NONMASKABLE interrupt (IRQ 0). However It is
>possible to slow down the rate of RAM refresh calls, and thus
>making memory access faster!
Ok, I didn't grab my BIOS Tech Ref, but I've designed enough DRAM systems
to believe that you wouldn't involve the processor in the DRAM refresh
request system at all. Normally, there is some sort of independent timer
that grabs the next free memory cycle and refreshs a row of DRAM. To the
processor in merely takes a little longer for the DRAM to respond this time.
Maybe the processor would need to be interrupted (such as a bus request DMA
cycle) on an Async bus, but the IX86 bus is a Syncronized bus.
--
____________________________________________
/\ /\ < Arik A. Anderson >
/__\/__\ < INTERNET: ar...@cserver.plexus.com >
/ /\ \ < UUCP: marque!cserver!arika >
Andrew Eckhardt
>e...@iesd.auc.dk (Erik F. Andersen) writes:
>
>
>>If I remember correctly, _disable() only disables MASKABLE interrupts.
>>The RAM refresh request is a NONMASKABLE interrupt (IRQ 0). However It is
>>possible to slow down the rate of RAM refresh calls, and thus
>>making memory access faster!
>
>Ok, I didn't grab my BIOS Tech Ref, but I've designed enough DRAM systems
>to believe that you wouldn't involve the processor in the DRAM refresh
>request system at all. Normally, there is some sort of independent timer
>that grabs the next free memory cycle and refreshs a row of DRAM. To the
>processor in merely takes a little longer for the DRAM to respond this time.
>
>Maybe the processor would need to be interrupted (such as a bus request DMA
>cycle) on an Async bus, but the IX86 bus is a Syncronized bus.
1. Refresh does NOT generate an interrupt. It is transparent
to the processor in PC's.
2. IRQ0 <int 8> is QUITE maskable. This is the system timer interrupt.
3. NMI in PC's is only generated on a prity error.
Now, when NMI occurs, atleast on the 8086 / 8088
it can interrupt between a prefix and an opcode -
not a restartable condition.
You don't need to mask it.
Duncan Murdoch
>
>3. NMI in PC's is only generated on a prity error.
> Now, when NMI occurs, atleast on the 8086 / 8088
> it can interrupt between a prefix and an opcode -
> not a restartable condition.
This is one where my memory is less vague. On PCs and XTs (but not ATs or
later), the NMI is also used by the 8087 coprocessor to signal errors. It
can be disabled because it's not wired directly to the 8088/8086 - it
goes through an interrupt controller. This causes a lot of crashes with
new software on old machines - on many (most?) XTs and clones, NMI is
disabled by the boot code, and has to be enabled explicitly by any program
that might cause coprocessor errors. Lots don't, especially those written
in Borland languages.
Duncan Murdoch
Michael K. Johnson
I have a vague memory from somewhere or other that the RAM refresh is
handled or triggered by the BIOS on timer ticks. If that's true, disabling
interrupts for more than a second or two would be fatal. Do you know
if it is?
Duncan Murdoch writes:
>I have a vague memory from somewhere or other that the RAM refresh is
>handled or triggered by the BIOS on timer ticks. If that's true, disabling
>interrupts for more than a second or two would be fatal. Do you know
>if it is?
Actually, ram refresh is handled by hardware below the chip level, I
believe. There is a chip which you *can* reprogram to change the
refresh rate, but it cannot be driven by the clock, because while the
clock ticks about 18 times per second, RAM is refreshed something on
the order of 1000 times per second. If anyone wants to see assembly
that deals with reprogramming the refresh rate, I think I have it
somewhere (it is also somewhere on the net, but I can't remember
what it is called) and could get it to you, even though it is
kind of off the topic of whether a STI instruction will prevent ram
refresh.
Hope this helps!
michaelkjohnson
john...@stolaf.edu
I don't do .sig's
Frank Budzelaar
sorry to see that the information value of this line of messages begins to drop
rapidly.
1) the things discussed are perfectly described in various books. Let's keep
this group for special problems people have to deal with, such as the
original question..
2) if you are not sure, look it up before you start to fill the world with
plain wrong information.
refresh is handled by the hardware, and has nothing to do with interrupts.
lowering the refresh rate (normally about every 15 us) reduces the required
bandwidth a bit
so that the processor has more bandwidth available. disabling interrupts has NO
impact on refresh, but there various reasons not to disable them too long
(such as keyboard input, timer interrupts etc).
(sorry if I seem a bit sour. I hate nonsense!)
Greetings,
frank budzelaar
/----/----\
/ / /
----/----/----/------
/ / \
/ /-----/
Disclaimer:
Of course my opinions are my own.
------------------------------------------------------------------------
Frank Budzelaar "My other computer is a 486"
Eindhoven University of Technology seen on an XT
email: bu...@eb.ele.tue.nl
-----------------------------------------------------------------------
thomas.j.roberts
1) On all IBM-PC compatibles I have seen, DRAM is NOT refreshed by any
kind of interrupt. It is refreshed by DMA reads initiated by timer 1
(timer 0 is the timer interrupt IRQ 0, timer 2 drives a tone to the
speaker). Thus, you can disable interrupts forever, and DRAM will
still be refreshed.
2) The timer interrupt (IRQ 0, gets mapped to INT 8) is initialized to
an important routine in the BIOS. This routine maintains the current
time-of-day clock, turns off floppy-disk motors after use, etc.
It is VERY bad form to disable this routine.... (note that on
most PCs with a CMOS real-time-clock, the DOS get-time call really
uses the value from the timer, NOT the value from the CMOS clock; the
CMOS clock is read only at boot time to set the timer-based clock).
Note that the IBM PC and compatibles initialize the timer
interval to its maximum value, so the interrupts are as slow
as possible, 18.2 Hz. If you write a program which speeds
up the timer interrupt, you must continue calling the
original interrupt at the proper rate. I have successfully
run the timer interrupt at 500 Hz (on an 8 Mhz 8086 -
an AT&T PC6300).
3) The keyboard also runs on interrupts - if you disable interrupts
forever, you will never see any more keypresses. This makes it very
difficult to abort an errant program (even CTL-ALT-DEL won't reboot).
In short:
IT IS VERY BAD DESIGN PRACTICE TO DISABLE INTERRUPTS ON A PC!!!!!
Good hardware designers have known this for years. This usually means
that DAC/ADC boards need FIFOs on-board, with a depth sufficient to
permit them to hold 1-2 millisec of data. The usual guideline is that
interrupts should be off for no longer than 1 millisec (this also
applies to the execution of an interrupt handler at interrupt level).
I have a music system which sometimes takes 100 millisec to completely
handle an interrupt - it re-enables interrupts within .2 millisec, and
ensures that its long part is not re-entered. This drastically slows
down the baseline (non-interrupt) program, but keeps the PC operating.
Tom Roberts
att!ihlpl!tjrob TJ...@IHLPL.ATT.COM
Louis Lamarche
|> When you
|> disable interrupts for extended periods of time, you loose things like
|> clock interrupts that maintain your PC clock for you
If you disable the timer interrupt you will also loose your mouse.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Louis Lamarche, IREQ | lama...@ireq.hydro.qc.ca
| CP 1000, Varennes | or
| QC, Canada, J3X 1S1 | 514-652-8077 (office) 514-324-2919 (home)
Marty Del Vecchio
What? Turn off interrupts? You mean with the CLI instruction? If you do this
at the start of an application program, then the keyboard won't work, the
timer won't work, serial ports won't work, network cards won't work, etc.
If you are an application program, you just "ignore" interrupts. If you are
a TSR or a driver, you probably have to deal with an interrupt or two.
I guess I don't get what you are trying to accomplish by disabling interrupts.
--
================================
Marty Del Vecchio
Software Engineer
Shiva Corporation
Ed Nather
> So much wrong information/speculation, I had to jump in.
I second the motion.
[reliable & correct information deleted]
> Note that the IBM PC and compatibles initialize the timer
> interval to its maximum value, so the interrupts are as slow
> as possible, 18.2 Hz.
To expand this a bit, the timer counts down the PCs master clock by
stuffing 0 into a 16 bit counter, and counting it down to 0 again
(65536 clock ticks). That counter is accessible so you can put in some
other value and get interrupts faster, if you want.
> If you write a program which speeds
> up the timer interrupt, you must continue calling the
> original interrupt at the proper rate. I have successfully
> run the timer interrupt at 500 Hz (on an 8 Mhz 8086 -
> an AT&T PC6300).
I wrote a data acquisition program with a timing interrupt of 1 ms
(1 KHz rate) that runs fine on an IBM PC (8088, 4.77 MHz) but had to
be pretty efficient in the interupt routine to leave time for other
things. By measurement, 12.5% of the CPU time is spent in servicing
this timing interrrupt, rather less on faster machines. You stuff
the integer 1193 into the countdown to go this fast. I pinched most
of the code from the book "Supercharging C with Assembly Language"
by Chesley & Waite, Addison Wesley 1987, who explain in detail how
to call the regular interrupts at the proper interval to keep the
system working.
> In short:
>
> IT IS VERY BAD DESIGN PRACTICE TO DISABLE INTERRUPTS ON A PC!!!!!
For very long, at least.
Erik F. Andersen
Yup, I guess it's not only silicon chips that needs constant
refreshing!
Here's what I found in "Programmer's Problem Solver for the IBM PC,
XT, & AT" by Robert Jourdain: Channel 1 of the 8253/8254 timer
chip "controls memory refresh on all machines but the PCjr...
The out line of the channel is connected to the direct memory
access chip, and a pulse causes the DMA chip to refresh all of
RAM...Channel 1 is used to count the intervening pulses of
the time-of-day clock, so that the count can be updated after
disk operations are complete."
Ralf....@b.gp.cs.cmu.edu
}I have a vague memory from somewhere or other that the RAM refresh is
}handled or triggered by the BIOS on timer ticks. If that's true, disabling
}interrupts for more than a second or two would be fatal. Do you know
}if it is?
No it isn't, though I can understand your confusion. The timer chip has
three separate timers; one is hooked to the DMA controller to trigger the
refresh cycles, one is hooked to the interrupt controller to form the clock
tick, and one is hooked to the speaker to produce sound.
--
{backbone}!cs.cmu.edu!ralf ARPA: RA...@CS.CMU.EDU FIDO: Ralf Brown 1:129/26.1
BITnet: RALF%CS.CMU.EDU@CARNEGIE AT&Tnet: (412)268-3053 (school) FAX: ask
DISCLAIMER? Did | "Secrecy is the beginning of tyranny."
I claim something?| -- from the Notebook of Lazarus Long
Ralf Brown
Release 28 of the MSDOS interrupt list is now available. It can be retrieved
via anonymous FTP from CS.CMU.EDU [128.2.222.173] in /afs/cs/user/ralf/pub
(change there with a *single* command) as inter28[abc].zip. It will also
be available from SIMTEL20 in PD1:<MSDOS.INFO> shortly.
Ralf Brown
Announcing the release of SPAWNO v4.0. This replacement for the Turbo C
and MS C spawn..() functions will swap out your program to disk, EMS, XMS,
or raw extended memory, leaving less than 300 bytes in memory while
executing another program. This release now includes a version for
Turbo Pascal.
It is now available for anonymous FTP from CS.CMU.EDU [128.2.222.173] in
/afs/cs/user/ralf/pub (change there with a *single* command) as spawno40.zip.
It will also be available from SIMTEL20 in PD1:<MSDOS.C> shortly.
Ralf Brown
}Release 28 of the MSDOS interrupt list is now available. It can be retrieved
}via anonymous FTP from CS.CMU.EDU [128.2.222.173] in /afs/cs/user/ralf/pub
}(change there with a *single* command) as inter28[abc].zip. It will also
}be available from SIMTEL20 in PD1:<MSDOS.INFO> shortly.
Anybody who retreived INTER28C.ZIP from CS.CMU.EDU before 23:00GMT 17Nov91
should get it again, because my initial upload was corrupted. The correct
file is 135096 bytes in length.
It seems that the version of 'rz' I have will happily append to a partial
file when attempting to use '-r' crash recovery without telling the
sender to start sending other than at the beginning of the file....
Alexander Vrchoticky
>If you disable the timer interrupt you will also loose your mouse.
well, you might be able to catch another one,
you know, cheese and all that. :-)
incidentally, this has strayed rather far from realtime issues,
followups are therefore redirected to comp.os.msdos.programmer only.
this should also help restore the comatose state in comp.realtime that
we all know and love.
[sigh]
-alex
--
Alexander Vrchoticky al...@vmars.tuwien.ac.at
TU Vienna, CS/Real-Time Systems +43/222/58801-8168
"die majestaetische ruhe des anorganischen" (max goldt)