Hey Jason. Thanks very much for your comment on my post below. I mainly write this blog just for my own amusement and to show the occasional friend what I'm up to. Sometimes I do wonder if anyone else has ever actually looked at it. ;)
You raise a few interesting points I'd like to comment on so I'll just point them out, otherwise this'll turn into another massive rant:
Nine layers? Wow, well you're braver then me! :) I did at first consider doing something different, like a sphere or pyramid, but the more I looked into it, the more I realized there are some pretty good reasons why the 8 cube is so popular. Maybe most significantly eight is a "byte" and a power of 2. So is 64 and so is 512. Having 8 layers to multiplex, and 8 "blades" becomes extremely convenient when you start mucking around with the data. There's 12 TLC chips, there's 12 bits per channel, there's 16 channels per chip, there's 16 bits per SPI send, they all divide nicely into each other. A central axis does indeed sound great, but an odd number of LEDs means you'll constantly have an odd "left over" bit (or bits) to deal with.. Don't mean to scare you, I'm sure there are probably ways to deal with this, maybe without too much trouble, but it was more then I thought I'd be able to tackle.
Sometimes when I'm feeling a bit bummed out about my project, it occurs to me that If I had started a 4x4x4 RGB cube, it would almost certainly be finished by now. There will definitely be highs AND lows, so don't let that discourage you.
Multiple microcontrollers are also probably not impossible, but as you note it adds a whole layer of complexity. If you can sort out the synching issue, it might actually not be that big a deal, but you'd need to invest a bit of time just to find out. It might just be a matter of synching everything to an external clock. The slaves can "draw" the cube fast as they can, but it doesn't mean the "animations" have to be that fast. I actually think it makes more sense to keep the animations at 24-30fps or so, even if you can get your cube refresh up to 60hz - 100hz. I'm yet to decide how far I'm going to try to push the pic32.
As for moving to PIC, you might not have to! I also started my very 1st single color cube on an AVR. Back when I started the 8x8x8 project tho, there was no AVR chip that competed with the mid and higher end PICs. They had actually announced the xmega, but, let's just say, "good luck getting your hands on one of those" back then. However! That was a year go, and having a quick look at sites like http://www.evilmadscientist.com/article.php/xmega seems like they are around now! So, that's definitely an option for you. It'll be a little bit of a move from arduino, but not "that" much, I ported the acleone arduino TLC code to "straight" AVR without too much trouble, easier then to PIC that's for sure. (If you haven't seen that code yet by the way, you must have a look at it http://code.google.com/p/tlc5940arduino/ I found it a massive help and I wasn't even using arduino) Also, the avrfreaks support forum is awesome! I mean really awesome! Compared to the microchip forum.. No offence to the people on the PIC forums, I've talked to and got help from some amazing people on the PIC forums, but the format is just not as friendly for someone like me; it's quite technical, broken up into a hundred sections, fairly "formal" which is probably great for people who actually work with PICs. But the AVR forums are just amazing, more informal, only a few main sections, very "hackish", very involved, people have a great sense of humor, that's definitely the thing I miss the most about leaving AVR… Far out, reminding myself about this makes me think I probably should have looked into xmega again, before jumping into pic32! Oh well. ;)
Another thing i came across which convinced me I needed more processor power was this site http://lumisense.com/?page=eightcubed you might have seen it. For their "version 2" they actually use an intel ATOM processor, which is essentially a PC, running linux. Don't ask me how they actually interface the cube, i have no idea. :)
Cheers for the link to your site, http://www.photosbyjasonsmith.com I'll definitely keep my eye on it. Good luck with the soldering, I still remember the relief I felt when I got to the end! Put some music on while you're doing it, that really helped me through, and re-runs of Futurama. :)
Wednesday, June 9, 2010
Subscribe to:
Post Comments (Atom)
visitor counter
Hah! "Braver" probably isn't the real word you were thinking there, but thanks for being nice. :)
ReplyDeleteYeah, I did think at least a LITTLE about "8" being such a nice number in computer-land... I eventually downplayed it with "ehh, I'll just throw a few more TLC's at it and will have a few pins left over." Ignorance is bliss! I've since started to grasp the data throughput that I'm actually going to need... If my math is right, it'd be 12-bits (with TLC's) * 81 LED's * 3 colors * 9 layers * say 30fps = 787,320 bits per second. I haven't quite figured out how to translate a microcontroller's specs into throughput, but I know that approaching 1 Mbps isn't exactly trivial. I do need to sit down and try to figure out that side of things before long. My brother-in-law is an electrical engineer, so I've got him to fall back on once I've painted myself into a corner. :) I haven't mentioned it to him yet though to force myself to have to actually learn some things on my own first... Many the hard way, I'm sure!
I definitely did find Alex's TLC library. I had ordered 3 TLC's to play with and was able to easily (which is saying a lot) chain all three together and get them going. The distributor I like to use barely had enough left in stock for me to do this project, and their next shipment wasn't coming in until August or something crazy like that, so I went ahead and bought enough to cover my needs (plus a few spares if "learning the hard way" involves smoke!). So far, that's all I've somewhat obligated myself to use.
Soooo, depending on how the learning curve goes, I may wind up with a fancy 9^3 framework of LED's and just wire & address a little 3^3 cube in one of the top corners and a bunch of TLC's soldered in for decoration. Think anyone would notice? "Those LEDs? Oh, those are all just there to hold up this corner so you can see it better!" I joke, but I guess I actually could scale up that way as I try different things. Hmm....
Did you ever reconfigure for N-channel fets? Or are you thinking the microcontroller was the real culprit. I was eyeballing Dave C's LED cylinder schematics (N's with drivers) as a possible path to follow. Mainly because there aren't many others who have gotten very verbose on the detials of their high-power side of the fence.
I JUST started DVR'ing Futurama last week! I used to watch it all the time before it was cancelled. Was excited to stumble across it again the other day. Will definitely have to incorporate that into the soldering routine.
Thanks for the tips. I'll take a closer look at the xmega and try to figure out what I actually need. And the guys using the ATOM is actually a site that I had not been to yet. Was pretty sure I had seen them all (several times each) by now....
30fps is fine for an animation, but it's not good enough for a refresh rate, you need at least twice that, especially because of the multiplexing. There is only one "layer" on at any one time, so only 1/9th of the cube is actually lit at once. The aim is to get that 1 layer scanning so fast that you can't notice it's scanning at all. 30fps won't do it, even 60fps is the low end, that's what I was aiming at and you still notice the flicker. I think 100 would be ideal, but that gets hard on a big display. If only LEDs had a little bit of phosphorous like CRT screens then the refresh could be lower because the "afterglow" would fill in the gaps, if you know what I mean, that would be great! I've thought about doing this with capacitors or something but I think the fact it's all multiplexed pretty much makes it impossible, short of adding a diode and capacitor to EVERY single LED's cathodes.
ReplyDeleteSo, your actual "pattern" will be 9*9*9 *3 LEDs = 2187 "voxels", each with 12 bits = 26,244 bits is a single "frame", that's 3280.5 Bytes. If you are aiming for 60Hz, this will be over 196KB/s of data. That's KB with a big B for Bytes. This is where it starts getting a little confusing with bits and Bytes. The other thing is, when you are actually "sending" the data to the TLCs, the LEDs are neccesarily NOT lit. So each refresh (1 / 60th of a second) has a data send period and a separate "ON" period, which are mutually exclusive. So it's not enough that your controller can send 196KB/s if that send is going to take up most of that second, it won't leave any time for your LEDs to actually light up! I think this is mostly the problem I'm hoping the PIC32 will help me overcome.
As for the N Channel FETs, yes I did try them and to tell you the truth, I don't think it made a difference at all, not that I noticed. I didn't go so far as to compare them with the CRO or anything, I might get around to that, but the P channels seemed to work just as well, except without needing charge pumps or MOSFET drivers or anything like that. So I think I'm going to go back to the P design when I re-jig everything for pic32. The only difference controller wise is that the P channels use a low for on, but the N use a high for on, and that's dead easy to change in code.
The one thing which wasn't so successful was the demultiplexer idea. I tried to add in a 74hc238 to free up some pins on my pic24, but it made my outputs really weak. I only spent a little bit of time troubleshooting it, didn't work out if it was the fault of the timing, or the current throughput, or something else. Quite possibly I didn't have it configured properly, but now that I have more pins to play with I'm not going to bother with it.
The atom guys probably have the most "pro" of the cubes that I've seen, (excluding the crazy Chinese ones), but they keep their cards pretty close to their chest since they are trying to make a commercial kit out of it… I've written them several emails but they aren't very forthcoming with information, which is fair enough I suppose if they're trying to make money on the thing.. Funny thing is, I did actually enquire about getting a kit from them way back when, they said it would be around $800-$1000 when it was ready and I thought that's crazy! I'm going to do it myself! Funny thing is (or sad thing, lol) I've easily spent more then that already if you add it all up, but now I have 3 different micro programmers, a bunch of gear I didn't have before, and it's been a year full of learning and fun, so I don't regret it for a second. I have times of doubt, but not regret.. ;)
You're making my ignorance less blissful... :) Kidding.
ReplyDeleteActually, what you said about animation rate vs. scan rate totally clicked with me. I mentally had those two as being the same thing, but seeing it spelled out like that makes perfect sense. And it makes it a little more daunting. Maybe they'll have quantum computing ironed out and available in a $5 microcontroller by the time I'm done soldering. ;)
That's good to know on the mosfets. I have some P-channels that I haven't started playing with yet. I'll have to dig those out soon and see if I can breadboard that part of the circuit out w/o destroying anything.
LOL... The "crazy Chinese" cube is pretty insane. My wife is always pretty understanding when I go off on these random projects. I think she'd draw a line in the sand though if I drug something like that into the living room. ;)
I read a little more on the xmega... Atmel has a pretty sweet demo board (Xplain) for about $30US. The smaller ones on the link you originally referenced are from BostonAndroid.com and also about $30US. I've managed to get by so far w/o a programmer (been using USB via an Ardiuno board, and popping out the chip if I wanted to isolate it on a breadboard). Looks like USB programming isn't an option with the Xplain, so I'd have to pick up a programmer too. That was probably inevitable though.
You've been very generous with your time in responding here... I really appreciate it! I'll try to shut up though so you can get back to blazing trails!
Sorry, my shutting up period mentioned in the post above only lasted a couple of hours.
ReplyDeleteThe contents are probably all old knowledge for you since you ported the TLC library, but this person just released a new one and a very detailed doc to go along with it.
http://sites.google.com/site/artcfox/demystifying-the-tlc5940
I'm going to re-read it later, but after a quick skim I thought it was very cool. He has a trick starting at chapter 4, pg 22 of shifting in the next set of values while the previous set are still lit. Might reduce some flicker if I understood correctly that you were shifting dark? It is ENTIRELY possible that I misunderstood you/him/both. Appologies if so, but its still a nice read!
i hadn't seen that before! From the arduino code I was under the impression that you couldn't shift data in while the tlc's were "latched", I thought that's what "latched" meant! lol. If I'm understanding this correctly, this makes a HUGE difference! This means you can shift in the next row, while the previous row is still latched and being displayed! Dude, if this is what i think it is, it's pure gold! I'll definitely be trying to work this out on the pic.. Awesome find, i've spent over a year on this without working that out, hahaha, that's so sad i think i'm going to cry.. :D
ReplyDeleteHe just released it today. I hadn't spent much time on avrfreaks, so I was randomly poking around there checking things out (not looking for anything TLC related) and completely stumbled over it a few hours after he posted.
ReplyDeleteI was hoping I had read that right and understood what you were doing. I hope it works! I'm gonna dabble with it a little here before I turn in for the night.
It didn't take long for me to give in to the temptation. I ordered one of the xmega proto boards from bostonandroid.com this evening. :) I read on the sales sheet below that they can deliver up to 16Mbps over SPI (there's three SPI channels on the one I went with... I assume that's 16Mbps combined, but that's still pretty generous!) That doesn't mean that *I* can get that much out of it, but at least it's available. If I read right, those can be programmed over USB too, so I'm holding off on the programmer for now.
http://www.atmel.com/dyn/resources/prod_documents/doc7925.pdf
Best of luck on the TLC coding!
I've just been going through the demystifying doc and this has got me really excited again. It's going to take me a while before I'm up to speed on the pic32 but this has definitely reinvigorated my resolve! It really clicks, seems like it's really the "point" i was missing all along, just what I needed. Fantastic. :)
ReplyDelete