The groovik’s cube project is coming along well. Chris, Brian, Barry, and I spent a couple hours discussing the software yesterday. We reviewed all of the existing code, talked about each module’s constraints and expectations, and kicked around ideas about how we might solve problems we think we might encounter. It’s in pretty good shape: we have working prototypes for every component, and the system works when we plug all the components together.
I’m not sure how many hours I spent on the dimmer code this weekend, but it felt like a lot. I’m on my fourth rewrite; I’ve figured out how to set up an interrupt-driven timer, and how to do fast writes by updating the IO registers. This is an enormously compelling project, constantly tickling those learning-driven pleasure centers in my brain. This problem is really all about timing, and the precision thereof; in order to render the full range of 24-bit color without flickering, the dimmer code has to be able to emit a light pulse of exactly one-eighth of a microsecond. This is at least theoretically possible with the 16 MHz microcontrollers we are using, but it is going to require some extremely tight code. I have not had to think about performance at this level of detail in years, over a decade at least; it’s kind of a guilty pleasure, and I am thoroughly enjoying the opportunity.
I know I must be missing something here, but let’s say you’re using pulse width modulation, perhaps going for 60 Hz update rate to avoid flickering — then for 8 bits (each color channel) RGB I calculate the shortest pulse width you’ll need to be: (1/256)(1/60) = 1/15 millisecond. This is 500 times longer than your estimate. What am I missing?
— Geoff
Comment by Geoff — June 1, 2009 @ 1:43 pm
The relationship between power and perceptual brightness is logarithmic, so a linear mapping to PWM duty cycle would yield very large steps between levels at one end of the scale and very small steps at the other. Typical exponent is 2.2; I’m approximating this as 2, so we square the brightness. 255*255 = 65025, so we need 16-bit precision; fudge this to 65536, run the cycle at 128 Hz, and you get eight ticks per microsecond, which is two processor cycles on a 16 MHz machine.
60 hz would work, but it’s still really easy to see PoV effects. I am more worried about flicker than aliasing, since the cube will spend most of its time displaying a few static colors, so I would rather drop bits of timing precision in order to keep the refresh rate high. In the end, though, I think we’ll be able to have both.
Comment by mars — June 1, 2009 @ 3:25 pm