Implement analogReadResolution

[KurtE]

resolves #36

The current released version was always reading with 12 bits of resolution. The Arduino analogRead web page said that by default it should default to 10 bits.

The updated code is now ignoring the arduino_adc[idx].resolution field as this is setup for 12 and you can not change it run time.

Like the MBED version, this version is using the static variable read_resolution to hold the current resolution. Which we then pass through to zephyr when we do the reads.

I also changed the parameter buf that we pass through to zephyr from in16_t to uint16_t as if you choose resolution of 16 bits it was returning negative values.

[facchinm]

I'd rather "remap" the value obtained via zephyr API to Arduino range (something like this 96ad455#diff-0f72c528133d0264d72e0dc51520d88b17cf1c6b548d08f661591ba87dc53cb9R301-R326 ) .
Rationale: the resolution in the device tree is HW dependant, while the one set by the user is not (and could be higher than the maximum supported by the chip, triggering a runtime error).
WDYT?

[KurtE]

WDYT?

Can do it either way.

I see pros/cons on both approaches.

The way I did it, could do as you mentioned, maybe give a runtime error. I am assuming that the hardware driver won't simply
scale up if needed...

The approach you mention, using either a map function or scaling like:

if (user_resolution > device_resolution) result <<= (user_resolution-device_resolution);
else if (user_resolution < device_resolution) result >>= (device_resolution - user_resolution);

With current setup on GIGA, I believe the hardware was initialized to 12 bits and Arduino default is 10 bits.
So, we would have the hardware read in the 12 bits and right shift 2. Likewise, if we ask for 16 bits, it would still
read in 12 bits and left shift the results 4 bits. That is no real gain in resolution over 12 bit.

Now we probably can change the device tree to always ask for 16 bits. But my guess is, that will cause all
analogRead calls to be slower.

I am only guessing here as I have not done that much analog stuff on STM and other boards. Other than we did
help in getting the ADC library converted from Teensy 3.x to support T4.x. And at least with the IMXRT 1060 like
boards, I believe asking for more resolution caused it to run slower, as well as how many oversamples, ...

let me know the way you wish to go.

[facchinm]

Now we probably can change the device tree to always ask for 16 bits. But my guess is, that will cause all
analogRead calls to be slower.

I'd go for this route; in case the user want to go faster using a lower resolution they can write another lib based on the underlying zephyr code (the difference should be unnoticeable unless you do very fast acquisition as in https://github.com/arduino-libraries/Arduino_AdvancedAnalog )

[KurtE]

I updated the code along the line you mentioned, I only updated the GIGA overlay so far. Thought about doing Portenta
but did not find any of it defined yet.

[facchinm]

I refactored the commits a bit to keep the history clean, will merge as soon as the CI turns green 🙂