Ubergeek63,
Looks like Nrets has 35 IO pins available so the # of pins shouldn't be an issue. You still may need resistors with the 74ABT574A where as the TLC5917 has constant current outputs which are programmable. The 74ABT574A will be cheaper and probably easier to get.
Nrets,
The shift register is not for multiplexing. It simply gives you parallel outputs from a serial IO interface thus saving MCU pins.
Yes, it should be fast enough for that. You'd only need 8 TLC5917s for 64 LEDs. You may also be able to use the PIC's hardware SPI to do this with less CPU overhead.I understand now. So I could theoretically use 9 (9*7 + 1=64) TLC5917's in a series to drive 64 LEDs? Is a 20MHz processor fast enough to do this in 0.04 ms?
No. Those shift registers all have latches (8 bits of memory) so they will hold their last state while shifting the new data in. ie: Toggling the RCLK on the 74LV595 latches the data in the shift register to the outputs and updates all 8 LEDs at once. LE(ED1) on the TLC5917.Nrets said:While the shift registers are being filled with new data, I imagine I would have to have the LEDs off, otherwise the shifting would be visible.
This would make a software bitbang faster by 8x. 8 SER, 1 SRCLK and 1 RCLK lines will drive 8 74LV595s.Nrets said:I could also group the LEDs in 8's, and use 10 pins (8 outputs, 1 clock, 1 clear) to send the data and 1 to ground the LEDs. I imagine this would be more practical.
True, I had missed the direct drive. He is still trying to drive twice as many LEDs than he has port pins available though.Ubergeek63,
Looks like Nrets has 35 IO pins available so the # of pins shouldn't be an issue. You still may need resistors with the 74ABT574A where as the TLC5917 has constant current outputs which are programmable. The 74ABT574A will be cheaper and probably easier to get.
Or, since you are considering straight serial, two MM5450sI understand now. So I could theoretically use 9 (9*7 + 1=64) TLC5917's in a series to drive 64 LEDs? Is a 20MHz processor fast enough to do this in 0.04 ms? While the shift registers are being filled with new data, I imagine I would have to have the LEDs off, otherwise the shifting would be visible. So I have to have the LEDs off for however long it takes to fill all 9 shift registers.
Or, since you are considering straight serial, two MM5450s
Dan
Well a 5450 has an enable line so you can fill one at a time.
Hahaha! Two weeks from zero to a fairly advanced project?!?!If you guys think I'm biting off more than I can chew then go ahead and let me know. I have 2 weeks to complete the project and I have never programmed a PIC or tested my programmer with my laptop. I know higher languages, and some C, but I want to see if I can program this project in Assembly. I predict I'll be spending a few nights reading through tutorials haha. I just hope I don't break anything.
Hahaha! Two weeks from zero to a fairly advanced project?!?!Good luck. You better be a very quick study and be ready to put in tons of hours.
No, you need to send the last few bits as it is the last bit that transfers the data from the shift register to the display register.I would need to use an extra pin for this, yes? I might just do the MM5450's in parallel or something also, but I imagine I'd still have to use the enable line because I'd only be filling up 32 bits in each IC.
What PIC is that? It says 16F83P. There's no such thing.Ok, here's my first attempt at drawing a schematic.
That's really cool Nrets. Could you send or post the M file? I took an image processing course in college using Matlab years ago. My term project was blur reduction using image deconvolution.
What PIC is that? It says 16F83P. There's no such thing.
You have the PIC's ground (VSS) connected to VCC, which would be 5V, and you have the PIC's VDD connected to a ground symbol. OH! I see you did the same thing on the 5450 connections. You'll smoke chips if you wire them that way. VSS=Ground. VDD=Power.
Ground symbols should always point down, and power symbols (VCC) should always point up. Some people like to draw a ground rail across the bottom and a power rail across the top and connect everything to them, but that's optional.
I sure wouldn't pull up the OSC1 pin like that. Remove that resistor. MCLR should be pulled up as you've done, though I'd use a 22K or 33K resistor instead of the 10K. The 10K is ok though. It just wastes a little more power.
One more fairly big mistake is that you have all your LEDs backwards. The MM5450/5451 chips' outputs are designed to sink current. That means that when they switch on, they switch to ground. They're not able to source current. So you should connect the LED cathodes to the chip and supply power to the anodes.
That's all I can see with a quick look though. Not too bad for a start.
Ive just tripped on this forum, very interesting.
Take this one step further, Ive thought about this for some time, a cool way to achieve true 3D images "floating in space". A series of "propellor arms" on the same shaft, say 10 deep or more half an inch or less apart from each other (assuming an arm diameter of say 5 inches, to give a similar front to depth view) , each slightly offset to avoid the previous arm blocking the view of the one before. Timing would be critical, and the intiall image map generation would be tricky, but the effect would be a solid cylinder of image 5in dia 5in deep 3D image space. The arms should be invisible if LED on time was controlled carefully. I have googled 3D displays extensively, and dont see anything close. Next step would be to map video into it, low res, and god knows how you would capture it, but video games have depth data embeded that could be extracted for a 3D display.
you need another pin. The last bit latches so you can not run these in series like that.Ok, here's my first attempt at drawing a schematic.
I included 2 MM5450's (SM parts), a PIC 16F88 (I think), 64 0603 SM LED's, and a simple IR emitter/detector circuit to measure the spin rate of the hard drive.View attachment 24636
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?