LED Matrix Message Board

Community PCB Design
1

Hi all!

I’ve just finished with my first PCB design. It’s for the circuit [here.

This is the first PCB I’ll have actually manufactured, and also by far the most complicated (I’ve made simple PICAXE PCBs at school, but nothing with more than one IC).

A few things I’m already not entirely sure about:

  1. Is the ground plane really required? I’m not sure if it’s going to make soldering things any harder either?

  2. With the circuit running all off USB power and using at most 150mA, is there any significant need for larger power tracks?

  3. Will I gain any significant advantage by manually routing all the tracks? I could probably have a go at it, but the autorouter seems to have managed fairly well.

  4. Am I going to incur any problems having the USB socket fairly far away from the FT232RL? The whole PCB is 2"x2".

Besides that, does anyone have any general comments on the circuit design?

Thanks,

Adam

[Eagle Schematic

[Schematic (PNG File)

[Eagle Board

[PCB (Top) (PNG File), no ground plane shown

[3d View of PCB (top)

[3d View of PCB (bottom)

(N.B.: I know the headers on the 3d view are 1) male 2) offset and go over the edge, this seems to be a bug in the Eagle3D software I’m using to generate the images)](https://randomskk.net/projects/led_matrix/pcb_3d_flipped.png)](https://randomskk.net/projects/led_matrix/pcb_3d.png)](https://randomskk.net/projects/led_matrix/pcb.png)](https://randomskk.net/projects/led_matrix/rev02.brd)](https://randomskk.net/projects/led_matrix/schematic.png)](https://randomskk.net/projects/led_matrix/rev02.sch)](http://forum.sparkfun.com/viewtopic.php?t=9393)

2

while i can’t comment on the technical aspects i like the pcb :smiley: wouldn’t mind having one myself.

3

The crystal seems to be really far away from the uC. I would position it super close to the xtal pins on the atmega. It’s good practice to keep gnd around the xtal leads, also.

A ground plane is a good idea. I just leave as much copper as possible and connect it to ground.

I would move your USB connector closer to the FT232. Also, I would try to keep the signal lines as short as possible. Hand routing allows you a lot more control over where the traces go.

On the '595s, I’ve had bad luck with them if i don’t put a current limiter on the input pins and tie them to ground with a fairly high value resistor. I’ve used 1K in series with ser, sck and rck. I’ve used a 470K to pull them to gnd. I couldn’t figure why I was consistently blowing my 595s. Never happened after I added the resistors.

4

I’ve moved the crystal to be adjacent to the xtal pins, and I’ve moved the FT232RL to be next to the USB socket.

I made a ground plane by typing “polygon gnd” into eagle and drawing it, which automatically connects it up to ground wherever there’s a ground connection.

I’m still using the autorouter for now, as I don’t feel up to routing this size board dual layered just yet!

As far as the 595s go, the ones I’m using I have wired up in a solderless breadboard and they’ve been working fine for over a week now - I don’t know if these ones don’t need the resistors or if I’m just killing them slowly, how long did yours last until they died?

Here’s the new [PNG and [Eagle Board.

(I know the ferrite bead seems to be overlapping the headers, but the outline is actually wrong and it’s a fair bit smaller, I’ve printed it out 1:1 and it seems fine).

Thanks for the advice!](http://randomskk.net/projects/led_matrix/rev03.brd)](http://randomskk.net/projects/led_matrix/board_rev03.png)

5

Random:
I’ve moved the crystal to be adjacent to the xtal pins, and I’ve moved the FT232RL to be next to the USB socket.

I made a ground plane by typing “polygon gnd” into eagle and drawing it, which automatically connects it up to ground wherever there’s a ground connection.

I’m still using the autorouter for now, as I don’t feel up to routing this size board dual layered just yet!

As far as the 595s go, the ones I’m using I have wired up in a solderless breadboard and they’ve been working fine for over a week now - I don’t know if these ones don’t need the resistors or if I’m just killing them slowly, how long did yours last until they died?

Here’s the new [PNG and [Eagle Board.

(I know the ferrite bead seems to be overlapping the headers, but the outline is actually wrong and it’s a fair bit smaller, I’ve printed it out 1:1 and it seems fine).

Thanks for the advice![/quote]

Those planes are completely broken up and thus pretty much useless. C1 and C2 are on the wrong sides of the crystal causing ugly overlapping traces. The USB lines should be run as a differential pair. There are tons of right angles in your traces, as well as many completely unnecessary vias. The mounting pads for the USB connector should be grounded. This layout is a complete mess.](http://randomskk.net/projects/led_matrix/rev03.brd)](http://randomskk.net/projects/led_matrix/board_rev03.png)

6

NleahciM:
Those planes are completely broken up and thus pretty much useless.

Really? I'm not aware of any other way to make the planes, so I guess that just comes down to having a correct layout before putting them down?

C1 and C2 are on the wrong sides of the crystal causing ugly overlapping traces.

Whoops, didn't notice that. Fixed it, thanks.

The USB lines should be run as a differential pair.

How do you mean? I've never wired a USB connection, so I'm pretty clueless here.

There are tons of right angles in your traces, as well as many completely unnecessary vias.

Heh, I guess I'll manually route it then.

The mounting pads for the USB connector should be grounded.

That's a good point, the part for that in Eagle doesn't have connections to ground so I guess I never noticed it.

This layout is a complete mess.

Thanks for the advice on how to start fixing it up, though!
7

I’ve manually routed most of it, but have 14 connections still go to (two shift registers to resistors).

The crystal is the right way around and right up close to the uC, the USB lines run parallel (is this what you meant by “as a differential pair”?) and overall the FT232RL is slightly better routed, I think.

I don’t believe there are any (or many, at least) right angles around, either.

This will be it for tonight, I’ll tackle the last 14 connections tomorrow, but could anyone comment on the current layout? I hope I’ve fixed all the issues mentioned below.

I’ll also add ground planes tomorrow, but so far they seem to cover the board nicely instead of being cut into smaller parts. Can’t say for sure until the final 14 routes are set though.

Thanks!

[PNG

[Eagle Board](http://randomskk.net/projects/led_matrix/rev04_routed.brd)](http://randomskk.net/projects/led_matrix/board_rev04.png)

8

For the small amount of distance between the FTDI chip and the socket, I wouldn’t be too concerned with the differential pairing of the USB signal lines. I have hacked up worse with a PIC18F4550 on veroboard and had no issues at all.

9

Placement is a key part of designing a PCB. With good placement, routing is a LOT easier.

Does the board have to be that shape? Increasing the size will make layout a lot easier.

I would move the microcontroller away from the center to one edge, put the USB connector and chip on the opposite edge and the two pin headers+resistors+'595s on either side. I would tuck the third '595 in there somewhere.

Also, the 8 pins that go to the 2 headers from the 3rd '595 causes some layout problems. Do they really need to go through a 595? You have a lot of left over pins on your microcontroller. I would either use them and get rid of the 3rd 595 or go to a smaller microcontroller (fewer pins). As it stands, your Atmega is significantly under utilized.

Look into pinswap - you can reduce the complexity of your layout by changing pin assignments.

Finally, you might want to consider using all surface mount parts. SOICs are pretty easy to solder. That will certainly give you a smaller board.

10

The board does have to be 2" square, since it’l be fitting directly underneath the LED matrix (and to keep costs down!). Further, the two rows of headers have to line up with the pins on the LED matrix, so they can’t be moved.

I considered using the pins on the ATmega to replace the third shift register, but in the end decided against it to simplify programming.

I’ve also looked at using other ATmega chips, but I need the program space (for font libraries) and UART (for USB communications), and I didn’t find any AVRs with less pins that meet both criteria. I’ve also thought of using a larger chip that has enough IO to do away with all the shift registers, but then the chip itself stops fitting on the board!

I’m not sure if perhaps there’s a chip that fits the sweet spot between these two extremes that would be better than the ATmega168. I’m also using the '168 for familiarity, since I’ve used them programming Arduinos and hence should be able to load the Arduino bootloader and program them like that.

As far as pinswap goes, how does that work? I can’t seem to find any related information online, surely most pins are pretty much unchangeable on the hardware?

I can’t seem to find surface mounted varients of the chips I’m using from any of my usual retailers, so have gone for the PTH versions.

Thanks,

Adam Greig

P.S.: I routed half the remaining connections, just the bottom ones to go:

http://randomskk.net/projects/led_matri … alfway.png (warning: massive PNG).

11

Mouser lists 37 matches for 74HC595 in a soic package, a similar number in tssop.

digikey shows a number of surface mount versions of the 168.

I’m not sure I understand why programming a 595 is easier than output pins on a uC. They both are pretty easy.

I would look very closely at losing the 3rd 595.

12

Since you are already going with an SMT part for USB, why not simplify further and use something like at ATMEGA164P in the 44 pin TQFP package? Its got 0.8 pitch (actually larger than your USB chip) with 32 I/O pins divided into four 8-bit ports. You can have one full port for RA, one full port for GA and then either divide C1-C8 between two ports (if that makes layout easier) or put them all on a third (if that makes software easier). Add the serial port and you still have 6 pins to spare. With 200ma overall current drive, it seems to fit your needs and eliminates all the 595s in one go plus is smaller than the 168 in DIP package but not killer small.

Also, why not use a ceramic resonator instead of crystal+caps? I find them easier myself (one part vs three and cheap and small). The extra room and fewer chips should make routing pretty easy (should be able to do almost all of it on the top of the board, allowing you to put a nice ground plane under it).

13

Greetings Vraz,

Vraz:
With 200ma overall current drive, it seems to fit your needs and eliminates all the 595s in one go plus is smaller than the 168 in DIP package but not killer small.

You are misquoting the Abs max spec here. Please

read section 26 of the data sheet and review graphs

27-15 and 27-17.

An Atmega uC is not a substitute for HC CMOS SRs

in this application.

Comments Welcome!

14

Mouser lists 37 matches for 74HC595 in a soic package, a similar number in tssop.

digikey shows a number of surface mount versions of the 168.

Ideally I'd want a UK supplier, but I'll look into Mouser, since none of the suppliers I normally use seem to carry SMT versions.

I’m not sure I understand why programming a 595 is easier than output pins on a uC. They both are pretty easy.

I suppose it's partly because it keeps setting the anodes and cathodes consistent, and partly because I've already got the program working to use all shift registers. However, I am now considering changing it - is the hardware works, the software can certainly be made to!

Since you are already going with an SMT part for USB, why not simplify further and use something like at ATMEGA164P in the 44 pin TQFP package? Its got 0.8 pitch (actually larger than your USB chip) with 32 I/O pins divided into four 8-bit ports. You can have one full port for RA, one full port for GA and then either divide C1-C8 between two ports (if that makes layout easier) or put them all on a third (if that makes software easier). Add the serial port and you still have 6 pins to spare. With 200ma overall current drive, it seems to fit your needs and eliminates all the 595s in one go plus is smaller than the 168 in DIP package but not killer small.

While this would be a nice solution, as bigglez pointed out, the chip can't drive all the LEDs.

That said, to both you and bigglez: Given that I’m multiplexing it such that at most 8 LEDs are lit at once (one row), is it still outside the current rating?

Also, why not use a ceramic resonator instead of crystal+caps? I find them easier myself (one part vs three and cheap and small). The extra room and fewer chips should make routing pretty easy (should be able to do almost all of it on the top of the board, allowing you to put a nice ground plane under it).

That sounds like a fairly good idea, will the resonator still be accurate enough for 9600 baud serial communications with the FT232RL? I've not used either before on a PCB.

The FT232RLs arrived today, and wow the pitch is pretty small! Soldering this will be interesting.

Thanks for all the help so far guys!

15

You are misquoting the Abs max spec here. Please

read section 26 of the data sheet and review graphs

27-15 and 27-17.

So am looking at the 164P user manual (I assume your section references are to another device-- maybe the 168?). Regardless, I suspect they are similar:

Under Absolute Maximum Ratings:

DC Current per I/O pin: 40.0ma

DC Current Vcc and GND Pins: 200ma

Under DC Characteristics (notes):

  1. Although each I/O port can sink more than the test conditions (20mA at VCC = 5V, 10mA at VCC = 3V) under steady state conditions (non-transient), the following must be observed:

1.)The sum of all IOL, for ports PB0-PB7, XTAL2, PD0-PD7 should not exceed 100 mA.

2.)The sum of all IOL, for ports PA0-PA3, PC0-PC7 should not exceed 100 mA.

If IOL exceeds the test condition, VOL may exceed the related pecification. Pins are not guaranteed to sink current greater than the listed test condition.

  1. Although each I/O port can source more than the test conditions (20mA at VCC = 5V, 10mA at VCC = 3V) under steady state conditions (non-transient), the following must be observed:

1.)The sum of all IOH, for ports PB0-PB7, XTAL2, PD0-PD7 should not exceed 100 mA.

2.)The sum of all IOH, for ports PA0-PA3, PC0-PC7 should not exceed 100 mA.

If IOH exceeds the test condition, VOH may exceed the related specification. Pins are not guaranteed to source current greater than the listed test condition.

For the 164P, I assuming the graphs you are referring to are 28-22 and 28-22. They show voltage drop based on pin load, capping out at 20ma per the above spec.

Note that I assumed this design required no more than 10ma per pin since Random quoted the power consumption at 150ma and I assumed that was divided between the matrix of 16 LEDs (150/16=9.3ma max) in a raster scan.

That said, to both you and bigglez: Given that I’m multiplexing it such that at most 8 LEDs are lit at once (one row), is it still outside the current rating?

Assuming an LED voltage drop of around 2v (check your LED spec), I think that means (5v-2v)/330 ohm = 9ma per LED. Based on my reading of the spec, 9ma * 8 pins = 72ma which seems within the spec of the 164P on a per pin, per port and per device basis, but I may be reading it wrong.

bigglez- Is there something else I missed or am I reading the spec wrong, or ???[/quote]

16

So I just clued in that you are trying to drive the SFE dual-color matrix display. That answers why you drive 8 LEDs at a time but have 16 current limiting resistors (2 colors). However, the big issue is that when you drive a single row of 8 LEDs, all the current will return on a single column pin. So while each LED might draw 9ma, with them all on, you need to return 72ma on a single pin.

That 72ma will exceed the single pin rating of the AVR or of the 595 (35ma per pin). You need something with higher current capability than either of these parts for the column select.

Just curious-- you have tried the matrix with the 330 ohm current limiting resistor @ 5v and was it bright enough for your application? Obviously more current creates additional challenges, but better to figure out exactly what you need now so you can correctly size the other components.

17

Vraz:
So I just clued in that you are trying to drive the SFE dual-color matrix display. That answers why you drive 8 LEDs at a time but have 16 current limiting resistors (2 colors). However, the big issue is that when you drive a single row of 8 LEDs, all the current will return on a single column pin. So while each LED might draw 9ma, with them all on, you need to return 72ma on a single pin.

That 72ma will exceed the single pin rating of the AVR or of the 595 (35ma per pin). You need something with higher current capability than either of these parts for the column select.

Just curious-- you have tried the matrix with the 330 ohm current limiting resistor @ 5v and was it bright enough for your application? Obviously more current creates additional challenges, but better to figure out exactly what you need now so you can correctly size the other components.

That’s interesting - I am running it right now with the 3 shift registers and 330 ohm resistors, and it’s working fine on a breadboard (while not very bright, it’s perfectly sufficient, I wouldn’t want it brighter). I believe the SparkFun serial control backpack also uses the same shift registers without problem.

I see your point about the 72mA returning on one pin, though.

Bear in mind that each LED is being driven at less than 6% duty cycle - on half of 1/8th of the time, when it’s on - and it’s not being updated all the time, but instead once every 200µs.

I don’t know if this might change the effective current, since it does seem to be working fine at the moment.

18

Random:
That’s interesting - I am running it right now with the 3 shift registers and 330 ohm resistors, and it’s working fine on a breadboard (while not very bright, it’s perfectly sufficient, I wouldn’t want it brighter). I believe the SparkFun serial control backpack also uses the same shift registers without problem.

I see your point about the 72mA returning on one pin, though.

Bear in mind that each LED is being driven at less than 6% duty cycle - on half of 1/8th of the time, when it’s on - and it’s not being updated all the time, but instead once every 200µs.

I don’t know if this might change the effective current, since it does seem to be working fine at the moment.

If you breadboard is still attached, you might try an experiment. Set up the display with one LET lit on the first row, two on the second, etc. with 8 on the bottom. Can you see any difference in the brightness of the rows?

19

Greetings Adam,

random:
I believe the SparkFun serial control backpack also uses the same shift registers without problem.

Correct, but only for Columns, the Rows are driven

by low-side drivers spec’d to 500mA [(ULN2003,I

think, the number was left off the SFE schematic).

Comments Welcome!](http://focus.ti.com/lit/ds/symlink/uln2003a.pdf)

20

Greetings vraz,

Vraz:
For the 164P, I assuming the graphs you are referring to are 28-22 and 28-22. They show voltage drop based on pin load, capping out at 20ma per the above spec.

It was late when I posted the datasheet cite, and to clarify,

use [this datasheetand check fig. 28-22 and 28-23.

Vraz:
Note that I assumed this design required no more than 10ma per pin since Random quoted the power consumption at 150ma and I assumed that was divided between the matrix of 16 LEDs (150/16=9.3ma max) in a raster scan.

Not true. The array requires zero to eight columns

to be high at the same time as one row to be low.

The row therefore can have eight times the single

LED current, exceeding the AVR IO pin spec.

Vraz:
bigglez- Is there something else I missed or am I reading the spec wrong, or ???

Yes, even though the matrix is MUX'd the drivers must

be strong enough to carry the full current of eight LEDs.

Because of MUX’ing the peak LED current will be eight times

the average current.

In this case the OP is happy with very low brightness

compared to the DC limits of the display, but even so

the current demand exceeds the drivers (in an AVR),

and taxes the drivers in an HC CMOS logic device.

Comments Welcome!](http://www.atmel.com/dyn/resources/prod_documents/doc8011.pdf)