Go Down

Topic: Shield design review - Dual RGB Character LCD Interface (Read 779 times) previous topic - next topic


Sep 13, 2015, 10:49 pm Last Edit: Sep 13, 2015, 11:02 pm by ShapeShifter
I'm working on a project that involves driving a few discrete LEDs and a pair of RGB backlight character LCD displays (https://www.adafruit.com/products/499)

I have the hardware and software working on a breadboard, but for longevity and reliability, it's time to turn it into a custom shield. While I've made up many circuits on perfboards, and I did etch some single sided PC boards as a kid using hand-drawn resist pens (many decades ago) this is the first time I will be going to a board house to have some boards made. I would appreciate a review of my work so far, and am asking for any constructive criticism.

The circuit is very simple: independently drive two character LCDs, drive their RGB backlights using PWM control, and also drive a few discrete indicator LEDs. That's all there is to it, everything else the project does is handled by the Linux side of a Yun, using the USB and network interfaces. Yes, this could be built on a raw perfboard (the proto-shields I have don't have enough holes in a row for the 40 pin header.) But this seems like a relatively low risk project for the first time out getting boards made, and opens the door for more complicated future projects.

The board is specifically designed for a Yun, and includes large notches in the corners to fit around the tall Ethernet and USB jacks of a Yun. This allows the board to sit flat, without hanging up or shorting out on those tall connectors, and without needing extra long headers (or stacking an extra set of headers between the boards.) While the form factor is specific to the Yun, it should work with any Arduino that has the standard shield layout (so it excludes Mini, Micro, and similar variants.)  While the Yun does have the R3 style headers with the separate SDL and SDA pins, I did not include them on this shield - partly because I don't need them, and partly because the Ethernet jack cutout interferes with those pin positions.

The only part of the design that might be unique is the use of a 40 pin (2 rows x 20 column) header for the display connection. The displays have single row 18 pin headers. By using a ribbon cable with three connectors crimped onto it, the shield can be connected to both displays, while still allowing independent control. One display is plugged into the odd row of pins on one connector, the other display is plugged into the even row of pins of another connector, and the last connector is plugged into the dual row header on the shield. Most of the pins are connected in parallel between the two displays: the exceptions are the individual display enable lines, and the RGB backlight LED control lines. The cable will look something like this:

Note that the cable length is not to scale, I intend to make it longer than is implied by that drawing (probably around a foot total length, definitely less than two feet total.) The dark pin spaces are keying inserts - plugs to prevent the cable from being plugged into the displays incorrectly. It's a bit of a waste using a 40 pin cable, when 36 pins are all that are needed, but while 36 pin connectors are available, they are significantly more expensive than the more standard 40 pin versions, and I already have a sufficient stock of 40 pin connectors in my parts bin.

Eagle schematic and board files are attached. For the convenience of those who don't have Eagle installed, I'm also attaching a PDF version of the schematic. This is a representation of the board layout, as well as a rough paper mockup of how it will look when installed on a Yun:


This is a two layer board. Red traces are on the top, blue are on the bottom. Ground pours on both sides are not shown here, for clarity. Signal traces are 16 mil (0.016 inch) while the power trace is 50 mil (0.050 inch.) The small "isolated" vias that are not connected to any traces are stitching between the top and bottom ground planes.

Power from the board is intended to come from half a USB cable soldered into the pads of J1. This will be plugged into a powered USB hub, which will also supply power to the Yun through it's micro-USB connector, as well as power the USB devices controlled by the Linux side code. JP1 is a three-way solder jumper: a blob of solder from the center pad to the lower pad allows powering this board from the Yun - but this is not recommended because of the limited amount of power available from the Yun. A blob from the center pad to the upper pad allows powering the Yun from this board - also probably not a good idea, so that the Yun is isolated from any voltage variances caused by LED loads.

J4 is a place to solder a grounded two-pin male header, providing a convenient place to attach scope and logic analyzer ground leads during board testing.  Below the upper right standoff hole is another hole labeled "Yun RST" - This allows accessing the Yun's Linux processor reset button using a small tool. The bottom ground pour has a small void in it, which is the area above the Yun's ICSP header. By keeping components and copper out of this area, there is no possibility of a short with these pins. The top silkscreen shows outlines for stackable headers installed from the top, while the bottom silkscreen has outlines for standard male header pins to be installed from the bottom. This gives flexibility to use the shields either way - I plan to just use regular male pins instead of stackable headers, as all of the I/O pins are used up, making stacking anything with this a moot point, not to mention clearance for the large ribbon cable.

There are additional design notes on the schematic page to help explain my thought process (both for your benefit during reviewing this, and for my future benefit when I come back to this years from know and can't remember the details. Age related CRS is the pits!)

Pin D7 is not used by this shield. This pin is also connected to the Linux processor, and I am using this signal as a direct hardware handshaking line from the Linux side to the sketch.

I plan to have some boards made by OSH Park. This is what their automated preview render engine thinks they will look like:

Board Top:   

Top copper:   

Board Bottom:     (as seen from the bottom)

Bottom copper:     (as seen from the top)

I used the standard set of OSH Park DRC rules, except that I increased the Masks - Limits value so that the small ground plane stitching vias are covered with soldermask. The default value of 0 leaves all vias exposed.

I still need to do some experimenting to decide on resistor values. The values on the schematic are very conservative and keep the overall power usage to a minimum (I am currently powering the breadboard with the limited 5V output of the Yun.) But I will be decreasing those values to increase brightness in the final build. I won't be exceeding 20 mA for any LED, either discrete or backlight RGB.

I spent a lot of time and thought on this board. (Too much!) But I'm sure there is something that I haven't considered. If anybody has any constructive criticism, either functional or aesthetic, I would be grateful and would sincerely appreciate hearing it.

Edit: Schematic and board files are in the attached .zip file - I guess the forum doesn't like attaching them directly...


Wow, not a single comment from anybody? Does that mean it's perfect as is? That can't possibly be true.

Or is it so bad that it's hopeless?


I was able to download and open with Eagle 6.6 and it looks good from what I see.

I like to set the Polygon copper pour isolate to at least 0.016" because although the PCB shop (OSHpark uses several) will mostly not have a problem I have seen a few in the past (not from OSHpark). It also reduces the capacitance between the plane and other stuff, though sometimes that capacitance helps so I'm not sure it is worth mentioning.


Thanks for the feedback!

Is there a setting in the DRC that allows adding that isolation clearance for all pours? The only thing I see in there is the general clearance between various items (not specifically pours.) I see the setting you're talking about on the ground pours, and with the default value of zero, I guess that means it's taking the general 8 mil clearance value from the DRC? So I guess this is something that needs to be done for each pour (or set up in the tool ribbon bar after selecting the polygon tool but before drawing the polygon.)

I've gone ahead and increased the ground pour isolation. Thanks!


That sounds right. There are times when I want the 8mil clearance (e.g. near an FTDI chip). At any rate I just set the isolate when making the pours (or actually after since I forget most every time).

And your welcome.

Go Up