###Toggling? Or setting?
Our toggleLights function is oddly named and doesn't do what I'd expect.
In C, and especially in embedded C, we shouldn't be afraid to use unsigned integers as bit arrays.
So, perhaps we want a setLights function that looks something like this:
void setLights(uint8_t lights) {
LEDPORT = lights;
}
And to turn each of the eight lights on, one at a time, we can bitshift over them in our for loop:
for (uint8_t lights = 1; lights != 0; lights <<= 1) {
setLights(lights);
// delay
}
So now we're effectively doing what your code attempts to do, but the setLights function is even more flexible. It just sets the lights to exactly whatever we tell it to set them to (arguably, the function may not need to exist at all... but it does restrict our input to a correct type and give us some sense of safety).
I might even go so far as to create a uint8_t typedef to use as the type in our for loop and for the setLights function.
Using a uint8_t here saves us 24 bits versus int.
###lights <<= 1
<<= is a compound assignment operator. Everyone knows and is familiar with +=, correct? It's the mot common of the ten compound assignment operators.
Meanwhile, << is a bitwise left shift operator (you used it in your toggleLights function).
So here's what's happening in our for loop.
We initialize lights to 0x00000001. Run the loop body. Update statement shifts lights to the left by 1 (lights <<= 1), and we end up with: 0x00000010.
We repeat this several times until we get to 0x10000000, and the next update statement shifts all of the bits out. We end up with 0x00000000 (just 0) and the for loop exits, because lights != 0 returns false now.
###Hexidecimal vs Binary
Using hexadecimal notation is arguably more readable than counting the number of 1s in binary notation. I think I'd prefer seeing 0xFF rather than 0x1111111.
Did you even notice there are only seven ones there?