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@xxxxxxxxx> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
