- From: Ian Abbott <abbotti_at_mev.co.uk>
- Date: Thu, 09 Mar 2006 12:57:50 +0000
On 09/03/06 11:52, Stienen, A.H.A. (CTW) wrote:
> Ian Abbott wrote:
>> int configure_quad(comedi_t *dev,
>> unsigned int subd,
>> unsigned int encoding, /* GPCT_X1, GPCT_X2 or GPCT_X4 */
>> unsigned int indexphase, /* GPCT_IndexPhaseHighHigh,
>> GPCT_IndexPhaseLowHigh, GPCT_IndexPhaseLowLow or
>> GPCT_IndexPhaseHighLow */
>> unsigned int resetonindex /* 0 or
>> GPCT_RESET_COUNTER_ON_INDEX */
>> )
>> {
>> comedi_insn insn;
>> lsampl_t data[4];
>>
>> memset(&insn, 0, sizeof insn);
>> insn.insn = INSN_CONFIG;
>> insn.subdev = subd;
>> insn.data = data;
>> insn.n = 4;
>>
>> data[0] = INSN_CONFIG_GPCT_QUADRATURE_ENCODER;
>> data[1] = encoding;
>> data[2] = indexphase;
>> data[3] = resetonindex ? GPCT_RESET_COUNTER_ON_INDEX : 0;
>>
>> return comedi_do_insn(dev, &insn);
>> }
>
> Ian,
>
> Why do you pick insn.n is 4? Isn't .n based on the number of sample
> points you want to get back when inserting a data-read request? In the
> original test programs of Klaas Gadeyne .n for the config insert was set
> to 0. This turned out only to work when first a data-read or a
> get-time-of-day was performed on the device, but when .n was set to 1,
> it did work properly without the GTODs or data-reads. But other than
> this, it seems to an irrelevant option for configuring.
insn.n is the length of data[]. For insn.insn == INSN_CONFIG, the
required length of data[] depends on data[0], but the checks performed
by the Comedi driver are not very rigorous - see
check_insn_config_length() in comedi/comedi_fops.c.
--
-=( Ian Abbott _at_ MEV Ltd. E-mail: <abbotti_at_mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Received on 2006-03-09Z12:57:50