RE: Does anyone actually use kcomedilib?

Thank you very much.  Your code shows me how comedi_lock and comedi_unlock are to be used.
It also seems I'm on the right track with my proposed sequence of instructions to call.

Could you please explain why the need for the three sequential calls to comedi_command_test() function?

Since data is buffered on both our A/D card and the video frame grabbers, the Vsync interrupt is "real-time enough" for our setup or we'd be dropping video fields and the whole system would be broke and useless.  The A/D sample clock and Vsync pulse are phase-locked.

I see you are not using the async structure and init_async_buf(), is this because you are using comedi_map() instead? or is this a difference between how your board and my board's driver works?

Again thanks, this is the first actual bit of code I've found so far.

--wally.




From: Yoshiya Matsuzaka
Sent: Thu 7/26/2007 1:19 AM
To: Kulecz, Walter (JSC-SK)[WLS]
Subject: Re: Does anyone actually use kcomedilib?


Hi,

   I may not understand your need correctly, but if you are trying to read the 
data from your devices within guaranteed latency, using the RTAI and kcomedilib 
is a good idea. Actually, I have done that and posted a sample code to the ML 
some time ago (probably this month). Currently, I am sampling data at 1.25 MHz 
with that code.
   I hope it helps.

Yoshiya Matsuzaka

Kulecz, Walter (JSC-SK)[WLS] wrote:
> Does anyone actually use kcomedilib?
>  
> Am I wasting my time trying to learn to use it?
>  
> Google code search for kcomedilib turned up nothing that wasn't in the 
> Comedi distribution or various RTAI or LXRT headers/readmes, none of 
> which had any useful code examples.
>  
> --wally.
>  
>  
>  
> ------------------------------------------------------------------------
>   
> ----- Original Message ----
> Subject:   	Using kcomedilib, am I on the right track?
> 
>  
> 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.
>  
>  
> ------------------------------------------------------------------------
>   
> ----- Original Message ----
> Subject:   	Can kcomedilib be used to do this?
> 
>  
> I've been a lurker on the comedi list for a long time, but have never 
> actually used Comedi, instead I've used the Comedi source as a guide to 
> write my own much simplified drivers for use with RTLinux-2.1.
>  
> We've a project where real time video data is analyzed (two frame 
> grabbers, 60 fields/sec) and needs to be synced with A/D and DIO data.  
> Currently we use a version of the existing RTLinux system for A/D and 
> machine control while the video analysis runs on a separate computer.  
> The data streams are currently synced by an IRIG time code returned with 
> each sample of the A/D and DIO data and overlaid on the video images 
> which time stamps each field of the video analysis output as well.  The 
> downstream analysis then uses the embedded time stamps to sync the 
> analog and video data streams.
>  
> This has worked well but the video overlay inserter hardware is 
> expensive, and is now old enough to be a reliability issue.
>  
> My plan is to modify the Linux video driver (bttv.ko and video-buf.ko) 
> to return A/D and DIO data along with each video frame.  D/A and DO data 
> will be passed in when I queue the V4L2 buffer for /dev/video0, while 
> the DI and A/D data will be returned when I dequeue the VFL2 buffer.  
> This would eliminate the need for the expensive video inserters and time 
> code board, and run everything on a single computer.   
>  
> I've already made the mods (Ubuntu 6.06 LTS) to the video driver modules 
> to allow this and tested it by returning data synthesized in the Vsync 
> interrupt service routine so there appear to be no show stoppers on the 
> video side, and my mods still have /dev/video1 work exactly as before.  
> In fact the current video analysis software works fine with the modified 
> video driver modules since it doesn't use the new features I've added to 
> the video driver.
>  
> Question is, can I install comedi and use kcomedilib to write D/A and DO 
> data, and read all the A/D data acquired between "now" and the previous 
> Vsync interrupt and the current DI data?  I'd be using kcomedilib 
> read/write functions at interrupt time much as I run my current RTLinux 
> driver in the RT interrupt service routine.  The open, setup, and close 
> kcomedilib functions would be called during the /dev/video0 open and 
> close system calls and thus be "normal" kernel module operations.
>  
> Currently we use Computer Boards PCI-DAS1602/16 boards.  Anyone 
> experienced with kcomedilib think this would be viable or not? and which 
> kcomedilib functions would be best for the reads and writes?  We want 
> the A/D data to be perhaps as high as 2000 samples of the 16 channel 
> scans per second.  DIO and D/A at 60Hz is fine.  My dummy code is moving 
> this extra data between kernel and userspace along with the video data 
> without apparent problem.
>  
> The advantage of using kcomedilib would be I could avoid writing A/D 
> board specific code and then perhaps use other comedi supported hardware 
> in the future.  The disadvantage is the learning curve for kcomedilib 
> and the risk of only learning that it won't work as I need.  Another 
> disadvantage is having to redo the video driver mods for a new kernel or 
> different video capture card, but given the performance and low price of 
> bt878 based capture cards its easy to argue why use anything else, and 
> since we are not connected to the internet sticking with an "obsolete" 
> Linux version is not a burden as the RTLinux-2.1 on top of RedHat-6.1 
> has done what we've needed up to now for a long time (we've eight 
> systems on all three coasts and they have been the most reliable parts 
> of these systems despite the initial fears that I'd be the only one able 
> to maintain them).
>  
> I haven't found any kcomedilib example programs yet, a few could help a 
> lot, are there any?  While RTLinux has worked very well, I'd like to 
> avoid using it or RTAI if possible as using a well supported and easy to 
> use Linux like Ubuntu is enough of an uphill battle as it is.
>  
> Learning how to modify the V4L2 drivers was difficult since I got  no 
> help at all from the video4linux-list in even getting to first base as 
> to how to recompile only the video modules without a total kernel 
> rebuild.  I figured it out with some Google searching about kbuild and 
> trial & error editing of the Makefile in the 
> /usr/src/linux/drivers/media/video directory.  The changes ended up 
> being pretty minor touching only four files: bttv.c, bttvp.h, 
> video-buf.c, and video-buf.h.
>  
> TIA
> --wally.

-- 
----------------------------------------------------
Yoshiya Matsuzaka, MD/PhD
Dept. of Physiol., Graduate School of Medical Science,
Tohoku Univ.
2-1 Seiryo machi, Aoba ward, Sendai 980-8575, JAPAN
Tel: +81-22-717-8073, Fax: +81-22-717-8077
URL: http://www.med.tohoku.ac.jp/~2sei/
----------------------------------------------------