Hi -
Sorry about that. Here's what I was trying to suggest:
1. It sounds like the problem has to do with "performance".
Since you're an EE (hence comfortable with math), this book might be of interest to you:
The Practical Performance Analyst, Neil Gunther
http://www.amazon.com/gp/product/059...lance&n=283155
2. But before you do any analysis, you need to get some numbers.
That's where "gprof" comes in.
You can add special flags when you compile your program that that, as it runs, certain statistics will be accumulated. Then you can dump these statistics to try to figure out why your program isn't executing as quickly as you expected it to.
Here is a nice, short tutorial on gprof. You can easily google for many others:
http://badgertronics.com/writings/gprof.html
3. If things are "taking a long time", then you'll generally find it's for one of two reasons:
a) Either the application is "compute bound" (in which case you'll see high CPU usage,
and quite probably one particular subroutine called an excessive #/times)
... or ...
b) The application is "I/O bound" (in which case you'll see *LOW* CPU usage, and
quite probably one particular subroutine will show excessive wait times).
4. From there, you need to figure out *what* is wrong.
It's probably less a problem with comedi (although that's certainly possible), than a
problem with the way you're using comedi (for example, excessive polling: constantly
looping to check if some data is available).
5. Finally, I suggested you might want to join the comedi mailing list. You can do so from the comedi web page:
http://www.comedi.org
'Hope that helps .. PSM