Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

POV: SMD LED array with PIC (beginner)

Status
Not open for further replies.

Nrets

New Member
I've been reading some tutorials various POV controlled by PIC's or other controllers. Some are really simple 8 LED devices you wave with your hand, others are 96 x ? displays that can display actual pictures. I've seen a few radial variants to create clocks also. Anyways, each one has its own method for controlling the LED's and I have a few questions about how this is done; lets get started.

I read a really good tutorial that takes eight 8x8 LED grids and drives the whole thing using only 10 pins. 8 ground the rows, and 2 switch a Johnson counter. The only problem with this tutorial is that it only explains the process for one 8x8 grid, even though it makes perfect sense on this level. How do you extend this to 7 more grids using the same pins?

My background in circuits is very poor as I am a chemical engineer and not an electrical engineer. From what I understand, a Johnson counter increments its output each time it is cycled (although I don't think it's quite that simple and I know there are a number of other types of counters; do johnson counters bring back down the previous output to 0 first?). Anyways, as I understand it, you ground the rows for the first column, the counter shifts, then you ground the rows for the second column, and so on, until you get to the end of the matrix where the counter is then reset (automatically or in the code?).

That makes sense. Each additional 8x8 matrix needs another johnson counter. Now my question is: how are these 8 individual counters controlled with only two pins? Can you have nested Johnson counters? That is, can you cycle one 'master' Johnson counter in such a way that it doesn't get shifted until the first 'slave' Johnson counter is reset? That way each column in the 8x8 matrices gets cycled, and then the 8 of the 8x8 matrices get cycled. That way it's as if each 8x8 matrix is a single LED and the 8 together make a single row whose columns are cycled through by the 'master' Johnson counter.

I hope that makes sense. I'm not sure if this is how it is down in practice though. Is it even possible? Is there a better way?

My plan was to have 64 0603 SMD LED's in a line on a hard drive platter and multiplex them along the radius by having 8 groups of 8 in a row, so it's just like the above example. In other words, I'll be multiplexing along the radius, 8 at a time, and then spinning the harddrive at 4,000 RPM for the other dimension. I basically want to make a polar plotter; it's going to be a gift for someone.
 
Well, no responses yet, hope I didn't scare anyone off or annoy people. To spark some interest in the project, and to inspire you guys to help me out a bit, watch this video:

YouTube - the most amazing RGB propeller clock ever seen

To help even more, the following link explains how to do what I want to do (except I'm driving a 64 x 1 array, same concept though):
A dot matrix led display project for an 8x8 or 5x7 led matrix.

Anyways, I haven't made any progress on the hardware aspect of this project, but I have made some major headway into the software part.

The idea is to plot 2-d Cartesian images using polar coordinates, because that's what I'll be using in my POV.
I'm using MATLAB to convert images into matrices of polar coordinates (angle and radius) that will be used in the POV hard drive. The m-file is very simple and basically takes an imput of dtheta, R, and the image file.

dtheta is just how often I want the LED's to change. So dtheta = 1 translates into 1 degree, so 360/1 = 360. Hence, my POV would have a resolution of 360 x 64 (because I have 64 LED's across).

R is the radius of course.

The image file can be pretty much any format, but jpeg is preferred. The image size also has to be less than 128 x 128 (64*2).

Anyways, here's an example of how it works:

the attached images show how it works:

Raw image w/ 64x360 grid mapped over it:
image_map_ex.jpg
Plotted binary image using polar coordinates:
result_ex.jpg

When the POV does the plotting, the coordinates will not be dots, but nearly rectangular wedges as the POV sweeps fro theta to theta + dtheta. I could probably simulate this in matlab, but I'm too lazy.:rolleyes:

If anyone has a similar project or wants the m-file, I'll go ahead and post it here.
 
Last edited:
Well, no responses yet, hope I didn't scare anyone off or annoy people. To spark some interest in the project, and to inspire you guys to help me out a bit, watch this video:

YouTube - the most amazing RGB propeller clock ever seen
That's very cool! I've been meaning to build either a propeller clock or a hard drive clock for a while now. That vid makes me want to do it even more. Maybe a good project for my new ARM7 board... Hmm...
 
Of course, weight and balance our an issue, especially at 4,000 RPM, but it's the least of my worries right now.

Multiplexing the 64 LED's with one PIC is my problem right now.

This is my first PIC project EVER, but I don't think it's too ridiculous. There are lots of POV tutorials and they are not too complicated. The theory of using Johnson counters or even latches is where I need help.

In the meantime, I'll select a PIC to use (already got a programmer) and start buying the LEDs and stuff. Is there any local supplier in the Phoenix area that sells PICs? Or any websites that can deliver items within 3 days of ordering?
 
Why drive at 4000 rpm? 1800 would be fast enough for POV.

I think both Mouser and DigiKey will overnight shipments.
 
Why drive at 4000 rpm? 1800 would be fast enough for POV.

That's just the idle speed of the hard drive, maybe it's slower, I can't remember. I don't know how to control the speed of the hard drive because they have a special driving circuit because the motors are some type of stepper motor that require sin-wave input.

I might just use a PC fan, but hard drives are much cooler.
 
Check my LED matrix PIC tutorial.

I assume you are referring to this tutorial:
?

Yes, I have read your tutorial, and it's great, but I don't see how it can be extended to individually controlling 64 LEDs in a single row?

Oh, you know what. I think I just figured it out!

I was always planning on grouping the LEDs in eights, so how about I just have the first LED of each group of eight connected to the same PIC pin? That way I have it arranged just like an 8x8 LED matrix, linearly. Do you think this will work?
 
That's just the idle speed of the hard drive, maybe it's slower, I can't remember. I don't know how to control the speed of the hard drive because they have a special driving circuit because the motors are some type of stepper motor that require sin-wave input.

No, it's not a stepper - it's a brushless DC motor - as used in VCR's etc.
 
I assume you are referring to this tutorial:
?

Yes, I have read your tutorial, and it's great, but I don't see how it can be extended to individually controlling 64 LEDs in a single row?

Oh, you know what. I think I just figured it out!

I was always planning on grouping the LEDs in eights, so how about I just have the first LED of each group of eight connected to the same PIC pin? That way I have it arranged just like an 8x8 LED matrix, linearly. Do you think this will work?

It's just a matter of how you mount the LED's, they connect exactly as my tutorial, and you just lay them out in a line to give a row of 64 (but driven as 8x8).
 
Is it? I can't drive the motor with DC power using the 4 connections. I have to have the circuit board connected to the 4 pins and apply power to the board.

A brushless DC motor requires electronics to work, essentially hall effect sensors detect the position of the rotor, and switching transistors activate the different coils in the correct sequence. It's really no different to a brushed motor, just that the switching is done electronically instead of mechanically.
 
To spark some interest in the project, and to inspire you guys to help me out a bit, watch this video:
YouTube - the most amazing RGB propeller clock ever seen
If you look closely at the start of the video, you'll see that the author uses direct drive for his RGB LEDs. There are a number of reasons for this:
1) Multiplexing will be more difficult with a POV display because you'll SEE the LED multiplexing when it spins unless you multiplex REALLY fast.
2) Multiplexing tends to make it difficult to make the display bright enough due to the high peak currents required. This would mean adding extra drive IC's for more current thus adding complexity and weight. The light, already "spread thin" by the multiplexing, will be spread even thinner by the POV "multiplexing" resulting in a very dim display.
3) In short, I don't think there is any advantage to multiplexing the LEDs used in a POV display, but I can see a lot of down sides.
 
Last edited:
Ok, so multiplexing for a spinning POV device isn't a good idea because of processing speed and brightness?

So 4,000 RPM = 67 RPS => 0.04ms per degree. So yeah, I guess I'd have to have the 64 LEDs multiplexed in 0.04ms, and I don't think that is possible is it? 20MHz clock = 20,000 cycles/ms =>800 cycles/0.04ms. It seems like it'd be possible, but I don't really know a lot about processors and what I can really expect in terms of instructions/ms, and how this translates into the circuit.

Brightness I suspect would be the main problem. Cycling 64 LEDs in 0.04ms would be pretty dim. I was thinking of using a UNL2308 transistor array to give the LEDs more current, but I don't think this will be enough, will it?

Directly driving 64 LEDs

I don't know how to directly drive the 64 LEDs but I'll do some research and figure it out. I suppose having latches to act as "RAM" might help? Again, I don't know much about using latches.

I'm thinking of using a PIC 18F4550 so I'll have 35 I/O pins, if that helps with my options let me know.
 
Hard drives that i have played with don't have hall effect sensors in them the controller has
has a counter that keeps up with the pluses to no if it is at speed
 
I don't know how to directly drive the 64 LEDs but I'll do some research and figure it out. I suppose having latches to act as "RAM" might help? Again, I don't know much about using latches.
Look into the 74HC595 or 74LV595. These contain a shift register and a latch in one package. Both can supply apx 70ma to 8 LEDs (8.75ma per LED), though the LV version looks a little better as far as the output voltage is concerned.
There are other chips, such as the TPIC2810 that have a SPI or I2C interface and deliver more current. Or you can get really fancy and try the TLC5917 which has built in constant current capability so you can eliminate resistors and have program control of LED brightness.
 
Last edited:
which has built in constant current capability so you can eliminate resistors and have program control of LED brightness.
74ABT574As are more efficient to drive (though they take more lines) and can pull 128mA to ground per pin (64mA to maintain logic output levels)

Dan
 
Look into the 74HC595 or 74LV595. These contain a shift register and a latch in one package. Both can supply apx 70ma to 8 LEDs (8.75ma per LED), though the LV version looks a little better as far as the output voltage is concerned.
There are other chips, such as the TPIC2810 that have a SPI or I2C interface and deliver more current. Or you can get really fancy and try the TLC5917 which has built in constant current capability so you can eliminate resistors and have program control of LED brightness.

Thanks!

But I think I am a little confused on why I would want a shift register if I'm not multiplexing. I'll do some research on shift-registers and probably answer my own question though. I don't want to waste anyone's time.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top