The main thing here is providing a new function to convert counts to volts. Example updated to show usage. Not sure what's less clunky? This PR, which requires making two calls (one to read, one to convert) OR adding new "volts" versions of existing raw ADC read functions, like readADC_SingeEnded_Volts or some such. Could also be a parameter maybe? readADC_SingleEnded(uint8_t channel, bool volts=False);
Another minor but (possibly) significant tweak is changing the return type of readADC_SingleEnded from uint16_t to int16_t. The use of uint16_t has been the source of lots of confusion and issue generation. It worked fine, not really an issue, but technically, all the register values are signed:
even if generating a negative value is not possible for the current arrangement. Using int16_t also works, and I'm not seeing any reason not to just use that.
The main thing here is providing a new function to convert counts to volts. Example updated to show usage. Not sure what's less clunky? This PR, which requires making two calls (one to read, one to convert) OR adding new "volts" versions of existing raw ADC read functions, like
readADC_SingeEnded_Volts
or some such. Could also be a parameter maybe?readADC_SingleEnded(uint8_t channel, bool volts=False);
Another minor but (possibly) significant tweak is changing the return type of
readADC_SingleEnded
fromuint16_t
toint16_t
. The use ofuint16_t
has been the source of lots of confusion and issue generation. It worked fine, not really an issue, but technically, all the register values are signed: even if generating a negative value is not possible for the current arrangement. Usingint16_t
also works, and I'm not seeing any reason not to just use that.