To answer a suggestion for a mode on the FGW LED controller:
The current ripple code takes up half of the code space I have on the chip. Half. That’s without fading between buttons. My attempts at making it fade made the code way to huge to be usable. But, I am open to suggestions, and to give an idea of the kind of work it takes, I figured I’d post up for everyone how the different modes work; if you can think of an algorithm to use to get your desired affect, whatever that affect may be, that doesn’t turn into a monstrous amount of codespace, I’ll do everything I can to add it to future versions, even if it means using a larger chip if there’s enough to warrant it.
The mode functions have access to these variables. This isn’t an absolute list; I actually have a good amount of RAM available, and can probably spare up to 100 bytes for additional variables if needed.
unsigned short inputs: 16 bits that hold the current state of the buttons; all eight buttons are in the lower 8 bits. If stick mode is on, bit 8 is the stick (with 1 being ‘some direction is pressed’, 0 being ‘stick in neutral’). If the extra buttons mode is on, bits 8, 9, and 10 hold the state of the buttons. All buttons are 1=button pressed, 0=button not pressed.
unsigned char scratch[11]: scratch space that can be used for any reason, and remains persistent. Any changes made during one frame remain on the next frame until you change them again. Cleared to all 0’s at power on, when screensaver activates or mode is changed in the setup menu.
unsigned char intensity[11]: the ‘output’ from the function. Each entry in the array should be between 0 and ‘brightness’, the maximum brightness value set in the setup menu. After the intensity array is filled, the chip reads it and turns each LED on long enough to achieve the desired brightness. intensity[0] should be set to the brightness wanted for button #0 (1P). Button 1 is 2P, 2 is 3P, 3 is 4P (ignored if in 6 button mode), 4 is 1K, 5 is 2K, 6 is 3K, 7 is 4K (ignored if in 6 button mode).
That’s it. To get the ripple affect, I pretty much had two parts:
First, go through the inputs, and if a button was pressed, set the scratch[button] to 255. If not pressed and scratch[button] != 0, scratch[button]–;
Then, I’d have to check each scratch[button] manually (no for loop). If scratch[button]>200, intensity[button]=brightness; If it was 200>scratch[button]>100, then set the intensity for each neighbor button to brightness. If 100>scratch[button]>50, then do it for the second further set of neighbors. This ended up being pretty much a huge manual lookup table, and did it ever take up some space.
Trying to fade between neighbors tripled the size of the code immediately. Trying to do it geometrically did too. But, I could easily be missing an elegant and small algorithm that could do it; if anyone can think of one for the ripple code, or for any display mode they might like to see, post up some C code or pseudo code to show it, and I’ll do my best.
In the mean time, who wants to guess what this is/will be?
http://img833.imageshack.us/img833/7793/kittyy.png