Are simultaneous for loops possible?

Using 2560 - I'm firing LEDs 2-42 in chase sequence using a for loop. Working fine.

I now want the LEDS to chase in two directions at the same time starting with 22.
X=22
y=22
x=x+1 //count up
y=y-1 //count down

This would have to be a simultaneous for loop.
That's not possible correct?

This is more of a metal exercise to see if it can be done.
I'm assuming the better way is to use an array? Or can this me done with an array?

Or maybe I can do it with a loop.

Code is incomplete, but would my logic work?

for (byte z = 0; z<22 z=z+1){

digitalWrite(x+z, HIGH); //Can I do math in a digitalwrite?
digitalWrite(y-z, HIGH);

delay (20);

digitalWrite(x+z, Low);
digitalWrite(y-z, Low);

}

If I can not do math within a digitalwrite statement I guess I would have to use additional variables and an addition/subtractions line.

ledUP = x + z;
ledDN = y - z;

digitialWrite(ledUP, HIGH);
digitialWrite(ledDN, HIGH);

Would all of this be easier with an array?

for (byte z = 0; z<22 z=z+1){
  digitalWrite(x+z, HIGH);  //Can I do math in a digitalwrite?
  digitalWrite(y-z, HIGH);
  delay (20);
  digitalWrite(x+z, Low);
  digitalWrite(y-z, Low);
}

something like that that should work fine. You can also use other kinds of loops:
(yes, you can do math inside the parameter list of any function call)

x = y = 22;
while (x > 0) {
  digitalWrite(x, HIGH);
  digitalWrite(y, HIGH);
  delay (20);
  digitalWrite(x, Low);
  digitalWrite(y, Low);
  x++;
  y--;
}

You can also do things like:

for (int i=0, j=22; i<22 && j > 0; i++, j--)
{
}

Regards,
Ray L.

RayLivingston:
You can also do things like:

for (int i=0, j=22; i<22 && j > 0; i++, j--)

{
}

Regards,
Ray L.

Of course.... A logical AND Brilliant.

for (int i=0, j=22; i<22 && j > 0; i++, j--)

Of course.... A logical AND Brilliant.

Meh. Needlessly obscure, with no actual advantages.
I actually like the OP's original code (x+z, y-z) best, among the various suggestions.

westfw:
Meh. Needlessly obscure, with no actual advantages.
I actually like the OP's original code (x+z, y-z) best, among the various suggestions.

I liked the challenge of getting that to work. I really think the && method was brilliant.

Can I ask you to look at my code so far? I'm trying to switch from delay to milli and I'm stuck.

I understand the logic of the milli code, just having a hard time understanding how to apply it to my application. I am so close, but just not seeing it.

http://forum.arduino.cc/index.php?topic=549037.new#new

I liked the challenge of getting that to work.

Fair enough. I didn't notice that you WERE the original poster - good work figuring it out.
But from now on, avoid the comma operator!
Remember that you have a compiler working for you, and it will optimize multiple different expressions of an idea into approximately the same actual code; there's (probably) no performance advantage to a "challenging" one-line presentation, and you should usually pick the expression that is easiest to read (for you AND for other people.)

I really think the && method was brilliant.

It shouldn't be necessary, and you might find it especially difficult to debug. If both conditions don't happen at the same time, and your counts are symbolic. Um. Shouldn't one of those 22's be a 42?

IMHO it is ALWAYS best to write code for clarity rather then fewer keystrokes.

My aim is to write code that I can understand 6 months later after a single read-through - of course I don't always succeed.

...R

Robin2:
IMHO it is ALWAYS best to write code for clarity rather then fewer keystrokes.

My aim is to write code that I can understand 6 months later after a single read-through - of course I don't always succeed.

...R

Any reason for not writing tight code and document what the code's doing? In my code, (and I'm using this as a teaching tool) I was able to eliminate over 100 lines of code with just 6 lines of code. The new more compact code is far easer to read.

Anoter reason for leaning to create efficient code is it saves memory. One day you might be working on a project where you run out of room. And only if that code was a little more efficiently wrttien it woudl fit.

But maybe I was taugh old school.

westfw:
Fair enough. I didn't notice that you WERE the original poster - good work figuring it out.
But from now on, avoid the comma operator!
Remember that you have a compiler working for you, and it will optimize multiple different expressions of an idea into approximately the same actual code; there's (probably) no performance advantage to a "challenging" one-line presentation, and you should usually pick the expression that is easiest to read (for you AND for other people.)

It shouldn't be necessary, and you might find it especially difficult to debug. If both conditions don't happen at the same time, and your counts are symbolic. Um. Shouldn't one of those 22's be a 42?

Thanks.

I agree with yout the && can cause debuging issues. But still it's very clever.
I'm going to go with the z +y -y logic. Simple, and easy.

I'm not sure which 22 you mean. The way I built the game,. and this was by design.... LED 21 the win LED and is in the middle of the series. So if one hit's the win LEDs will start at 21 and -1 +1 around. to 2 dn 42.

Still need to know how to exit a the for loop. Goto/Break/Jump?

Doug101:
In my code, (and I'm using this as a teaching tool) I was able to eliminate over 100 lines of code with just 6 lines of code. The new more compact code is far easer to read.

It’s all about trade-offs and balance. If you can replace 100 lines of code with 6, chances are it was pretty crappy code to begin with.

Doug101:
The new more compact code is far easer to read.

Then it meets my criterion.

Anoter reason for leaning to create efficient code is it saves memory.

Efficient code does not mean that it must be unreadable. For example long meaningful variable and function names do not affect efficiency.

...R