From owner-freebsd-hackers Sun Oct 5 12:23:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05156 for hackers-outgoing; Sun, 5 Oct 1997 12:23:39 -0700 (PDT) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05151 for ; Sun, 5 Oct 1997 12:23:36 -0700 (PDT) Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy4.ba.best.com (8.8.7/8.8.BEST) with ESMTP id MAA14708; Sun, 5 Oct 1997 12:21:39 -0700 (PDT) Received: from localhost (mdean@localhost) by shellx.best.com (8.8.6/8.8.3) with SMTP id MAA27987; Sun, 5 Oct 1997 12:21:38 -0700 (PDT) Date: Sun, 5 Oct 1997 12:21:38 -0700 (PDT) From: mdean To: Mike Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: A world of unexplored pain. In-Reply-To: <199710050846.SAA00411@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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?