POV: SMD LED array with PIC (beginner)

[kchriste]

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.

 

[Nrets]

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.

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? 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.

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.

I'll draw up a possible schematic and post it here soon. I'm in the middle of finals and should really be focusing on ethanol-water fractionation, haha.

 

[kchriste]

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?

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.

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.

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.

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.

This would make a software bitbang faster by 8x. 8 SER, 1 SRCLK and 1 RCLK lines will drive 8 74LV595s.

 

[Ubergeek63]

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.

True, I had missed the direct drive. He is still trying to drive twice as many LEDs than he has port pins available though.

Dan

 

[Ubergeek63]

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? 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

 

[Nrets]

Or, since you are considering straight serial, two MM5450s

Dan

Not a bad idea. It says in the data sheet however that the bits are not latched until the 36th bit has been transferred. How does this work when you have two MM5450's in a series? You'll need to transfer 70 bits to fill both MM5450's, but you don't want to latch the first 35 into the first IC.

 

[Ubergeek63]

Well a 5450 has an enable line so you can fill one at a time.

 

[Nrets]

Well a 5450 has an enable line so you can fill one at a time.

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.

Anyways. I'm going to order parts tomorrow. 64 0603 SMD LEDs, 2 MM5450's, and the PIC (I'll probably go with something smaller than the 40 pin chip since this IS my first PIC project and I don't want to completely overwhelm myself). I already have the components for the sensor circuit and other small components like the resistors and capacitors.

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.

 

[futz]

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.

 

[Nrets]

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.

Haha, that's the plan. I'm done with my last final tomorrow and I tend to learn pretty quick on these sorts of things. If everything falls through the floor, then I'll save it for Valentine's Day or Chinese New Year (since she's chinese) and do something simple for Christmas.

 

[Ubergeek63]

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.

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.

Of course you can send two bits in parallel instead, it just gets messy in software if you aren't real clever with your wiring. I often put a lot of work into display arrangement since it can put an unnecessary burden on software making requirements go from comfy to not a chance.

Dan

 

[Nrets]

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.

Note:

1. This is my first attempt at a schematic and I am sure I violated good practice everywhere
2. The "Address Buses" were just added to keep from cluttering the diagram, each output goes to a separate LED for a total of 64 outputs to 64 LEDs
3. I only showed 16 of the 64 LEDs
4. The IR emitter/detector circut shows two LEDs, but one of them is suppose to be a detector.
5. I don't have any resistors for the LEDs because I plan on using the MM5450's current control, when i figure it out.
6. Finally, I have no idea why I have the 3 10K resistors, I just did this because I've seen it done in similar circuits.
   

 

[futz]

Ok, here's my first attempt at drawing a schematic.

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.

 

[Speakerguy]

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.

 

[Nrets]

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.

Sure no problem. I attached the file. It accepts inputs of dtheta, R, and image_in.

dtheta is the change in angle for each step
R defines the radial 'resolution', it will be the number of LEDs used to generate the image

image_in can be defined with the following code:
image_in = imread('filename','filetype');

The output of the file is a matrix containing a column of angles in radians, a column of the LED number, and a column of 1 or 0 to indicate if that LED should be on or off.

The code also plots your image, so it may take a while to run. Get rid of this line if you just need the data.

View attachment topolar.txt

(had to attach it as a text file, wouldn't let me attach an m-file)

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.

Wow, yeah, I'm really glad I don't have the parts yet, haha!

I fixed those problems and added a few wires and capacitors for brightness control, but not sure if it's configured properly.



I'll also go ahead and add some wires for IC programming since I have free pins.

 

[kchriste]

When you edit your post, you choose "Go Advanced" and then "manage attachments" and delete the old attachment and upload a new one.

 

[bassnut]

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.

 

[Nrets]

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.

It sounds really cool, but I don't think it would work. When you think about it, we see everything in three dimensions around us, but only the surface of things. You can never see both the surface and everything inside of an object.

But yeah, you could do cool stuff like having something move in three dimensions, or have a planet orbiting a star. Now I kind of want to do it. Anyways, multiple propeller arms would be too heavy I think.

Have you seen this?
YouTube - 3D led display globe

 

[bassnut]

Cool video, but thats not 3D, just a curved 2D display. A 3D display, just like normal vision, shows the "surface" of things, but all round them, with a depth aspect, when you physically view it at different angles.

 

[Ubergeek63]

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

you need another pin. The last bit latches so you can not run these in series like that.

Split the enable pins to direct the serial data stream to one or the other. If you do not want to use another pin you can put an inverter between them.

Dan