Which pins to use?

Projects Programming
1

I found out the hard way the some pins are not quite identical to others. I thought I had all the information I needed but found out during testing that some pins are to be avoided for certain operations. I hope it is ok to ask for advice here.

For a project I will be using a nano, to be mounted on a dedicated pcb.

I was using D13 for the TSOP4838 (works fine on an uno) but it does not work on the nano. Changing the software definition (and connection) to D3 fixed the problem.
I am using D4, D5, D6 for 74HC595 #1, D7, D8, D9 for 74HC595 #2 and D10, D11, D12 for 74HC595 #3. For some reason bit 1 of the 74HC595 #3 will not work (pcb is tested and the trace is correct). Perhaps I should have avoided D10, D11 or D12?

The best solution is probably to design a new pcb. In order to do that I need to make sure I use pins in the right way. The required pins are:
:
9 for 3 x 74HC595's (they cannot be linked sequentially but have to be under individual control)
2 for I2C
1 for TSOP4838 IR decoder
2 for relay switching
4 for 2 x rotary encoder (A and B)
.
Note that all the 2 relay pins and the 74HC595 output are connected to ULN2803's or discrete transistors to perform the actual relay switching.

Your help is appreciated.

2

It really depends on how you use the pins. Understand that the IDE (in the background) configures many of the pins for functions that are assumed to be in the users' best interest (PWM, etc.) and may have ties to timers that are in conflict with what you are trying to do. Difficult to say for sure without seeing your code, but you should check it out.

9 for 3 x 74HC595's (they cannot be linked sequentially but have to be under individual control)

I have some difficulty with this statement as I often use multiple 595s from a single set of control pins and have no difficulty in dealing with each separately. Sure you have to be a bit creative with the code, but isn't that what this is all about? At the least you can still pump the data out a single pin using a single clk and simply have separate pins for each of the latches. Presumably when you are latching a 595 you've already queued the data and if you're not latching, who cares what state the input is.

3

Look at the schematics of the uno and the nano. The uno uses a buffer to drive the on-board led, the nano does not (if memory serves me well).

4

In general all of the digital pins of an Arduino board have the same functionality with the possible exception of pin 13 which is connected to the on board LED. Don't forget that you can use A0 to A6 as digital pins, but not A7 or A8 on the Nano.

Some pins have special purposes but if you are not using SPI or I2C then that is of no concern.

5

The connections mentioned above are all that are required, so I2C is used but SPI is not.

Yes, I am aware I could cascade the 3 x 74HC595's, but would prefer to use 3 pins per 74HC595 (3 x SER, 3 x RCLK and 3 x SRCLK; total 9 pins) if I can avoid it. If there are enough pins it is something less to worry about :slight_smile:

The only libraries I am using are IRremote, wire and Liquidcrystal_I2C.

I understand that using D10, D11 and D12 for a 74HC595 should not be a problem?

6

Nothing that you've said should be a problem. It's what you haven't said (or shown) that's causing the trouble.

7

Thanks. I have confirmed that D10, D11 and D12 work as intended. The problem is caused by something else and I will ask a question in the appropriate section of the forum.

8

In general all of the digital pins of an Arduino board have the same functionality with the possible exception of pin 13 which is connected to the on board LED. Don't forget that you can use A0 to A6 as digital pins, but not A7 or A8 on the Nano.

Some pins have special purposes but if you are not using SPI or I2C then that is of no concern.

--- In general yeah. But many of pins are part of timer groups, etc, which a full scale pinout diagram will reveal. In most examples you'll know those pitfalls before you encounter them as it requires pretty advanced functions.

9

Problem solved. Reminded me of days gone by, when you would try to find an error in your software (even though you were sure everything was ok). After many hours or days of searching in the code and not finding anything you changed the code anyway, against better judgement, just in case you had missed something. 9 times out of 10 it turned out the software was fine all along but there was an error in the hardware.

Similar problem here. New program. New pcb. New nano, New everything. Many variables. It turned out to be the nano!
As it was the first nano I ever used and some of the nano's functions worked fine, it was difficult to pinpoint the source. Until I ran this test:

  • NOTHING connected to any of the nano pins, expect scope probe on 5V and GND
  • Amperemeter in USB connection to PC to monitor current drawn
  • Ran simple testprogram (see below)

If pins 4, 5 and 6 were used as output (changed by 3 #defines in the beginning of the code), everything was fine.
If pins 7, 8 and 9 were used, everything was fine.
If pins 10, 11 and 12 were used (as in the example below), voltage would drop a bit and current drawn tripled. This would cycle (current back to normal for a bit, only to go to high value again, etc.).

After replacing the nano, the problem was solved.

//Test program to turn leds connected to a 74HC595 sequentially on

// Setup pins for 74HC595 U1 
#define U1_SER 10
#define U1_RCLK 11  
#define U1_SRCLK 12

void setup()
{
  // configure pins for U1
  pinMode(U1_SER, OUTPUT);
  pinMode(U1_RCLK, OUTPUT);
  pinMode(U1_SRCLK, OUTPUT);

  // Switch off Led's U1
  digitalWrite(U1_RCLK, LOW);
  shiftOut(U1_SER, U1_SRCLK, LSBFIRST, B00000000);  
  digitalWrite(U1_RCLK, HIGH);
}

void loop()
{
  int i;
  byte todisp[8] = {B00000001, B00000010, B00000100, B00001000, B00010000, B00100000, B01000000, B10000000};
  
  for (i=0; i<8; i++) 
  {
    digitalWrite(U1_RCLK, LOW);
    digitalWrite(U1_SRCLK, LOW);
    shiftOut(U1_SER, U1_SRCLK, LSBFIRST, todisp[i]);  
    digitalWrite(U1_RCLK, HIGH);
    delay(1000);
  }
  delay(500);
 
}