When testing streaming input (or streaming output) command functionality
for a subdevice, attempt to make it the current 'read' (or 'write')
subdevice by calling the new 'comedi_set_read_subdevice()' (or
'comedi_set_write_subdevice()') function.
That is currently only supported by the Linux "in-tree" version of
Comedi, since kernel version 3.19. If the attempt fails, and the
subdevice is not the current 'read' (or 'write') subdevice, the test
will report "not applicable" as before.
If the comedi data buffer is larger than the total size of the data
being written to the buffer in first test_cmd_write_fast_1chan(), the
first loop iterates endlessly writing 0 bytes to the buffer. Break out
of the first loop once the required amount of data has been written.
Remove the global variable 'capabilities' which is set to 0 by the
get_capabilities() function but not used anywhere else. Remove the
'type' and 'flags' local variables from get_capabilities() which are set
to the return values of comedi_get_subdevice_type() and
comedi_get_subdevice_flags() but never used. Remove the 'tmp' local
variable from test_segfault(); it was involved in a volatile memory
access to test for segmentation faults. Still do the volatile memory
access but don't use the variable.
The 'go' variable is only used by the 'while' loop that reads the data.
We don't need to set it in the 'for' loop that checks the data
afterwards.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
If the command does not stop immediately after the last sample, there
can be more data to read than we have room for. Make sure the 'while'
loop 'read()' does not overrun the end of the malloc'ed 'buf'.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
A struct timeval is not the same size as a pair of lsampl_t's for 64-bit,
so can't point 'data' in a comedi_insn to a struct timeval and expect it
to work!
I was running "comedi_test -v" on my new analog output driver and
noticed that it was getting stuck in a loop during the
"cmd_write_fast_1_chan" test.
It turned out that the test had written more data to the buffer than was
required to complete the acquisition (it was using cmd->stop_src =
TRIG_COUNT) and then got stuck in a loop waiting for the buffer to empty.
The attached patch stops the test_cmd_write_fast_1chan function writing
more data than is required to complete the acquisition.
