Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA1284 ; Tue, 23 Feb 93 14:33:53 EST
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!spool.mu.edu!wupost!csus.edu!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: [386BSD] device drivers & RTC (Real Time Clock)
Message-ID: <1993Feb14.005348.13989@netcom.com>
Keywords: 386bsd device driver RTC real time clock
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Sun, 14 Feb 1993 00:53:48 GMT
Lines: 64
-------------------------------------------
This should not be a resend, but I thinks I don't know.
-------------------------------------------
wjolitz@cardio.ucsf.edu
[386bsd]:NEED Real-Time-Clock working
386bsd is running on one leg, but at this time I have
neither the time (time, time, time, S^| ) nor the know-how to
fix the problem. The problem is that the CMOS RTC (Real Time
Clock) is not being utilized. At the present only the 8259 or
80255 interrupt timer chip are running the time loop, but with a
second clock running at a different frequency, a more effective
OS will result.
On the MS-DOS/IBM system Int 8 handles the timer tick,
mostly for foreground timing - like the keyboard buffer polling
done by MS-DOS. Int 8 runs at approx. 18 ticks per second. The
RTC - operates through Int 70h and primarily signals semaphores,
flag bits, and the TOD (Time of Day) counter. The semahpres &
flags inturn signal timeout and frequency operation polling.
Int 70h runs at about 1000 ticks per second.
What all this leads to is the need for a working RTC and
support_calls(). The routines I beleive that are needed include:
get_tick_count() /* get the current tick_count */
delay() /* simply wait a predetermined tick count */
event_wait() /* initiate a semaphored event wait
( or toggle a flag bit in a address)
*/
cancel_event_wait() /* cancel the event_wait request */
setup_alarm_routine() /* pass routine an address to
start a process in 24hrs plus
*/
set_alarm() /* set alarm 24+hrs. event */
reset_alarm() /* cancel alarm 24+hrs. event */
Except for setup_alarm_routine() and set_alarm() all calls
should have top priority on the event que. Resolution should be
1000 or 10,000 ticks per second.
Applications may use the event_wait() to check for user
response ot polling with the toggle flag. Low-level I/O can use
event_wait() for timeout procedure via the semaphore event. Cron
and network protocols can use the set_alarm().
To do this work one will need the "IBM: Technical
Reference Personal Computer AT", part# 6280070.
It may also be called "The Personal Computer Hardware Reference
Library".
DELAY() is a hideous method of programming. Sleep() is
another bizzare concoction. Both show the blind patches
programmers used to make on computers, becuase EE's had not
enough forethought to consider real problems in a multitasking
OS. If I had my way, I would have multipule counters on a CPU,
16 or 20, like microcontrollers have now, such as the 68hc11,
the 8052, and others.