Another Pin 0 issue

I have a circuit using an ATMega328 on it's own, so I don't have the default stuff like you'd find on an Uno. I am programming the chip separately and socketing it into the circuit, so I am using digital pins 0 and 1 (and 5 more) as outputs into a transistor array to drive LEDs. I wrote a quickie test to make sure this portion of my circuit works.

const int ZERO = 0;
const int ONE = 1;
//continues through SIX

void setup() {
  pinMode(OUTPUT,0);
  pinMode(OUTPUT,1);
//continues through SIX

}

void loop() {
  digitalWrite(ZERO, HIGH);
  delay(500);
  digitalWrite(ONE, HIGH);
  delay(500);
//continues through SIX
  digitalWrite(ZERO, LOW);
  delay(500);
  digitalWrite(ONE, LOW);
  delay(500);
//continues through SIX
}

LEDs ONE through SIX behave accordingly, lighting in sequence and then turning off in sequence. the LED attached to ZERO stays high (illuminated) the entire time.

Electrically, the array checks out, and I don't have a good way to check that pin 0 is outputting accordingly. Am I missing something in software? At this point, changing hardware isn't exactly feasible.

Upload your code with the ISP method.

This will remove all extraneous boot-loading code items.

pinMode(OUTPUT,0);
pinMode(OUTPUT,1);

pinMode() arguments are pin,mode.

So those should be

pinMode(0,OUTPUT);
pinMode(1,OUTPUT);

The reason that pin 1 works and pin0 doesn't is that INPUT, OUTPUT, and INPUT_PULLUP are just #defines provided by the core - of values 0, 1, and 2 respectively... so your code:

pinMode(OUTPUT,0);
pinMode(OUTPUT,1);

resolves to
pinMode(1,0);
pinMode(1,1);

which is the same as

pinMode(1,INPUT);
pinMode(1,OUTPUT);

As for why pin0 is staying on... Do you have it connected to a serial adapter? The serial adapter's TX pin will be connected to pin 0 (RX). An idle serial pin is held HIGH. If there is a series resistor in the serial line (this is common, but NOT universal), then setting the pin as output will work, as it will overpower the series resistor (which is probably 1k or 2.2k) and drive the pin low. If there is no series resistor, they'll fight eachother, which could damage the '328p, serial adapter, or both.

If as your comments imply, you've taken it all the way to 6 pins, and it's working, that's because digitalWrite(pin,1) on a pin set INPUT (which all your pins except pin 1 would be) will turn on the pullup, and you're using either MOSFETs or BJT's with light enough load and high enough beta that this is sufficient to turn them on....

Don't understand why you wouldn't leave Pins 0 and 1 as their default UART I/O functions. It's very help sometimes to have a serial debug port in an embedded application.

DrAzzy:
pinMode(OUTPUT,0);
pinMode(OUTPUT,1);

pinMode() arguments are pin,mode.

So those should be

pinMode(0,OUTPUT);
pinMode(1,OUTPUT);

Yep, I'm an idiot. That fixed it easily; not sure why I messed it up. I know the order of operations. I blame it on wanting to get lunch.

Thanks, DrAzzy.

gfvalvo:
Don't understand why you wouldn't leave Pins 0 and 1 as their default UART I/O functions. It's very help sometimes to have a serial debug port in an embedded application.

I normally would, but I need the extra IO for the rest of the circuit.

Prop-Forge:
I normally would, but I need the extra IO for the rest of the circuit.

Guess it's a design choice. I've been doing embedded development for long enough that I'll slap down a SPI or I2C I/O expander before I'll give up the one and only serial debug port.