[solved] Analog pin configuration outside of setup()

[BDub]

@polystyrene

urate from startup, up until a second call to pinMode(). This did happen to be during setup(), but I'm not positive setup() vs loop() was at issue.

What I noticed in my test firmware was that to start I'd set pinMode() to INPUT, and readings were accurate. Immediately prior to a second call to pinMode(), getPinMode() returned AN_INPUT instead of INPUT. After that second call to pinMode(), readings were inaccurate, but getPinMode() was now returning INPUT, even after calls to analogRead().

I don't know much of anything about the internals of the system, but it seem

analogRead() does not actually require you to set the pinMode() to INPUT or even AN_INPUT explicitly. It will be set the first time you call analogRead(). If you set it as an INPUT that means you want it to be a digital input, which it will happily do as well. Now every time you call analogRead(), it determines that it is in digital INPUT mode and has to switch to AN_INPUT, take a reading, then switch back to INPUT so you can do a digitalRead() on the same pin again elsewhere in your code. This is simply a background convince multi-use of the pin, but as you can see that's causing some inaccuracy, and confusion.

Quick solution is to not set the pinMode() at all when using analogRead().

We probably need to add what I just wrote to the Docs as well

Longer term solution might be to remove this multi-use convenience so that when pinMode() is called explicitly, that's the only way in which the pin will be used. However I'm not sure what percentage of users would miss this multi-use functionality... I would guess not many though.