18/04/2009 So yes it is a pipe dream, but one day i would love to make an 8x8x8 RGB cube. So the things I'm currently working on are partly decided by: is this somehow bringing me closer to the 8 cube. Not necessarily is it going to be actually in the 8 cube, but am i at least learning something useful. Since trying to even understand and scope not just what I'll physically need, but also what skills i'll need, it's dawning on me just how massive a project this is! I'm at the moment, i'm trying to work out how I would even address so many individual LEDs, because it's not just 512 LEDs to address, each one has 3 values, R, G and B, making a grand total of 1536 addresses. The best example I've been able to find so far of a working open source example is the fantastic work by Dave Clausen http://dclausen.net/projects/ledcyl/ RGB LED cylinder. His 95 LED RGB cylinder runs on an ATMEGA168, which is very similar to the ATMEGA16 which I've been working on, in fact, he runs the 168 which is capable of 20MHz at only 16MHz, so i "think" you could just swap a ATMEGA16 in without too much fuss.. I have not been able to find any open source examples of larger cubes or any larger RGB projects, so i'll be trying to learn as much as I can from this one. Along with the uC, he has 4 x 16 channel texas instrument LED drivers. These are impossible to source in Australia, i've found them from farnell, but they're $8 a pop which isn't too bad for 4, but if I use the standard multiplex for 8x8x8, i'll need 192 channels, that's 12 chips and almost $100 just in drivers! After a lot of searching around i managed to find some cheaper LED drivers online in Australia. They appear similar to the one in the cylinder project in as much as they are 16 channel constant currant drivers, but they do not use standard SPI so i'll need to work out how to communicate to them by myself.. Which brings me to the current problem, bandwidth! Dave's driver chips have 12bit resolution per channel, the ones I bought are only 10bit, that's still 1024 levels of brightness!! I mean wow! I was hoping for 8 bits, through 3 channels that's still millions of colors! But anyway, 10 bits it is. However this may be more of a curse then a blessing, since the ATMEGA is an 8bit processor, i think that means it takes 2 "writes" to send 10 bits, which is a pity! The LED Cylinder has 95 lights which is 285 separate channels, that's just over 420 kilobytes, the 8x8x8 needs 1536 "addresses"!, and 10 bits per address is over 1.9 kilo BYTES, JUST for a "frame". Even 8 bits per address is 1.5kB, the ATMEGA only has 1kB of SRAM! So this is a bit of a stumbling block at the moment. I imagined i'd have the program just pumping values into an array and an interrupt routine drawing the array onto the cube, a layer at a time, sort of like the 4x4x4 cube, but that's not going to work in this case. But perhaps I could somehow use a static look up table instead, there's enough ROM there to keep a 1.9kB table, then I only call 1 layer at a time,, but then, the layers still have to somehow remember "where they were at"... So that's what I have to figure out next. This is a very preliminary idea of what i think my cube might look like. There are 3 times 16 channel drivers per "4x4x8" segment, 12 total for the 192 channels required for one layer. I can have 6 pins from the uC driving 2 driver chips in series that way they only need to send 32 bits per frame. The driver chips require 4 or 5 more pins for command and clock which is shared. The multiplexing has been left out of this drawing, that will require a whole 8 pin port dedicated to layer select. that leaves me with a port, which is good if I one day decide to add a PC serial port. Well! Fortunately i'm not shy about asking the n00b questions on the avrfreaks forums, and fortunately the people there aren't shy about telling it how it is! So far i've only looked at the AVRs available from futurlec, which is where i've been buying them from! Little did i know that there are several AVRs which futurlec do not sell! Including the atmega1281! WIth: dum, dum ,dummmm: 8kB RAM! This should be plenty of memory to have a full frame and a full frame buffer.> The flip side, i just made my $8 micro requirement into a $30 micro requirement! If I was designing thins thing for mass production i would probably think very long and hard before making this decision, but it's a one off, so i don't care.. The SMALL problem this has created is: the atmega1281 is a TQFP package, that's surface mounted, for those who still don't know what i'm talking about, it's REALLY small! In fact, I think i've underestimated how small, since yesterday the LED drivers i'm planning to use just arrived, and they are surface mounted too. Check this out: |


