Re: nervous about command timing

From: Bernd Porr <BerndPorr_at_f2s.com> · Date: Mon, 04 Oct 2004 20:30:09 +0100

Hi!

Looks OK.

Re the preemptive execution: it's always on if you've enabled it in the 
kernel. It just means that if a hardware process waits too long for the 
hardware it will be interrupted.

I don't know how fast the loop can run. Just try it out. I think that 
something up to 50kHz should work as long as you don't load the system 
too much. I've got a crappy ACER laptop which locks completely up during 
every hard disk access. So realtime works as long as I don't store a 
vast amount of data on the HD. If I sample into memory I have even at 
1MHz sampling rate only a minimal backlog.

/Bernd

www:	http://www.berndporr.me.uk/
         http://www.linux-usb-daq.co.uk/
Mobile:	+44 (0)7769 506746
Work:	+44 (0)141 330 5237
         University of Glasgow
         Department of Electronics & Electrical Engineering
         Room 519, Rankine Building, Oakfield Avenue,
         Glasgow, G12 8LT

Michael Thomas wrote:
> Sounds like a slick robot app!  But it might need some tweaking to fit my
> purpose.  First, I need almost 15kHz.  I was hoping it could get that fast
> because the data is handed off to other hardware for processing.  (How much
> processing is performed inside the loop that gets 1kHz?)
> Second, I need to programmatically know about each period to keep my I/O
> coordinated - hence the question about interrupts.  Would this template keep
> my inputs and outputs interleaved 1-to-1?
> 
> // with comedi commands running
> While (!stop_flag){
>    i=0;
>    while (i<AI_SIZE){     // update (overwrite) each ai sample on dpram
>       i += read(comedi_fileno(daq), *(dp_ram_ai+i), AI_SIZE-i);
>    }
>          // ao from 1-scan-old ai ready, write it
>          // (desperately wishing my ao board supported TRIG_FOLLOW)
>    write(comedi_fileno(ao), *dp_ram_ao, AO_SIZE);
> }
> 
> Also, as an engineer who "also writes software", I do middle-school C, not
> kernel hacking.  KNOPPIX 3.4 has a 2.6.6 boot option (I've been using
> 2.4.26), and I heard 2.6 supports preemption, but how do I write a program
> using it?  I'm on a dual processor machine, so could I safely lock one
> processor indefinitely?  (RTAI would be *way* over my head - I'll probably
> have enough trouble learning to make this a kernel module.  I assume I'll
> need to, given the timing... one thing at a time!)
> 
> Michael Thomas
> 
> -----Original Message-----
> From: comedi-admin_at_comedi.org [mailto:comedi-admin_at_comedi.org] On Behalf Of
> Bernd Porr
> Sent: Monday, October 04, 2004 8:56 AM
> To: Nils Juergens
> Cc: comedi_at_comedi.org; Tao Geng
> Subject: Re: nervous about command timing
> 
> Hi!
> 
> I do this usually with two comedi commands. One to aquire the data and 
> one which sends out the stuff. Under 2.6 with the preemptive option I 
> get 1kHz realtime I/O with just a "while (1)"-loop. My colleague Tao is 
> controlling a walking robot in that way. I've copied the mail to him.
> 
> /Bernd
> 
> www:    http://www.berndporr.me.uk/
>          http://www.linux-usb-daq.co.uk/
> Mobile: +44 (0)7840 340069
> Work:   +44 (0)141 330 5237
>          University of Glasgow
>          Department of Electronics & Electrical Engineering
>          Room 519, Rankine Building, Oakfield Avenue,
>          Glasgow, G12 8LT
> 
> 
> Nils Juergens wrote:
> 
>>On Fri, 01.10.04, Michael Thomas <Michael.Thomas_at_dynetics.com> wrote:
>>
>>
>>
>>>trigger?  That still wouldn't help my user code stay synced up.  It just
>>>seems there should be a better way.
>>
>>
>>If it's a real time problem (it smells like one :-)) ) you need a real
> 
> time
> 
>>system, e.g. RTAI.
>>
>>It might work like this:
>>
>>* create an RTAI task
>>* make task periodic
>>
>>in the task (via kcomedilib)
>>* read samples (comedi_do_insn())
>>* do stuff (calculations etc.)
>>* write samples (comedi_do_insn())
>>
>>I think it's also possible to combine this method and comedi_command (for
>>increased performance and decreased jitter in the sampling periode).
>>
>>hth,
>>Nils
>>
> 
> 
> _______________________________________________
> comedi mailing list
> comedi_at_comedi.org
> https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi
> 
> 
> _______________________________________________
> comedi mailing list
> comedi_at_comedi.org
> https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi