Problems with ATTiny and it's ADC's

I'm having some issues with my ATTiny85 chips I'm trying to use in a project. The ADC's don't seem to be working at all for me. When I read them one of them stays around 5-7, and the other stays around 235, neither of which is correct. This ATTiny is running at 3.3v, confirmed with a Fluke multimeter. The ADC's are getting good values in from TMP36 sensors, pins 2 and 3 are both at .719v (again, checked with a Fluke multimeter), which doing the math, (719-500)/10 = a believable room temperature in celsius. I'm using this guide and the library he links to:
http://hlt.media.mit.edu/?p=1695
To program the ATTiny with Arduino.
I've written this simple program that runs on the Arduino:

And yes, I simplified the program and took out my averaging routines, spitting just an instantaneous ADC reading out the serial port when queried, with no change. "Zone 1" does seem to react to changes in temp, going down to 220 from 235, but still way off. Zone 2 just stays around 5 (4-7, kind of noisy).
Is SoftwareSerial screwing with the ADC? Do I need to do something special to get the ADC to work at 3.3v rather than 5v? I figured it'd just be fine.
I hope someone can help me with this odd issue.

Hi @UnaClocker,

I searched for an old thread but couldn't find it, but I think this came up before and the answer was that the HLT core didn't support analog, but Arduino Tiny does (and the support for it here is good XD)

I hope I'm remembering that correctly; I'm sure someone will correct me if not.

Thanks for the suggestion. I tried the Arduino-Tiny core as well, and am actually using it now, since there's not much point in switching back. It didn't help, but I did have a brain fart of sorts. I was thinking the ADC was 8 bit.. It's 10 bit.. So 235ish is totally within the correct range. It's within an acceptable margin of error of the correct reading.
As for the other ADC, I've actually encountered this on past ATTiny projects, and go figure, I forgot about it when designing my PCB for this project. "Pin 4"'s ADC doesn't seem to work, so I ran a jumper over to "pin 2", and changed the sketch to use pin 2. It now reads the same readings on both sensors.
The last time I encountered this, I was running an ATTiny on perfboard, I had a potentiometer going into that bum ADC and was using it to vary a PWM output to control a motor speed. Couldn't figure out why the motor speed wouldn't change until I finally tried a different ADC. That was at least 6 months ago, if not 9..
Oh well. I can move forward on my project now. Thanks for the reply.

Sounds like memory failed me on that old thread.

Without actually testing it, I believe the analog channels are 0 through 3, which might be why "4" has an issue. The pin numbers below are the DIP pin numbers:

ADC0  Pin1  PB5 (RESET)
ADC1  Pin7  PB2
ADC2  Pin3  PB4
ADC3  Pin2  PB3


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