apfiffer@admin.ogi.edu (Andy Pfiffer) (02/01/91)
I'd like to be able to program and poll one of the timers on the 8254 Programmable Interval Timer under a vanilla System V/386 R3.2. I have no difficulty accessing the ports, but I'm not certain how UNIX uses them. There are three 1.19 MHz timers on the chip. My guesses: Timer Function 0 100Hz clock interrupt 1 DRAM refresh (about 66 KHz) 2 beep & buzz Are these correct? Thanks. -- Andy Pfiffer (503) 645-1886 apfiffer@admin.ogi.edu Formerly w/ Cogent Research, Formerly w/ Topologix, Formerly w/ Theory Center. "To determine where to resume execution upon leaving the trap handler, examine the instruction at address fir - 4.
rcd@ico.isc.com (Dick Dunn) (02/02/91)
apfiffer@admin.ogi.edu (Andy Pfiffer) writes: > I'd like to be able to program and poll one of the timers on the 8254 > Programmable Interval Timer under a vanilla System V/386 R3.2. I have > no difficulty accessing the ports, but I'm not certain how UNIX uses them. There really isn't a timer you can use without screwing things up. For two of them, it's not so much how UNIX uses them as how the hardware uses them. > There are three 1.19 MHz timers on the chip... Yeah...there's actually one crystal-controlled oscillator driving all three CLK inputs on the 8254. The frequency is 1.193182 MHz. (Some AT tech refs are imprecise on this; it does matter for how you program it if you want an accurate clock.) >...My guesses:... > 0 100Hz clock interrupt > 1 DRAM refresh (about 66 KHz) > 2 beep & buzz > Are these correct? Yes. Note that timer 1 is set up for the 15 us cycle and wired on the motherboard to drive refresh...so although you probably can reprogram it (tho I've never done it--at least not that I know of:-), you're asking for trouble. In the same vein, timer 2 is wired to the speaker driver, so if you fiddle with it, you'll make funny noises--and if something decides it needs to honk at the user, the kernel will reprogram the timer out from under you. There's no hardware magic to timer 0 other than wiring CLK OUT 0 to IRQ0. But you're right that UNIX uses it for the system clock, so if you go reprogramming it, you're going to time-warp your system. Even if you don't mind your clock running funny, there are other dangers in repro- gramming it: If you turn it off, kernel timeouts won't happen and you'll probably hang the system in short order. If you crank it way up, clock interrupts will happen too fast and, I'd guess, you'll spend all your time in the kernel trying to handle them; you might manage to panic it. It's unfortunate that there isn't a free timer for other uses. It would be very useful for both system and application tasks. It would be nice if there were a simple I/O card with a programmable timer or two...couldn't take more than a few chips. Does anyone know if such an animal exists? -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
vjs@calcite.UUCP (Vernon Schryver) (02/03/91)
In article <1991Feb1.202411.9033@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > ... > It's unfortunate that there isn't a free timer for other uses. It would be > very useful for both system and application tasks. It would be nice if > there were a simple I/O card with a programmable timer or two...couldn't > take more than a few chips. ... It would be far better to build something like the 4.*BSD itimers, or just use select(2), even if you had to get to them thru a library that diddled a cdev[] driver. (Think of the old Excelan TCP code). It's often said that the only purpose of the kernel is to mediate among requests for resources. A mechanism to allow an varying number of processes to use varying numbers of what each process thinks are private, accurate, low overhead timers is not trivial. It's easy to blow several percent of a CPU on watching timers, even when they are not in use. Timers might be slightly easier to implement well given a hardware clock independent of any of the 3 clocks in the SV (lbolt, timeout(), and time), but I doubt it. Consider that those 3 kernel clocks are often based on a single hardware interrupt at HZ/sec. Imagine a trivial cdev[] driver that did little more than call timeout() in response to an IOCTL. It could have a hash table keyed on PID or file table pointer, containing the ID obtained from timeout() to allow cancelling timers in response to another IOCTL. It would send the requesting process a specified signal when the timeout expired, or simple wakeup and return from an IOCTL. Such a driver would take someone like D.Dunn at most a day to implement, debug, and document. A quick grep thru a copy of the SVR4 os/*.c showed me no signs of itimers. I don't see how you could have decent BSD compatibility without them, but they didn't call it SV without reason. (Yes, the original article was about SVR3.2.) Vernon Schryver, vjs@calcite.uucp
mburg@unix386.Convergent.COM (Mike Burg) (02/05/91)
In article <107@calcite.UUCP>, vjs@calcite.UUCP (Vernon Schryver) writes: [Discussion about timer driver implementation deleted] > A quick grep thru a copy of the SVR4 os/*.c showed me no signs of itimers. > I don't see how you could have decent BSD compatibility without them, but > they didn't call it SV without reason. (Yes, the original article was > about SVR3.2.) > Vernon Schryver, vjs@calcite.uucp Try looking at uts/i386/io/hrtimers.c, lib/libc/port/gen/getsetitimer.c, and lib/libc/port/sys/hrtsys.c. The library routines convert the BSD style of itimer into the a format use by the HRTSYS system call. -- ---------------------------------- Michael Burg - Unisys/Convergent Corp. Unix Intel Platforms Division San Jose Phone: (408) 456-5934 UUCP: uunet!pyramid!ctnews!unix386.Convergent.com!mburg
tmh@bigfoot.FOKUS.GMD.DBP.DE (Thomas Hoberg) (02/12/91)
In article <1991Feb1.202411.9033@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: |> apfiffer@admin.ogi.edu (Andy Pfiffer) writes: |> > I'd like to be able to program and poll one of the timers on the 8254 |> > Programmable Interval Timer under a vanilla System V/386 R3.2. I have |> > no difficulty accessing the ports, but I'm not certain how UNIX uses them. |> |> There really isn't a timer you can use without screwing things up. For two |> of them, it's not so much how UNIX uses them as how the hardware uses |> them. |> |> > There are three 1.19 MHz timers on the chip... |> |> Yeah...there's actually one crystal-controlled oscillator driving all three |> CLK inputs on the 8254. The frequency is 1.193182 MHz. (Some AT tech refs |> are imprecise on this; it does matter for how you program it if you want an |> accurate clock.) |> |> >...My guesses:... |> > 0 100Hz clock interrupt |> > 1 DRAM refresh (about 66 KHz) |> > 2 beep & buzz |> > Are these correct? |> [...] |> |> It's unfortunate that there isn't a free timer for other uses. It would be |> very useful for both system and application tasks. It would be nice if |> there were a simple I/O card with a programmable timer or two...couldn't |> take more than a few chips. Does anyone know if such an animal exists? |> -- |> Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 |> ...Mr. Natural says, "Use the right tool for the job." I might be all wrong and I have the appropriate manuals at home, but.... I believe the CMOS clock uses an extra IRQ line and can be programmed for alarms as well as periodic interrupts. I don't know what the resolution is and I'm quite sure since it uses interrupts, you'd have to write a driver for it, but if all you need is *one* timer, and if the resolution it provides is good enough... :-> tom ---- Thomas M. Hoberg | UUCP: tmh@bigfoot.first.gmd.de or tmh%gmdtub@tub.UUCP c/o GMD Berlin | ...!unido!tub!gmdtub!tmh (Europe) or D-1000 Berlin 12 | ...!unido!tub!tmh Hardenbergplatz 2 | ...!pyramid!tub!tmh (World) Germany | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET