Problems with ATTiny and it's ADC's


Yeah, I was using this as the reference, it only listed an Analog 1, 2, and 3, no 0, and that first ATTiny core I tried wouldn't accept A1 as a port (pinMode(A1, INPUT)), so I had to use the digital port number, which was 3 and 4 (physically 2 and 3).
I haven't ever tried using the RESET pin for I/O. Will the ICSP programming still work with reset disabled? Very odd that that one ADC won't work for me with two different cores. I haven't found anyone else mentioning it, yet I've run into it in two very different projects now. I even use a "real" ISP programmer now. (USBTinyISP)

Once the reset pin is disabled (and therefore enabled for I/O), ICSP programming won't work. I'm pretty confused with all the pin numbers, etc., specifically which ADC doesn't work, in terms of the DIP pin number?

Another thing to try is use analogRead(7) for ADC1, 8 for ADC2, 9 for ADC3.

I think analogRead(1) should be DIP pin 7, analogRead(2) DIP pin 3, and analogRead(3) DIP pin 2. Is that not what it's doing? I may give this a go tomorrow because it's starting to make me crazy now :fearful:

Thanks!

I saw the great news (you took the kitbiz plunge with One Million Ohms). Congratulations!

The analog pins are the ADC numbers from the datasheet. Which matches perfectly with the table in your post.

So, physical pin 7 (second pin down on the right side of the processor) is labeled PB2 and ADC1. This makes it digital pin 2 (two) and analog pin 1 (one).

A word of caution: the 0.1uF bypass capacitor from VCC to GND is very important in general and especially important when using the analog-to-digital converter. Leave it off at your peril.

It's true!

I saw the great news (you took the kitbiz plunge with One Million Ohms). Congratulations!

Thanks, I had to try it, thought it would be interesting. Starting out slower than I hoped but we shall see!

The analog pins are the ADC numbers from the datasheet. Which matches perfectly with the table in your post.

Thanks for verifying! Spent some time in the code, wasn't sure I ever convinced myself completely, but the comments helped!

Physical pin 7, Arduino pin #2, Analog #1 works.
Physical pin 2, Arduino pin #3, Analog #3 works.
Physical pin 3, Arduino pin #4, Analog #2 is the one that returns extremely low values every time.

Shame about the reset pin, I'll never use it if it means it'll be the last time I program the chip.

UnaClocker:
Physical pin 7, Arduino pin #2, Analog #1 works.
Physical pin 2, Arduino pin #3, Analog #3 works.
Physical pin 3, Arduino pin #4, Analog #2 is the one that returns extremely low values every time.

So are those coded, respectively, as:

analogRead(1);
analogRead(3);
analogRead(2);

Shame about the reset pin, I'll never use it if it means it'll be the last time I program the chip.

Yep, ditto. There is the high voltage programming option but not a lot of folks are equipped for it. I bricked an ATmega328P the other day when I typed in the wrong fuse with AVRDUDE and disabled the reset pin :frowning: It's in the bottom drawer in case I get bored some time, I may fiddle with the HV programming.

UnaClocker:
Physical pin 3, Arduino pin #4, Analog #2 is the one that returns extremely low values every time.

Did you accidentally configure it as an output?

Nope, the code has a #define zoneOneSensor 4
then a pinMode(zoneOneSensor, INPUT);
and a analogRead(zoneOneSensor); just like zoneTwoSensor which works on 3, and when I ran a jumper wire from physical pin 3 to 7, and changed the #define zoneOneSensor to 2 instead of 4, it reads fine.

Are you using the Tiny Core or the HLT core?

Yes. Used both, same results.

UnaClocker:
Nope, the code has a #define zoneOneSensor 4
then a pinMode(zoneOneSensor, INPUT);
and a analogRead(zoneOneSensor); just like zoneTwoSensor which works on 3, and when I ran a jumper wire from physical pin 3 to 7, and changed the #define zoneOneSensor to 2 instead of 4, it reads fine.

I'm thinking 4 won't work? Should be between 1 and 3? (Well 0 and 3 but excluding the reset pin.)

Ok, I managed to get it working. Instead of calling it Pin 3, I called it A2. The HLT core would not let me do that, it wouldn't take pinMode(A2, INPUT);, or any of the A1, A2, A3 defines. This Tiny core does, and it reads the port. Seems to be reading a bit off, but I can apply a correction factor to it as long as it's consistant.
Thanks for the help troubleshooting this, guys.

UnaClocker:
Seems to be reading a bit off, but I can apply a correction factor to it as long as it's consistent.

This was still bothering me, so I gave it a shot. I get near perfect results with the code below. With the inputs tied to ground, three zeroes. Tied to Vcc, three 1023 readings. Connected to a voltage divider consisting of two 10K resistors from Vcc to ground, I get mostly 507 or 508, the three are all usually within one of each other. ATtiny85-20PU at 8MHz, Arduino-Tiny core.

#include <SoftwareSerial.h>
#include <Streaming.h>    //http://arduiniana.org/libraries/streaming/

int a1, a2, a3;
SoftwareSerial ser(1, 0);

void setup(void)
{
    ser.begin(9600);
}

void loop(void)
{
    a1 = analogRead(1);    //dip pin 7
    a2 = analogRead(2);    //dip pin 3
    a3 = analogRead(3);    //dip pin 2
    ser << _DEC(millis());
    ser << ' ' << _DEC(a1) << ' ' << _DEC(a2) << ' ' << _DEC(a3) <<endl;
    delay(1000);
}

You never set the pins to input. I had also read that you need to toss the first result when switching analog pins. So you're definitely having great success. You're using serial on pin 1, AND reading analog from it.... Apparently the pin numbering is nothing like I imagined.

AVR pins default to input on power up/reset. Plus I'm lazy efficient XD The readings I quoted were after it ran a bit, I missed the first reading actually, so they may have been off a bit, but I don't know.

The pin numbering makes me crazy too, what between the DIP pins, the Arduino pins, the port number (e.g. PB2) etc. With The ATtiny85 and Arduino-Tiny, for digital pins, the pin number matches the port (PBn) number, which is nice and straightforward. The argument to analogRead() is really the ADC MUX channel number, not a pin number. So SoftwareSerial ser(1, 0); refers to DIP pin 6 (PB1) and DIP pin 5 (PB0) respectively, and the calls to analogRead() correspond to the DIP pins in the comments in the code.

I think this sheet is very handy when dealing with the tiny's

Here's the output from my Python test program:

Zone 1 ADC = 740
Zone 2 ADC = 729
Zone 1 Voltage = 0.705
Zone 2 Voltage = 0.703
Zone 1 is 20.46C
Zone 2 is 20.27C
Zone 1 is 68.8F
Zone 2 is 68.5F

I changed my sketch to use the internal VRef, hence the higher ADC numbers than before. Anyways, using my fluke meter, pressing against the pins of the ATTiny itself, both analog 2 and 3 are seeing the exact same voltage, which was .704 during this testing. I'm not exactly sure why the CPU is reporting different numbers, but I apply a correction factor (vary the ARef voltage in the equation "ARef/1024") to get the correct voltage. It seems that if I get the voltage to read correctly, the temperature comes out correct.
Anyways, thanks for the help on this one guys.

Hmm, yes that is off a bit. As a test, I'd connect pins 2 and 3 together and then connect them to a single sensor. Or to a voltage divider or potentiometer. If they don't track very close, within a count or two, then I'd say the microcontroller has issues. If they do track, then I'd look to the sensor circuitry for differences. What sensors are being used, anyway?

I'm using TMP36 sensors. I'll give that a shot. I've got a whole bunch of these ATTiny85's, I'll try swapping a different one in.