Interface for comedi_get_cmd_generic_timed

Hello,

Would it be worthwhile adding an n_channels parameter to the end of the call 
for comedi_get_cmd_generic_timed? I notice that if I set up a timed analog 
input command, then fill in a channel list with 6 channels, then pass it 
through comedi_command_test, the scan rate is 1/6 of what I meant it to be. 
This occurs because scan_begin_arg and convert_arg get set by 
comedi_get_cmd_generic_timed to the same value, and command_test believes 
convert_arg rather than scan_begin_arg when it detects a conflict.

A hack is to pass the (timing delay/n_channels), instead of (timing delay), as 
the parameter to comedi_get_cmd_generic_timed. While that fixes the analog 
input problem, it does so at the expense of messing up multi-channel analog 
output (since convert is set to NOW for analog output, comedi_command_test 
will keep the value set for scan_begin_arg).

For now, the best solution is adjust convert_arg (convert_arg /= n_channels) 
after a call to comedi_get_cmd_generic_timed. But since the convert_arg 
parameter is the most crucial one as far as timing goes (scan interval must 
be n_channels*(convert interval), all expressed as integer multiples of the 
basic hardware tick interval), doesn't it make sense that 
comedi_get_cmd_generic_timed should get it right the first time? I went 
through a couple rounds of bug finding/fixing/new bugs introduced/fixing 
before I figured out the right way to handle this, and it seems that an extra 
parameter in the function call would make everything cleaner (and obviate the 
need to dive into comedlib code to figure out what is going on, for whatever 
that's worth).

Best,
--Tim

Received on 2002-09-20Z19:17:38