Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Oct 1997 12:21:38 -0700 (PDT)
From:      mdean <mdean@best.com>
To:        Mike Smith <mike@smith.net.au>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: A world of unexplored pain. 
Message-ID:  <Pine.SGI.3.95.971005115758.2752B-100000@shellx.best.com>
In-Reply-To: <199710050846.SAA00411@word.smith.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help

> > the real question for me is: If I use acquire_timer0(1000, myintr) what
> > kind of jitter should I expect in delivery of those interrupts, i.e how far
> > off center will myintr() get called from the every 1/1000 of a second mark?
> 
> This depends on what other interrupt and clock-sensitive activity is 
> going on; several milliseconds is not an unreasonable figure.

Were not just talking about stepper motors here (It would be way easier for
me to use some dedicated controller board) if that was all I wanted.  I can
get a multi-axis serial master controller that will do 4 axis control and
is fully programmable designed to be used with the two-clock bipolar
microstepping drivers I am using. Price: $1500.  This is not the problem.
The problem is it doesn't do retargeting, and b) I have 100 12 bit analog
input connected through multiplexers/signal conditioners to the same
machine (A PC), and also 48 solid state relays that on this particular
machine switch 24 volts @ 3 Amperes each, and yes it is designed so that
all 48 can be switched on simultaneously (I had to have some custom
electrical rigs designed and built to carry these currents from a bank of
lead acid batteries that are continuosly charged). The 3.4 Kilowatt pulses
generally have about a 20% duty cycle. 

So the real question is realtime here, the machine that these are connected
to has all the interface cards needed for that above, a video card and
network card (complete with netboot eprom). It boots disklessly {as a
freebsd machine} from a tftp/bootp/nfs server.  I really thought that this
configuration would work out but apparently not. For instance I need to
generate pulses with the SSR that are reliably 37ms in length.  I cannot
really do this with freebsd in a clean way, which is quite dissapointing
because I really wanted to have the interface run under X.  Basically what
you are saying is that I should be using dos, or some other real time OS
(Any recommendations?). Of course they won't be able to run X or (probably)
boot over the network. But that's life.

All I need is a small C-Routine that can be guaranteed to get run once
every millisecond. It could handle everything above, and doesn't even need
to be a driver. Just a routine in kernel space as I understand. Or a
routine in user space sleeping on a select() that would get woken up once
every millisecond reliably. Can someone explain why this CANNOT be done.
Why a small routine placed in kernel space perhaps as an lkm, and only one
of then cannot take precedence over everything else. Where do these really
horrendously masked cli(), sti() routines exist that would prevent this?










Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SGI.3.95.971005115758.2752B-100000>