Probably really basic problem... but...

So I was using the pwm pins for input and I looped through them

Using something like
for(int i=1;i<7;i++)
{
if (digitalRead(i+1) == LOW) {FireTrigger(i+1);}
}

But now I’ve switched to analogue inputs and I can’t do this loop anymore so I need to explicitly read each one…

if (analogRead(A0) > 100) {FireTrigger(1);}
if (analogRead(A1) > 100) {FireTrigger(2);}
if (analogRead(A2) > 100) {FireTrigger(3);}
if (analogRead(A3) > 100) {FireTrigger(4);}
if (analogRead(A4) > 100) {FireTrigger(5);}
if (analogRead(A5) > 100) {FireTrigger(6);}

Is there a way round this so I can go back to my loop?

Cheers, Rob

Put the analogue pin numbers into an array, and iterate over the array with your for loop

lol, I was literally just posting this when the forum told me someone else had posted!!

int ar[6] = {analogRead(A0),analogRead(A1),analogRead(A2),analogRead(A3),analogRead(A4),analogRead(A5)};

So I read all 6 of my analog inputs into an array which allows me to just loop over the array...

If anyone has a better suggestion I'm all ears!!

Or you could simply write your for loop to iterate from A0 to A5 inclusive.

Or iterate from 0 to 5 and offset the pin number by A0.

But I prefer the array of pin numbers

This won't work:

int ar[6] = {analogRead(A0),analogRead(A1),analogRead(A2),analogRead(A3),analogRead(A4),analogRead(A5)};

First, because the analogRead() calls only happen at initialization. Second, because a call to analogRead() may not work during initialization. Put the Pin Numbers in the array per @AWOL's advice. And, make the array of type 'uint8_t' instead of 'int'. No reason to use an extra six bytes of memory if you don't need to. And, declare the array 'const' because your program should never change them.

Hi gfvalvo,

So it works perfectly! However, what you're saying is interesting. I've assumed that I need to do an analog read every time I want to listen to a sensor. Are you saying I can just declare this once and the array will magically update itself without me needing to ask again?

I'm going to need to try this!

But it's 22:50 at night and I'm going to bed!

Nothing is magic. There is no free lunch - you need to do a read every time you want a new reading.

That's what I thought!

This won’t work:

int ar[6] = {analogRead(A0),analogRead(A1),analogRead(A2),analogRead(A3),analogRead(A4),analogRead(A5)};

First, because the analogRead() calls only happen at initialization.

That WILL work, if ar is a local variable. It won’t if ar is global.

Since OP says it does work, I have to assume that ar is local.

@OP: It would be nice not to have to assume anything.

RobFarley:
But now I’ve switched to analogue inputs and I can’t do this loop anymore so I need to explicitly read each one…

You can use the pins A0 to A5 with digitalRead() and digitalWrite().

And maths such as

for(int i = 0; i < 5; i ++)
  {
    if (digitalRead(i + A0) == LOW)   {
          FireTrigger(i + A0);
    }
}

A0 just translates to a number. It is 14 on an Uno.

…R

Sorry, yes it's a local variable within a function

RobFarley:
So I was using the pwm pins for input and I looped through them

Using something like
for(int i=1;i<7;i++)
{
if (digitalRead(i+1) == LOW) {FireTrigger(i+1);}
}

But now I’ve switched to analogue inputs and I can’t do this loop anymore so I need to explicitly read each one…

if (analogRead(A0) > 100) {FireTrigger(1);}
if (analogRead(A1) > 100) {FireTrigger(2);}
if (analogRead(A2) > 100) {FireTrigger(3);}
if (analogRead(A3) > 100) {FireTrigger(4);}
if (analogRead(A4) > 100) {FireTrigger(5);}
if (analogRead(A5) > 100) {FireTrigger(6);}

Is there a way round this so I can go back to my loop?

Cheers, Rob

The analog pin names are just aliases for numbers.

for( int i=A0; i<A5; ++i )

RobFarley:
Hi gfvalvo,

So it works perfectly! However, what you’re saying is interesting. I’ve assumed that I need to do an analog read every time I want to listen to a sensor. Are you saying I can just declare this once and the array will magically update itself without me needing to ask again?

I’m going to need to try this!

But it’s 22:50 at night and I’m going to bed!

It is possible to do something like this, but it requires creating a custom class that performs a fresh analogRead every time it is accessed. You can’t do it just by throwing the analogReads into an array like you did.

Look at the EERef implementation in Arduino’s EEPROM.h for some guidance to creating a class like that.

for( int i=A0; i<=A5; ++i )

I already suggested this back in reply #3

You can’t do it just by throwing the analogReads into an array like you did.

Why not, if the array is local?

for( int i=A0; i<A5; ++i )

The above is making the implicit assumption that A0-A5 are, and will always be_,_ defined as a series of consecutive numbers, in increasing order. Is that really guaranteed to be the case for ALL hardware?

Regards,
Ray L.

Thanks everyone, I quite like the array way of doing it, feels quite clean, and indeed works perfectly.

AWOL:
Why not, if the array is local?

I was specifically addressing the "this once and the array will magically update itself " part of the quoted post. It is possible to create something like that, but not with the just the functions that the Arduino core provides. You need to create a new class to provide that functionality.

RayLivingston:

for( int i=A0; i<A5; ++i )

The above is making the implicit assumption that A0-A5 are, and will always be_,_ defined as a series of consecutive numbers, in increasing order. Is that really guaranteed to be the case for ALL hardware?

Regards,
Ray L.

This is a very good point. Thank you for bringing it up.

We make the same assumption about digital pins.

AWOL: We make the same assumption about digital pins.

Digital pins are referenced by actual numbers: 0-n. You KNOW whether or not the pins you care about are sequentially, and contiguously, numbered or not. Analog pins are referenced by symbols: A0-An. Unless you look at how those symbols are defined in the bowels of the board support packages, you have no idea whether or not they evaluate to sequential numeric values. Perhaps there is an established convention that they will do so, I have no idea, as I have not looked at exactly how they are defined and used in the Arduino libraries. But I would not assume they do, without, at a minimum, checking that they do so on the specific board I am targeting.

Regards, Ray L.

RayLivingston:
Digital pins are referenced by actual numbers: 0-n.

You KNOW that’s not the whole truth.

You’ve got digitalRead/digitalWrite to do the donkey work for you.

There is NOTHING to stop me using 0…5 to refer to the analogue input pins, and anyway, the Ax mappings are relatively recent.

I would expect this state of affairs to continue, and if a particular platform breaks the convention, then I will fix it.

AWOL: There is NOTHING to stop me using 0..5 to refer to the analogue input pins, and anyway, the Ax mappings are relatively recent.

Perhaps YOU know that, I most certainly do not. There is not a reason in the world that HAS to be true. The convention is to use the symbols A0-An, and without looking at how those are defined, there is absolutely no way for me, or anyone else, to know it is ok to instead use 0-n. And there is certainly no reason for me, or anyone else, to believe that will ALWAYS be the case, unless it is spelled out somewhere in the specs of the board support package architecture. Even if I looked at saw that for, say, the Uno, there was such a 1:1 mapping, that would not convince me to use straight numeric values, as it will not necessarily be true for, say, a Due, or Zero, or ESP.

The whole point is, making assumptions can get you into trouble, unless you ensure those assumptions are valid.

Regards, Ray L.