.
Some notes:
Putting much over 3.3v on the analog input will FRY the chip!
My Netduino Plus2 died when I accidentally went to ~4V. I turned the course adjust by mistake instead of the fine adjust on the power supply.
Also, it's a very good idea to put an ~100Ohm to 1K resistor inline with the ADC input to limit the current into the chip if input does have a slight overshoot over ~3.3v.
Note that for signals from another device, there could be overshoot and undershoot for some short period of time. Especially if connected by a wire. It depends on the rate of change of the input signal, and the impedances of the signal,wire, and input stage.
I had two Netduino Plus2 boards and two Netduino Plus1 boards.
I still do. But, one of the Netduino Plus2 no longer works. And, the ARM SOC gets very hot as soon as I power the board.
For sale: One slightly used Netduino Plus2 board.
From the thread:
http://forums.netdui...n-on-tolerance/
Summary:
When a pin is in ADC mode (PC0-PC5 ; pins 8,9,10,11, 24,25), the voltage limits are as follows:
Low: -0.3v
High: +3.6v (3.3v + 0.3v)
The data sheet is here:
http://www.st.com/st.../DM00037051.pdf
The N+2 uses a 64pin STM32F405RG
From the data sheet:
ADC voltage input specs:
page: 105:
VIL Input low level voltage
Min Vin Low
VIL VSS–0.3v
(VSS is ground. So, the minimum voltage is -0.3v)
Max Vin High
VIH TTa/TC(2) I/O input high level voltage VDD+0.3
See Note2
2.TTa = 3.3V tolerant I/O directly connected to ADC; TC = standard 3.3V I/O.
ADC Characteristics:
Table 67
pages: 124,125
ADC equivalent input schematic:
page: 127
Good Luck!
The correct way to do the counts to volts conversion is shown in the code.
The ADCs in these SOC micros are noisy and the specs are semi-joke. See the manuals for the details. The amount of noise on the ADCs is horrible.
The lower 3 bits (approximately 6 counts) are mostly noise.
Note: Having 3 -> 10+ counts of noise is true for most ADCs on most SOC (systems on a chip).
If you need "good" accuracy, always check the noise, accuracy, linearity, etc.
The ADCs on these low-cost SOCs will vary by temperature, power supply, ground noise, etc.
You can characterize the ADC of a specific chip with a good low-cost precision voltage source like: HP6112A. Check ebay.
You can then use the curve fit method of your choice. Excel offers a line fit function. And, the similar program from Open Office likely also has a similar function.
Again, realize that the ADC linearity, scaling, and noise will change with temperature. However, often very noticeably improvements in the accuracy of the ADC are obtained by doing a curve fit for each device, and doing a 4 or 8-sample average . Also, the ADCs of chips per batch often track closely. Check the date and batch code.
I've had my HP6612A for over 10 years. IMHO, it's essential when I want to get an good idea of how accurate/stable an ADC, and/or board is. Of course, at work, we have much much better precision voltage source supplies. But, IMHO, the HP6112A is fine to check the vast majority of ADCs/ DVMs/ Scopes/ etc. And, I don't have to program/enable the voltage each time.
IMHO, at the very least, an average of 4 samples should be done if any sort of consistent value is desired.
I did my testing with a very quite lab power supply, and had the NP1 and NP2 running off a battery powering the board. (BTW, Amazon has many rechargeable USB/etc battery packs.)
Although, some noise may have been introduced through the USB connection. My USB connection is through a powered Belkin USB2.0 hub. So, it should be pretty quite.
I have a tendency to write my code wordy, and to make sure that there are not any "false" assumptions about the variables/etc.
Since I do a lot of Verilog FPGA code, I hate it when I read some garbage like the following:
New_value = Value1 + Value2 + Value3;
In reality, you have no idea what the above does. The variables may be bit vectors of different lengths, or single bits.
For C code, I believe in putting the variables type as postfix. I use a modified, but very close, version of the accepted prefix or postfix indications of the variable type.
The above code is more explicit in the postfix to make it very easy to understand what's going on in each line.
I have a tendency to be more of a "pain" when it comes coding style and very easy readability. A lot of that has to do with the fact that I taught Computer Engineering programming classes for Freshmen, Sophomores, and Juniors for many semesters when I was in grad school.
And, yes, I know my style above is the old style (from K&R) in some ways. There are personal style choices.
For "C" and embedded programming, I prefer the explicit defines at the start, and keeping variable definitions/etc out of the main code.
I hope the above helps.
Good Luck!