getAnalogValue should force PullNone

[cefn]

An ambiguous call to getDigitalValue permanently pulls an IO pin at present, and keeping this pull is probably not intended if getAnalogValue is called later in the same program on that pin.

The getDigitalValue call now asserts that a Pull is needed given its digital nature, as covered in #157 either...

• the opportunistic default if not previously set - PullDown so learners are faced with an intuitive 0V on an unconnected input
• an explicit choice of PullDown, PullUp or PullNone passed as a second argument

For consistency, shouldn't a call to getAnalogValue force PullNone, given its Analog nature? It would be feasible to model this on getDigitalValue - a two-arg signature with a "default second argument" of PullNone.

[finneyj]

Interesting observation, and something that needs addressing.

AnalogIn is a bit of a different beast. I can't think of a reason why anyone would ever want a PullDown or PullUp on an analogue input (as it would obvious bias the sample heavily).

I wonder if the solution to this should be to revert to a PullNone mode as a pin leaves digital mode though, effectively constraining the use of the pull up/down resistors to the one state (digital input), without polluting other code? This would also guarantee other modes (e.g. outputs!) are unaffected, and requires no API change.

p.s. I love the irony of this c.f. #157!

[cefn]

Depending on the resistance of the pull-down, a pull on an Analog would save discrete components when wiring a voltage divider e.g. for an LDR, Thermistor.

[finneyj]

interesting use case.

It's a bit awkward as the mbed API doesn't define behaviour for pull up/down logic on analogue inputs. This is why the implementation of setPull() is deferred until use. To implement this I think we'd need to layer break mbed, which i'm slightly reluctant to do as it locks us to a specific processor (We have done this in the past where necessary, but only where no relevant abstraction exists in mbed)...

internal pull-up/pull-down value is around 10K, I believe. #144... Any use for the application domain you envisage?

[cefn]

A 10k is suitable for an LDR, a Thermistor, Humidity sensor, Phototransistor off the top of my head. I'm struggling to think of a simple resistive sensor it wouldn't be suitable for, especially if it's just for classroom demos (i.e. when precision is not so key).

Take the point that it would have to be a solid use case to justify unpicking MBed layers which are expected to be left alone. Hadn't realised the Pull-switching associated with getDigitalValue/getAnalogValue was at that layer. Feel free to close if intervention is not appropriate in the DAL.