Digital Comparator with ATTiny85 doesn't behave as expected

Question

Here is my schematic:

I've removed the resistors from the LEDs to make it smaller. The 1 and 2 on the left are outputs from the arduino (which supplies the VCC and ground).

These 1 and 2 are HIGH or LOW and I want the leds to turn on according to this table:

┌───────┬────────────────────┐
│ INPUT │ OUTPUT             │
├───┬───┼──────┬──────┬──────┤
│ A │ B │ Led1 │ Led2 │ Led3 │
├───┼───┼──────┼──────┼──────┤
│ 0 │ 0 │ 1    │ 0    │ 0    │
│ 1 │ 0 │ 0    │ 1    │ 0    │
│ 0 │ 1 │ 0    │ 0    │ 1    │
│ 1 │ 1 │ 1    │ 0    │ 0    │
└───┴───┴──────┴──────┴──────┘

And this is the code I am using with the ATTiny85

const int pinA = PB3;
const int pinB = PB4;
const int pinOut1 = PB2;
const int pinOut2 = PB1;
const int pinOut3 = PB0;

void setup() {
    pinMode(pinA, INPUT);
    pinMode(pinB, INPUT);
    pinMode(pinOut1, OUTPUT);
    pinMode(pinOut2, OUTPUT);
    pinMode(pinOut3, OUTPUT);

    int a = digitalRead(pinA);
    int b = digitalRead(pinB);

    if (a == b) {
        digitalWrite(pinOut3, HIGH);
    }
    else if (a == HIGH) {
        digitalWrite(pinOut1, HIGH);
    }
    else {
        digitalWrite(pinOut2, HIGH);
    }
}

With this set up, I get this output:

┌───────┬────────────────────┐
│ INPUT │ OUTPUT             │
├───┬───┼──────┬──────┬──────┤
│ A │ B │ Led1 │ Led2 │ Led3 │
├───┼───┼──────┼──────┼──────┤
│ 0 │ 0 │ 1    │ 0    │ 0    │
│ 1 │ 0 │ 0    │ 1    │ 0    │
│ 0 │ 1 │ 1    │ 0    │ 0    │ <- See the difference
│ 1 │ 1 │ 1    │ 0    │ 0    │
└───┴───┴──────┴──────┴──────┘

I think it has something to do with the fact that the ATTiny gets powered on if you supply 5v to one of the input pins too and not to VCC.

And yes, I keep restarting the board (by pulling out the VCC pin and seeing the led turn off).

I've also tried connecting A and B to VCC and ground both in all possible positions. Here I noticed that connecting A (or B) to 5v (of the arduino) while VCC is not connected, the board will turn on.

I hope this is enough info.

Answer 1

You have to assign the status of all output pins in each of your "if statement" conditions. Think of it like 'if that happens, I want x, y, & z to be ON, and a, b, & c to be Off'. Unchanging the HIGH status of one output will remain that output HIGH for all conditions. Output pins never change their statuses untill they have an order "your code" to do this. Also you have to replace your code inside a loop function to repeat your code without the need to manually reset your ATTiny.

Assuming LED1 = pinOut1, LED2 = pinOut2, LED3 = pinOut3. You have to replace "if conditions" in your code by the following:

while( 1 ){
    int a = digitalRead(PinA);
    int b = digitalRead(PinB);

    if ( a == b ) {
        digitalwrite (pinOut1 , HIGH);
        digitalwrite(pinOut2,LOW) ;
        digitalwrite (pinOut3, LOW);
    }
    else if ( a == HIGH ) {
        digitalwrite(pinOut2,HIGH) ;
        digitalwrite(pinOut1,LOW) ;
        digitalwrite(pinOut3,LOW);
    }
    else if ( b == HIGH ) {
        digitalwrite(pinOut3,HIGH) ;
        digitalwrite(pinOut1,LOW) ;
    digitalwrite(pinOut2,LOW);
    }
}

Also according to your application speed requirements, you can add a delay of about 300 ms before reading your digital inputs to allow the user to change the status of these digital inputs.

Answer 2

I see nothing wrong in your code, except a terrible design decision that forces you to reset the ATtiny every time you want to change its inputs. I guess, then, that the problem is in the way you use it. For example, let's say you are testing the lines of the table one by one. Once you are done with the second line and decide to move to the third, let's say that you:

1. power-cycle the ATtiny
2. set its A input to LOW
3. set its B input to HIGH.

The ATtiny could very well be reading its inputs right between the steps 2 and 3 above. It would then see both inputs LOW and do what it is supposed to do in that case. This is called a race condition, and usually leads to bugs that are very hard to find.

The right way to use this particular program is to never remove the power and:

1. set the new inputs
2. pulse the RESET pin of the ATtiny LOW for a few microseconds.

Of course, it would be way better to have a sensible design that doesn't force you to reset. C.f. Ahmed M.Zahran's answer. For this kind of trivial problem (just a truth table implementation) I prefer to implement the solution in plain C:

#include <avr/io.h>

static const uint8_t truth_table[] = {1, 2, 4, 1};

int main(void)
{
    DDRB = 0x7;  // PB0..PB2 as outputs
    for (;;) {
        uint8_t input = (PINB >> 3) & 0x3;  // the 2 input bits
        PORTB = truth_table[input];  // send output to the LEDs
    }
}

If you are worried about power, put the ATtiny to sleep and wake it up on a pin change interrupt. But be sure to have the simple version working first, before you worry about power saving and sleep modes.

Answer 3

I think it has something to do with the fact that the ATTiny gets powered on if you supply 5v to one of the input pins too and not to VCC.

And yes, I keep restarting the board (by pulling out the VCC pin and seeing the led turn off).

Here I noticed that connecting A (or B) to 5v (of the arduino) while VCC is not connected, the board will turn on.

All of the above is roughly translated into "I am frying my chip and don't know why it does not work".

Look at "absolute maximum ratings" in datasheet:

"Voltage on any Pin except RESET with respect to Ground -0.5V to VCC+0.5V"

In short, you need to power MCU up before applying voltage to input pins. That is why it is so surprising that you do not have a loop in your main().