I'm trying to run this simple code below in a Digispark Attiny85 board. The main problem is, when I connect the pins 2,3,4 and 5 to ground, for example, so the analog read would zero the board just "crashes" and LED stops blinking. Of course this is a super simple example but it illustrates and isolates the main problem I'm having in a larger context.
So, I've read the datasheet and lots of resources and found no warnings about using P2-P5 simultaneously to read analog input. Maybe I'm missing something. Any hints would be appreciated.
Best,
int x1;
int ldr1, ldr2, ldr3, ldr4;
void setup() {
pinMode(0, INPUT); // Some digital input
pinMode(1, OUTPUT);
pinMode(2, INPUT); // Some analog sensor
pinMode(3, INPUT); // Some analog sensor
pinMode(4, INPUT); // Some analog sensor
pinMode(5, INPUT); // Some analog sensor
}
void loop() {
x1 = digitalRead(0);
ldr1 = analogRead(2);
ldr2 = analogRead(3);
ldr3 = analogRead(4);
ldr4 = analogRead(5);
digitalWrite(1, HIGH);
delay(50);
digitalWrite(1, LOW);
delay(50);
}
Are you sure it’s not just A0 that causes the problem? Some clones don’t disable the reset enable fuse which makes that pin hold the processor in reset reset when a logic low.
I suspect the issue is as WattsThat said - ie, that it isn't the fact that you're reading all the pins, but rather that there's an input on the reset pin that's going below the reset threshold, and the reset pin is not fused to act as GPIO (some of the digispark clones available now have that set, but not all do - note that if it is set as reset, it's not possible to program it except using the flash-hogging digispark bootloader, unless you have an HV programmer to set the reset pin back to acting as reset instead of gpio)
Also - I don't know off the top of my head how the digispark core works w/regards to analogRead and pin numbers - ie, whether analogRead(5) reads arduino/digital pin 5, or if it uses ADC channel numbers (and hence there's no 4 and 5). The shitshow of a precedent that the official arduino boards set with "analog pins" led to inconsistent implementations on third party cores.
Dr. Azzy is quite correct about pin assignments, you appear to be using the wrong pin numbers. In addition, calling pinMode() sets a pin as digital and is not required or desired for analog inputs.
WattsThat:
In addition, calling pinMode() sets a pin as digital and is not required or desired for analog inputs.
Mrrrrrmmmppp!
Wroooong!
pinMode() configures the data direction register for the hardware you're using to either input or output (eg, the appropriate bit in the DDRx register on a classic AVR) and, if setting it as INPUT_PULLUP, the appropriate register to make that happen (eg, for a classic AVR, you get the pullup turned on by setting DDR to input, while PORT is set high - for other families of chips, the specific registers are different).
If you had a pin set as OUTPUT, or INPUT_PULLUP, to use is as INPUT without pullup, whether you are reading with digitalRead() or analogRead(), the pin must be set back as an INPUT with pinMode(). There is no difference in how the data direction registers need to be set for analog or digital reads (at least on AVRs - may be different for other families, but I can't think of any for which it is off the top of me head) - a pin does not get set as "analog" or "digital"
After a reset condition, none of the pins are configured as OUTPUT. Thus, setting pinMode(pin,INPUT) in setup() does nothing except waste a bit of flash and a few dozen processor cycles - the chip state is the same before and after the call to pinMode().
When we plan a project we analyze the requirements as to memory size, I/O pins required etc. We then choose hardware meeting these requirements.
I do not know the Digispark Attiny85 board or the available special software to handle it. However from a pure hardware point the ATtiny85 does not meet your sketch requirements.
I do use the ATtiny85 for some projects. I program it using ISP. I do not use a bootloader (there are plenty MCU more suited for use with a bootloader). As already explained above you need the reset pin to program the MCU - for both ISP and normally the bootloader. Therefor, you have three pins not available - reset, GND and VCC, leaving you with 5 pins. Your sketch requires 6 - as far as I am concerned the hardware is not suitable. I would merely scale up and probably use the ATTiny84.
The reset pin is not required to program via the bootloader - at least some versions of the bootloader rin for 8 seconds after power on reset, so you unplug and replug the board right before uploading.
After making sure that you have found a bootloader image that does this, flash it and then set the hfuse to disable reset.
DrAzzy:
The reset pin is not required to program via the bootloader - at least some versions of the bootloader rin for 8 seconds after power on reset, so you unplug and replug the board right before uploading.
After making sure that you have found a bootloader image that does this, flash it and then set the hfuse to disable reset.
Interesting. Good to know - should I require that.
Problem for me is I use ISP programming, so prabably not an option.