January 24th, 2007

animated me tinkering with leds


I had coded the main assembly for the segment driver of the random LED rail, and even simulated the hell out of it -- got rid of some bugs, and now it works pretty well. However, then I realised that the whole concept of the memory management would never work!

Back to the drawing board it is... And I think I have an idea.
Recall that I will drive ten leads from a single 16F628A, enough to charlieplex 30 RGB LEDs. Every 'light' has a few properties:
- The speed with which it travels down the rail (1 byte);
- The current 'countdown' (related to the speed) (1 byte);
- Which of the RGB LEDs is its current position (5 bits);
- Which of the colors (red, green and/or blue) are in this light (3 bits).
That makes a total of 3 bytes per light, because I can combine the LED number and the colors in a single byte. With a maximum of 30 lights, that's 90 bytes.

Then I have the physical RGB LEDs. Per LED, I need 3 bits of memory: which of its colors have to be lit -- but I'll take a byte for that, because of easier adressing and there is enough memory to go around.

What I will do, whenever a light 'cycles', is:
- Move the light to the next RGB LED;
  - If it moves to LED number 31, pass it along to the next segment, and erase it from this segment.
- Clear all memory positions for the RGB LEDs;
- For each light:
  - Take its LED number (call that L);
  - Take its color bits (call that C);
  - OR the contents of memory position L with C.

What the main loop will do:
- For each RGB LED:
  - For each color bit:
    - If it's 1, then light up that color.

I think I can code this quite compactly, and it also means I get to re-use lots of the code I already have written.