[PATCH v2 03/17] staging: comedi: quatech_daqp_cs: fix ai cmd timing

Ian Abbott abbotti at mev.co.uk
Mon Oct 5 17:10:23 UTC 2015


On 05/10/15 17:17, Hartley Sweeten wrote:
> On Monday, October 05, 2015 8:54 AM, Ian Abbott wrote:
>> On 02/10/15 01:23, H Hartley Sweeten wrote:
>>> According to the users manual, the conversion timing (scanrate) is fixed
>>> to 100, 50, or 25 kHz. The pacer clock is then used to trigger each scan.
>>>
>>> Currently this driver tries to fake other conversion speeds by always
>>> sampling the inputs at 100 kHz and using the pacer clock to trigger each
>>> conversion. It does this by setting the SCANLIST_START bit for each
>>> entry in the scan list. According to the users manual, this bit has to be
>>> set for the first (and ONLY the first) entry of the scan list.
>>
>> I'm not sure.  If you read the remainder of that paragraph in the
>> manual, it says you can use that bit to chop the scan list into pieces,
>> which is what I think the original code is doing.
>>
>> I'd say it's safest to leave the timing alone, as presumably any
>> existing users are happy with the way it is.
>
> But, the last part of the paragraph on page 30 says:
>
> "Although this may be useful for diagnosis or special applications, it is the
> abnormal way of setting the first channel flag and should be avoided
> unless absolutely necessary."

I think that's referring to the case where the "first channel flag" is 
NOT set on the first entry in the scan list.

> There are also advantages to allowing the slower conversion times.
> Depending on the A/D converter, the slower conversion time will allow
> a better sample to be acquired. With the current command support the
> conversion is fixed at 100 kHz even if the user specifies a slower speed.

There are also disadvantages because you can no longer have the 
conversion period set to an arbitrary value with the scan source set to 
TRIG_FOLLOW.

When the scan list only has the "first channel flag" set on the first 
entry, I'm not sure what controls the timing between channels in the 
scan list.  After all, it only has one pacer, and that controls the rate 
at which it starts a new scan (or the rate at which it advances to the 
next piece of a multi-piece scan list).  I can't see anything that 
indicates that conversions within a scan are controlled by the 
prescaling of the pacer clock as your code seems to assume.

> But, if you prefer this patch to be dropped I can redo the series.

Given the uncertainties of operation, I'd say it's safer to drop it.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti at mev.co.uk> )=-
-=(                          Web: http://www.mev.co.uk/  )=-


More information about the devel mailing list