RE: Using kcomedilib, am I on the right track?

My timing requirements are no stricter than the Vsync interrupt which is real-time enough or I'd be dropping video frames and the rest wouldn't matter.  At this point I see no benefit in trying to use one poorly documented interface over another.  

If the irq is serviced in 10 usec or 100 usec doesn't really matter, what counts is I can unambiguously say these n A/D samples were acquired during this video frame time interval, so I don't see what the complexities of RTAI buys me.  The Vsync clock and higher rate A/D sample clock will be phase locked and kept in sync.

--wally.




From: Tabish Mustufa
Sent: Wed 7/25/2007 11:49 PM
To: Kulecz, Walter (JSC-SK)[WLS]
Cc: comedi_at_comedi.org
Subject: RE: Using kcomedilib, am I on the right track?


Since you've got strict timing requirements, it sounds like you'd be
better off with RTAI+comedi.  There's a bit of a learning curve (the RTAI
documentation is sparse, but there are lots of code samples), but it works
quite well.  We use it drive 1.3 khz control loops, and performance is
good.

-Tabish

> Interesting system, but not very applicable to my needs.  If I could do it
> from user space I'd be doing it from user space.
>
> I didn't give all the details of my application, but basically two frame
> grabbers feed an image processing program that outputs 60 Hz (NTSC video)
> sampled x,y,z time series data.  A/D data at up to 2000 samples of
> 16-channels per second is to be synchronized with the video data (cameras
> are genlocked, A/D sample clock is phase-locked to the camera Vsync, its
> TBD if a multiplier of 32 or 34 will be used as we can't get exactly 2000
> Hz).  The PCI-DAS-1602/16 does a conversion in 5 us so 16 channels will
> scan in 80 usec with ~420 usec post scan delay to give ~2000 Hz sampled
> A/D data.
>
> My output data would be an array of structures with the 0th sample a
> special case:
>
> sample 0:
>    v4l2_timestamp
>    xyz[3]
>    ADC[16][0]
>
> sample 1:
>    v4l2_timestamp
>    xyz[3]
>    ADC[16][1-34]
>
> sample 2:
>    v4l2_timestamp
>    xyz[3]
>    ADC[16][35-68]
>
> and so on.
>
>
> Other complications are there will be D/A data passed in the output at 60
> Hz to drive a servo loop, along with DIO data being read/written at 60 Hz.
>  Some of the channels will be grossly over sampled (like the servo feed
> back, but I can use this for noise reduction via averaging).
>
> My question: is kcomedilib usable or not?  either by design or incomplete
> implementation.  If the implementation is incomplete, I might be able to
> contribute if its close enough to take less time fix compared to just
> going off and writing my own driver (the original plan)  instead of using
> Comedi.  But with the apparent lack of documentation and example/demos for
> kcomedilib I just don't see how I'd have the time to get involved.
>
> I'm passing dummy data in and out of my modified v4l2 driver modules
> (video-buf.ko & bttv.ko), now I just need to setup the DAQ hardware and
> use it at Vsync irq time.  Kcomedilib looks like it might work and save me
> development time if I can figure out how to use, if not I'll just use its
> source to learn how to twiddle the bits to make the board do only what I
> require, as I did years ago for our current RTLinux-2.1 systems.
>
> --wally.
>
>
>
>
> From: Bernd Porr
> Sent: Tue 7/24/2007 6:09 PM
> To: Kulecz, Walter (JSC-SK)[WLS]
> Cc: comedi_at_comedi.org
> Subject: Re: Using kcomedilib, am I on the right track?
>
>
> Hi!
>
> Actually, if you are using a standard frame rate normal polling would
> do. It's only every 20ms. So no kernel stuff at all. It's fast enough.
>
> This is the control program to steer our robot towards food blobs. ;-)
> The same program is also used for line following, receptive field
> development etc. Bascially it works so that V4L does double buffering of
> the video data while comedi records asynchronously data and writes out
> sync data to the robot. Anyway have a look. The clock is generated by
> the frame rate. Simple as that.
>
> You can watch me and the robot under this link:
> http://www.berndporr.me.uk/ico_neco/
>
> /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
>
>
> Kulecz, Walter (JSC-SK)[WLS] wrote:
>>  Documentation and examples for using kcomedilib seem pretty sparse at
>> best.  Let me outline what I guess from reading the various sources of
>> what comedilib functions my modified video module would call.
>>
>> #include <comedilib.h>  would be added to the module code.
>>
>> (1) modified v4l2 init_module function would:
>>    create the comedi_t device structure
>>    call comedi_open()
>>    create the async structure
>>    init_async_buf()
>>    create the comedi_cmd structure
>>    initialize the comedi_cmd structure fields
>>    call comedi_command_test()
>>
>> (2) in the v4l2 stream on ioctrl the modified vfl2 module would:
>>    call comedi_command() to start the data capture
>>
>> (3) modified v4l2 module  Vsync interrupt service routine would:
>>     call comedi_get_buffer contents() to retrieve A/D data captured
>> since start of capture or previous Vsync interrupt
>>
>> (4) in the modified v4l2 stream off ioctrl to stop video capture:
>>    call comedi_cancel() to stop the acquisition
>>
>> (5) modified module remove_module function would:
>>    free allocated comedi structures
>>    call comdei_close()
>>
>>
>> Is this a viable starting flow?  Am I missing any essential steps?
>> Where does the buffer used for the async A/D get allocated?   do I do
>> it? or is it done auto magically when I setup for the command?
>>
>> I've no idea at present of how  comedi_lock() and comedi-unlock() are to
>> be used.  I assume this is will be real important as I'm using a dual
>> core CPU.
>>
>> A sample/demo module using kcomedilib would be even more helpful.
>>
>> --wally.
>>
>>
>>
>>
>