- From: Daniel Nilsson <daniel_at_oden.homeip.net>
- Date: Sat, 19 Mar 2005 09:32:30 -0500
On Sat, Mar 19, 2005 at 02:57:20PM +0100, Jan Gukelberger wrote: > On Wed, 2005-03-16 at 16:08 +0000, Daniel Nilsson wrote: > > Frank, > > > > I'm only concerned with input at this time, checking for the number of > > samples received seems reasonable. My only concern with this is error > > handling, which I don't know how to check for. Is it reasonable to think that > > if I'm just waiting in a loop to see if I have sampled all my data that the > > hardware could take some kind of error and stop ? In that case, I'm worrying > > about being stuck in the loop waiting for data forever. Can I check somehow if > > the command is process died due to an error ? > > Well, I can't easily imagine a situation where the hardware just stops > sampling, but if you're recording with a fixed sampling rate and you > didn't receive any data for (some (small) constant)/(your sampling rate) > you could quite reasonably suspect that there won't be any more data, > couldn't you? Yes, I thought of this option as well. Seems like this might be the best thing do to in this case. It would have been better the be able to actually find out from the kernel driver what went wrong though, since now the only error message I can produce is a "timeout". That is however much better then just hanging the software... In case I get this timeout, is there a way to query the kernel driver for error status ? Would comedi_perror() etc have useful information ? Thanks -- Daniel Nilsson
Received on 2005-03-19Z14:32:30