Bug in compiler or what ever?

Simplified circuitry there is 2 LEDs and 1 analog input. LED connected to pin PB1 lights very dim when output is high. It seems that output has been configured to high impedance mode. That happens if inside setup() analog input A1 (pin 7, PB2) is configured after digital output PB1. If order of pin configuration is changed everything is OK. Is that compiler bug?

/*            ____
    D5 PB5  1|o   |8  Vcc
    D3 PB3  2|    |7  PB2 A1   Voltage measurement, potentiometer
    D4 PB4  3|    |6  PB1 D1   --|>--|
       GND  4|____|5  PB0 D0   --|>--|

byte led0 = PB0;
byte led1 = PB1;
byte potentiometer = A1;
int voltage;

/* It is important in which order pin configuration has been set.
Wrong order causes PB1 to high impedance, low current, output.
This must be compiler bug, I think.
If port BP1 setup has been made using straight to register there is no problem in order.
Any other analog input port and digital port combination works correctly. 

void setup()
  pinMode(led0, OUTPUT);
  pinMode(led1, OUTPUT);  // Doesn't work if this is before pinMode(potentiometer, INPUT);
  //DDRB &= ~(1 << DDB2); // Alternative working setup for analog input A1
  pinMode(potentiometer, INPUT);  
  //pinMode(led1, OUTPUT);  // Works if this led1 setup is after pinMode(potentiometer, INPUT);

void analog_input()
  voltage = analogRead(potentiometer);
  if (voltage < 500) {
    digitalWrite(led0, HIGH);
    digitalWrite(led1, LOW);
    digitalWrite(led0, LOW);
    digitalWrite(led1, HIGH);

void loop()
  • 1
    \$\begingroup\$ A more detailed description / schematic could help. How do you power the MCU? Do you really connect LEDs without any current-limiting resistors? That could have damaged the pin, resulting in all sorts of weird behavior. \$\endgroup\$ – Dmitry Grigoryev Jan 31 '17 at 10:26
  • \$\begingroup\$ LEDs have 470ohm resistors and powered using battery or USBtinyISP. No difference. I have tested with several devices. Interesting is really configuration order in setup(). Current from output is in bad case only 62uA because voltage drops down to 2,6V. Problem is only in thes pins. As I mentioned in the code there is no problem if configuration is made using straight register commands. \$\endgroup\$ – Paavo Merilinna Jan 31 '17 at 11:29

It should be noted that ATtiny is not supported by Arduino IDE out of the box. There are several third-party implementations (e.g. 1, 2, 3) which provide necessary files (mostly pin definitions) for Arduino, and you didn't tell us which one you're using.

The error looks like the implementation you're using has screwed up pin mask definitions, since applying the right mask directly in your code works. You should check the code you end up compiling (specifically the constants used in pinMode() function) for obvious errors. There are makefiles for Arduino (e.g. arduino-mk) which can be instructed to provide you with the preprocessed *.cpp file, as seen by the compiler. I always prefer looking into those, because they represent the real code, after all the tricks that Arduino IDE pulls out.

If doing that sounds too hard, I suggest you file a bug to the developer of the implementation you're using. Or just pick a different implementation, which will probably have a different set of bugs.

Compiler bug seems unlikely, because compilers are usually rigorously tested before they are released, unlike amateur projects on github.


As noted in the documentation, you cannot use the A# defines for pinMode() - you will get unexpected behavior. You must use the Arduino pin number, or the PIN_xx define. PBx works on the tiny85, but may not work on all chips - the PBx defines come from the compiler, and are #defined to the number of the bit within the port registers that controls that pin.

Edit: Misread the original problem.

  • \$\begingroup\$ Still confusing. What documentation says that here A1 is not allowed for pinMode? It is used generally in AtTiny codes. Arduino pin number, here 7, works with AtTiny85. PIN_B2 or PINB2 doesn't work at all. Why problem is in present only if code lines are in mentioned order? Why using damellis core there is no problem? It could be nice if somebody will explaine clearely wahat different cores and how and exactly pin defination must be done. Now all the small notes and helps are here, there and everywhere. \$\endgroup\$ – Paavo Merilinna Feb 13 '17 at 1:53
  • \$\begingroup\$ From the official documentation (Readme.md): "Note that analog pin numbers (ex A0 ) cannot be used with digitalWrite()/digitalRead()/analogWrite() - all pins have a digital pin number. Analog pin number should only be used for analogRead() - this represents a departure from the behavior used in the official AVR boards. This enables us to expose the advanced ADC functionality available on some of the ATtiny parts" \$\endgroup\$ – Dr. Azzy Feb 14 '17 at 5:10
  • \$\begingroup\$ The whole concept of calling some pins "analog pins", which is what the convention you're using came out of was IMO a terrible mistake, as it leads new users (which Arduino is meant to be friendly to) to think that there are somehow two different kinds of pins, and that analog pins can't be used as digital ones. I've tried to do a better job in my core by providing digital pin numbers for all pins, and advocating use of the ADC channel numbers, instead of a second layer of pin mapping. \$\endgroup\$ – Dr. Azzy Feb 14 '17 at 5:20

. Is that compiler bug?

At least three things are involved sand potentially more.

  1. Your hardware.
  2. The Arduino port to your hardware.
  3. Thee compilers.

Without ruling out the other factors, it is hard to pin the blame on thee compiler.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.