Arduino Register C and analog inputs

Using Arduino Microcontrollers
#1

I just checked out the arduino pinouts for Atmega328 and found that the register C on the microcontroller is used for analog inputs. So what if I want to use them as digital pins. Can I just mention that using pinMode and then start using the pins as digital pins?? Or should I make some appropriate changes to the fuse bits as I have heard that the behaviour of various pins of a microcontroller can be adjusted using fuse bits like deciding whether the pin is a digital I/O pin or the reset pin.

#2

They work perfectly as digital pins.

Use "A0" ... "A5" in pinMode() and digitalWrite().

#3

Or use pin numbers 14' to 19

#4

Grumpy_Mike:
Or use pin numbers 14’ to 19

So long as you don’t mind doing a calculation in your head every time you look at the code.

“pinMode(A3,OUTPUT)” is a lot clearer than “pinMode(17,OUTPUT)”

#5

or just use a descriptive name:

byte controlLamp = 14; // or similar

pinMode (controlLamp, OUTPUT);

digitalWrite (controlLamp, HIGH);

vs "What's A0/14 used for again?"

#6

While we're debating preferences, I would use:

#define PIN_BIGREDBUTTON  15
#define PIN_BIGGREENBUTTON  A1

... as it does not allocate a byte (or two, in the case of int) to what is essentially a placeholder. All substitutions are at compile-time, and essentially free.

#7

or
const byte PIN_BIGREDBUTTON 15
const byte PIN_BIGGREENBUTTON A1

(not sure if = & ; systax are needed for these, I just use byte myself)

#8

Huh. Are those optimized away by the compiler?

#9 
const byte PIN_BIGREDBUTTON  = 15;
const byte PIN_BIGGREENBUTTON  = A1;

Huh. Are those optimized away by the compiler?

Yes. The AVR-GCC compiler does an excellent job of optimizing compile-time constants.

#10

As long as your const is not an array being accessed by a non-compile-time-constant-index, then yes, GCC will optimise them away.

Take this completely nonsense code for example:

const byte bob = 10; //optimised away
const byte bill[4] = {2,5,12,8}; //optimised away
const byte ben[4] = {3,6,32,64}; //NOT optimised away

byte fred = bill[3];
fred += bill[2];
fred *= bill[0];
fred /= bill[1];
byte joe = PORTD & 0x2;
joe = ben[joe]; //ben can't be optimised away because joe is not know at compile time
#11

Interesting. I know some people prefer to use variables (as opposed to #defines) because they'll have a respective symbol that can be caught through debuggers and possibly some traces in the disassembly, so I wasn't aware they were purposefully optimized away at compile time. Although, it's similar to how (for e.g.) using the AVR-lib delay functions, if your parameter can be calculated at compile time, you avoid bringing in the floating point libraries for the delay vs. F_CPU calculations.... so it makes sense. :slight_smile:

#12

SirNickity:
I know some people prefer to use variables (as opposed to #defines)...

The biggest advantage of using const instead of #define is scoping...

void loop( void )
{
  const byte IAmOnlyVisibleInLoop = 13;

  digitalWrite( IAmOnlyVisibleInLoop, ! digitalRead( IAmOnlyVisibleInLoop ) );
  delay( 1000 );
}

namespace Pins
{
  const uint8_t SCK = 2;
};

void setup( void )
{
  pinMode( Pins::SCK, OUTPUT );
}

#define is always module (file) scope which can easily lead to conflicts (sometimes very difficult to troubleshoot conflicts).

#13

Thanks to all who showed interest in replying.....

#14