[3967] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: Linux and Realtime

daemon@ATHENA.MIT.EDU (Kevin M Bealer)
Wed Aug 7 08:30:32 1996

Date: 	Wed, 7 Aug 1996 00:32:11 -0400 (EDT)
From: Kevin M Bealer <kmb203@psu.edu>
To: Bernhard Deny <bh48@ph70.rz.uni-karlsruhe.de>
cc: linux-net@vger.rutgers.edu
In-Reply-To: <3207CFC0.1FFF@ph70.physik.uni-karlsruhe.de>

On Tue, 6 Aug 1996, Bernhard Deny wrote:

> Hallo everybody,
> 
> i am looking for an operating system to do some data acquisition and 
> graphical visualisation. The data (approx. 100 Bytes) should be collected, 
> calculated and stored via two serial ports every 10 seconds, no data 
> should be missing.
> A third port should receive 30 bytes every second. The visualisation 
> should not affect the data sampling (an uncertainity of about 0.5-1 second 
> is tolerable). I think an expensive realtime operating system is overkill 
> for this.
> 
> Do you think Linux is a good choice for such an application ? Does Linux 
> have functions for timing and interrupt-driven serial communication ?

I think Linux could probably do this with no problem.  I have no
personal experience with serial port programming (or real time data
collection for that matter, (except via Apple II ;) ).

If you have linux already, look at /usr/src/linux/Documentation/rtc.

This is documentation for the real-time-clock, which is a way to
time data sampling. (Below is an excerpt).

[ Note that the author is concerned about > 1024 polls per
second on a 486-33. ]

Another thing you may look for is a package called "grafix" on a
sunsite mirror.

This comes with a number of demos, and seems fairly well suited
for this sort of thing if you go via XWindows.  It seems quite
small and efficient, and is GPL'd.

The top of the readme:

Grafix  Ver. 1.2                1995, Oct 30.
==============================================
1. What is "Grafix" ?

"Grafix" is a utility originally designed to help scientists in
the visualization of results of a computation, esp. for
numerical integrations of partial differential equations.
 

------------------

	Real Time Clock Driver for Linux
	================================

(clip)
The interrupts are reported via /dev/rtc (major 10, minor 135, read only
character device) in the form of an unsigned long. The low byte contains
the type of interrupt (update-done, alarm-rang, or periodic) that was
raised, and the remaining bytes contain the number of interrupts since
the last read.  Status information is reported through the pseudo-file
/proc/rtc if the /proc filesystem was enabled. The driver has built in
locking so that only one process is allowed to have the /dev/rtc
interface open at a time.

A user process can monitor these interrupts by doing a read(2) or a
select(2) on /dev/rtc -- either will block/stop the user process until
the next interrupt is received. This is useful for things like
reasonably high frequency data acquisition where one doesn't want to
burn up 100% CPU by polling gettimeofday etc. etc.

At high frequencies, or under high loads, the user process should check
the number of interrupts received since the last read to determine if
there has been any interrupt "pileup" so to speak. Just for reference, a
typical 486-33 running a tight read loop on /dev/rtc will start to suffer
occasional interrupt pileup (i.e. > 1 IRQ event since last read) for
frequencies above 1024Hz. So you really should check the high bytes
of the value you read, especially at frequencies above that of the
normal timer interrupt, which is 100Hz.

-------------------- 8< ---------------- 8< -----------------------------

/*
 *	Real Time Clock Driver Test/Example Program
(clip)


__kmb203@psu.edu_______________Debian/GNU__1.1___Linux__2.0.11___
        To A Quick Young Fox:
Why jog exquisite bulk, fond crazy vamp,
Daft buxom jonquil, zephyr's gawky vice?
Guy fed by work, quiz Jove's xanthic lamp --
Zow!  Qualms by deja vu gyp fox-kin thrice.
                -- Lazy Dog



home help back first fref pref prev next nref lref last post