calvinsykes
Member
I've received an unusual Christmas present of a big bag of LEDs - my old school managed to order 1000 3mm ones when they wanted 5mm ones, and the teacher very kindly said I could have them! I thought I might have a go at building an LED cube like this one, but ideally would swap out the AVR microcontroller the author uses for a PICAXE since I'm familiar with the language and am set up to program them.
Rather than reinvent the wheel, I'd like to basically port the AVR C code provided in the instructable to BASIC. The software is built around an interrupt firing at regular intervals lighting successive 8x8 layers of the cube, at such a speed that persistence of vision makes it appear as if all the layers are lit simultaneously. The processor also calculates the animations on the fly, using a 2-dimensional array in memory as a buffer which is then read by the interrupt routine. This, along with the greater size of the cube would make this cube more computationally demanding than the ones others have posted on the forums here - the largest I found was a 5x5x5 cube, and the patterns were hardcoded in using lookup tables or similar.
So my worry is that the PICAXE might not be fast enough. The instructable says that, with the AVR clock at 14.7MHz, the interrupt fires ~10500 times per second meaning that all 8 layers are redrawn about 1300 times a second. Now if I assume that 25fps is still sufficient to get the persistence of vision effect, the interrupt rate required is 25*8=200 interrupts per second. If I ran the PICAXE at 64MHz and aimed for the 25fps refresh rate, the PICAXE could be slower than the AVR by a factor of 4 (difference in clockspeed)*52 (difference in interrupt count per second)=208 and still keep up.
[HR][/HR]
After all that, the question I'm asking is whether a 200-fold decrease in execution speed from AVR C to PICAXE BASIC is reasonable or whether the interpreted code overhead is more than this. I appreciate it's probably impossible to give a definite answer, but I'm just looking for some gut feelings before I go ahead and start designing circuits and ordering parts. Mine is that it might not be but I'm not ready to give up on the plucky PICAXE quite yet! ;-)
Cheers,
Cal
Rather than reinvent the wheel, I'd like to basically port the AVR C code provided in the instructable to BASIC. The software is built around an interrupt firing at regular intervals lighting successive 8x8 layers of the cube, at such a speed that persistence of vision makes it appear as if all the layers are lit simultaneously. The processor also calculates the animations on the fly, using a 2-dimensional array in memory as a buffer which is then read by the interrupt routine. This, along with the greater size of the cube would make this cube more computationally demanding than the ones others have posted on the forums here - the largest I found was a 5x5x5 cube, and the patterns were hardcoded in using lookup tables or similar.
So my worry is that the PICAXE might not be fast enough. The instructable says that, with the AVR clock at 14.7MHz, the interrupt fires ~10500 times per second meaning that all 8 layers are redrawn about 1300 times a second. Now if I assume that 25fps is still sufficient to get the persistence of vision effect, the interrupt rate required is 25*8=200 interrupts per second. If I ran the PICAXE at 64MHz and aimed for the 25fps refresh rate, the PICAXE could be slower than the AVR by a factor of 4 (difference in clockspeed)*52 (difference in interrupt count per second)=208 and still keep up.
[HR][/HR]
After all that, the question I'm asking is whether a 200-fold decrease in execution speed from AVR C to PICAXE BASIC is reasonable or whether the interpreted code overhead is more than this. I appreciate it's probably impossible to give a definite answer, but I'm just looking for some gut feelings before I go ahead and start designing circuits and ordering parts. Mine is that it might not be but I'm not ready to give up on the plucky PICAXE quite yet! ;-)
Cheers,
Cal