SAUL: Add periph/adc support

[jnohlgard]

(depends on #4430, #4860, #5110)

This PR adds support for reading ADC lines through SAUL. Currently only raw ADC reading is supported, so no physical units yet. Only mulle is configured.

In a follow-up I intend to add scaling functions to convert raw values to physical values for analog sensors and support for multiple values. The extended use case for my application is to add an analog temperature sensor and an analog 2-axis accelerometer, and still having the application itself completely hardware independent.

[haukepetersen]

nice one. The problem with the physical values/scaling of RAW values could maybe be solved by adding some kind of conver_cb() function to the SAUL ADC configuration struct?

[temmihoo]

What about leaving the value space processing to userland program? It should anyway be made with the knowledge of what hardware there is, what's the word width and how the adc values are preprocessed in analog domain.

I would not try to abstract that into some hidden thing that magically does what you want, except when you want something other than black paint for your model T.

Likewise, triggered point conversions in time are just that and a continuous conversion stream is that. Both need their respective post-processing and its needs depend quite a lot on what analog preprocessing was done before ad conversion. With respect to this, I would SAUL just the actual handling of converter control and would leave the values as is.

[temmihoo]

Anyway, nice to see ADC coming under SAUL control and also nice to see my favourite SoC family STM32 is also getting support pretty early on, thanks a lot Hauke :)

[jnohlgard]

@temmihoo
This current PR will do what you say; All value conversions must be performed by the user application.

What I would like to do in a follow up however, is to add the possibility for analog sensors to give physical measurements like we have for digital sensors today. It will still be possible to configure the SAUL driver to pass the ADC values straight through with no conversion performed at all.
Today, all digital accelerometer drivers in RIOT provide measurements in units of G instead of different raw values, and I need to integrate an analog accelerometer that I have for a project demo.

A real world use case:
For the sake of discussion, let's say I have some control algorithm that I use to control the central heating for a building. I would like to design this algorithm so that the desired indoor temperature is set in degrees Celsius. I also want to be able to see the current ambient temperature in the building, the temperature on the different water lines, and the temperature outside.

The easiest way to design the control algorithm is to only use one unit for all temperatures (to avoid conversion mistakes when comparing different measurements). I want this algorithm to be future proof in the sense that I may want to replace the temperature sensors with different ones depending on availability, price, performance etc. (indoor and outdoor sensors may not even be the same kind of hardware). If I can get all my temperatures from SAUL and I know that all of them are in Celsius, then I only need to worry about implementing the actual control algorithm in my application, and I can transparently replace sensors without having to rewrite my control application. Using SAUL it will not even matter if the sensor is digital or analog, i2c or SPI, from Analog Devices or Maxim, as long as it can provide the temperature to the SAUL layer.

[temmihoo]

@gebart
Oh that sounds nice. Adding useful abstractions is nice as long as it stays opt-in, which you just described to be the case :)

[jnohlgard]

@temmihoo Regarding opt-in for value conversions, I agree. I'll prepare another PR with the unit conversions later when I have some spare time, in the mean time we need to review #4430 so that this PR can be rebased on master.

[haukepetersen]

looking into #4430 now :-)

[DipSwitch]

Needs rebase

[jnohlgard]

rebased and cleaned up. Depends on #5110 and #4860

[haukepetersen]

dependencies are merged, care to rebase?!

[jnohlgard]

rebased, sorted the pseudomodules list.

[haukepetersen]

you could remove this function and use saul_notsup() from drivers/saul/saul.c instead.

[jnohlgard]

cool, I did not know that, thanks!

[haukepetersen]

was just recently merged :-)

[haukepetersen]

needs rebase. Otherwise ACK for the changes once the little remark above is addressed. Can we make it into the release with this one?

[jnohlgard]

rebased, replaced the write stub by saul_notsup

[haukepetersen]

go Murdock, go :-)

[haukepetersen]

seems like some boards need to define ADC_NUMOF 0 to make Murdock happy?!

[jnohlgard]

Rebased, updated to build properly on boards with no ADC configuration, re-added a file that accidentally went missing during the last rebase.

[jnohlgard]

Can we get this in the release?
OK to squash?

[OlegHahm]

Ask the release manager. ;)

[haukepetersen]

yes, please squash and and let's include it

[jnohlgard]

rebased, squashed, let's wait for Murdock

[haukepetersen]

oh man, things are moving fast currently. Would you be so good and rebase once more? Thanks.

[jnohlgard]

@haukepetersen rebased

[haukepetersen]

nice, Murdock is happy -> go