CyberRailGuru

Construction (Sort Of)

In Part 1 we learned about the requirements, and in Part 2 we talked about the design.  Now the rubber meets the road.  I did the research and the design.  Now I needed to manufacture some printed circuit boards and put the design to the test.

Laying out the PCB was a little cumbersome since all the chips wouldn’t fit neatly on a normal sized Arduino shield, so I had to make the board a little larger than “normal”.  Not a big deal, but a little less ideal than the perfectionist in me wants.

After the boards were manufactured, I order some solder stencils and set out to solder everything.  Since the board is almost exclusively surface mount, this would be my first foray into assembling a surface mount device (SMD) PCB on my own.  I’ve done it professionally, but in that case I paid other professionals to do it for me.  I’m way too cheap to pay someone to do it, so I did it myself.  I’ll probably write about that experience separately – it worked out very well and I am super pleased with the results.

Driver Shield and LED Strip PCB

Driver Shield

Once the boards were done I had to write all the software for the Arduino.  Writing the initial code was fairly easy, but getting it work properly was a huge pain.  The design / build process was orderly – test the driver first, then test the columns, then put the pieces together.  All went well.  Once I could turn LEDs on and off using the full complement of capabilities, I turned my focus to the multiplexing an driving a 48×16 array.  This is it got really complicated and really frustrating.

I spent many hours futzing with Arduino timers, optimizing the software, and really worrying about how many CPU cycles each routine was using.  In the end, I had to collapse most of the time critical code into a single routine and give up any hope of controlling the full array using the full depth of intensity settings

Embedded Software Design 501

Yes, I said 501.  This is not 101 territory.

This design contains a matrix that tis 48×16, which is 768 “nodes” individually addressable.  Each node has a 12-bit pixel depth, or intensity level.  Microcontrollers don’t understand 12 bit, so we get to round up to 16-bits, or 2 bytes. Easy enough – 48x16x2 = 1,536 bytes to fully control the entire matrix.  Oh, good software engineering says we double buffer the bit maps to avoid any “hiccups” with display intensity, so we need 3,072 bytes.

Now, I spent nearly a decade designing and implementing embedded solutions professionally, so I was very conscience of how much memory my program used.  However, I did not set down in advance and calculate it out like I did above.  Had I done that, I would have predicted, and avoided, many, many hours of exasperation.  You see, the Arduino microprocessor only has 2K of SRAM, and approximately 500 bytes is used by the bootloader, leaving only ~1500 byte free for the user.  So, I had approximately 50% of the RAM available to me that I needed.

Rather than the compiler flagging me and saying “hey, idiot, you have allocated more than than is available”, the code uploaded fine and operated fine.  For a while.  Then it started behaving oddly.  It didn’t stop working – it just stopped working properly.  More importantly, code that used to work, stopped working properly.

**THE MOST FRUSTRATING PART OF EMBEDDED PROGRAMMING EVER**

So after many hours of adding print statements, changing code, commenting things in and out, I finally narrowed the issue.  When I commented some code out, it worked fine; when I commented it in, it failed.  First and most classic sign of a memory problem.  When and finally sat down and did the math.  Duh! I am an **idiot**.

(For the record, adding print statements actually made the problem worse by using up even more RAM.  Great, eh?)

Compromise time.

I needed the double buffering, so my only choice was to narrow the intensity density.  But cutting it in half still pushed the memory requirements to ragged edge.  Remember when I said the boot loader uses “approximately” 500 bytes.  Yeah, well, that approximately is super important when literally every byte matters.  After a lot of debugging, it turns out I was using about 20 more bytes than were available, **if** I called more than 2 subroutines.  And which subroutine I called changed how much memory was required.

This my friends is called the “stack size” and it is really important.  When you push something on to the stack, it uses memory.  When that memory is used by something else, like say a variable in your interrupt service routine, it tends to, ummm, f*ck sh*t up.  Bad.

Ok, so that’s the lesson learned about advanced embedded system programming.

1. Know exactly how much memory you need
2. Know exactly how much memory you have
3. Only use how much memory you have

Seems basic.  But without an embedded debugger and a super expensive logic analyzer, it can take you days to figure out.  Days and days and day.

In the end, I had to combine a number of functions breaking all normal OO programming “rules”, use direct bit manipulation instead of the stock Arduino functions, and count the number of CPU cycles for certain operations before the code worked properly.

Once I got the code to work properly, I had to assemble the entire thing on the Power Tower itself, which led to much fun and amusement.  All of which will be documented in the next article, Part 4.

In Part 1 I discussed the “requirements” for the project and determined none of the solutions I found on the Internet met my needs.  So to the drawing board I go…

The Design

I combined a couple different ideas into a single solution.  I decided to use a PWM-enabled constant current LED driver for the rows, shift registers to control the columns, and a set of “high side drivers” to provide the voltage and current for the columns.

Now, you might think that using a constant current driver would have “solved” the current problem wouldn’t you?  Well, that’s what I hoped but here’s a quick diversion into EE 101 for the implications for my design.

To save on the total number of output pins, I grouped 3 LEDs together.  To turn the LEDs on I need exceed their combined forward voltage.  For normal red LEDs, that’s about 2.1v; for blue and green LEDs, that’s about 3.2.  I wanted a mix of all colors, so I knew the source voltage had to be between 6.3v (2.1 x 3) and 9.6 volts (3.2 x 3).  The “closest” normal voltage is 12v, which is what I settled on.  That means the anthode would be connected to 12 volts while the cathode would be connected to ground.

LED Schematic

As mentioned above, I decided to use to a constant current driver to control the rows, which puts the constant current driver at the cathode (i.e., ground).  As such, I need to drive the LEDs at 12 volts, but also use a constant current driver at the cathode.  Additionally, I need more current at the anthode than a single microcontroller ping can provide (~500mA vs 30ma).  Therefore, I need some sort of transistor at the anthode and there is where things get complicated.  Nearly every simple switching circuit I found would only work properly if the source voltage does not exceed the voltage controlling the transistor.  In my case, the control voltage is a normal logic level of 5 volts, but the source voltage is 12 volts.

I researched a lot of different configurations before I finally found a solution that meets the needs.  In short, I needed a “high side driver” – a driver that lets a small range of “drive” voltages control a larger range of “source” voltages.  Fortunately, there are a couple ICs on the market that (mostly) met my needs.  I really wanted to switch an entire column with a single control circuit, but an entire column would be approximately 840mA and all the solutions I found maxed out at 500mA.  So, I needed two ICs per column, leading to 16 “columns”.

After it was all said and done, I needed up with up to 48 rows, and up to 16 columns in the final design.  I combined two TLC5947 (code complements of Adafruit) constant current drivers with 2 74595 shift registers for the columns. The shift registers feed a pair of A2982 high side drivers that provide the current to the LEDs. In this configuration, each column can provide up to 500mA allowing me to switch approximately 25 rows at a time.  That almost perfectly separates the design in half; the 5947 provides 24 rows and the 74595/A2982 pair provide 8 columns at 500mA.  Double everything and I have 48 rows x 16 columns, or 768 control lines.  Theoretically, I can control 768 triads of LEDs, which is a whopping 2304 LEDs!

LED Driver v1.0

Fortunately, I did not need so many LEDs for my purposes.  Part 3 will document the manufacture, assembly, and testing of the final solution.  Stay tuned.

Intro

Last year around this time I started a new project to challenge my abilities in hardware design and software programming.  Truth be told, I have been thinking about the project for a number of years, but never really had the time to work on it.

The idea was to outfit a Faller Power Tower ride with LEDs lining the tower.  There are a number of videos on YouTube with something similar, but none of the videos really show the mechanisms up close or provide any details on how they accomplished it.  I’ve always been fascinated with the shear number of LEDs on some of the videos and prospect of controlling them.  So, I set out researching the control mechanism, mounting techniques, and assembly ideas.

I guess I should forewarn anyone who might read this, I had not fully thought through size and scope of the project.  Nor the slippery slope I was about to slide down.  In the end, the first phase of the project yielded approximately 1000 LEDs lining the sides of the power tower, and Phase 2 led to approximately 219 more LEDs for the mast, and Phase 3 will lead to another 219 for a main sign.

At this point any sane person might think I’m crazy or simply bored.  Neither.  Just the average maker looking for a challenge.

So, on with the description, pictures, and maybe a video or two.

Planning

To drive a lot of LEDs, you need a lot of output pins and a lot of current.  It is simply not feasible to control each (normal) LED individually.  Building a circuit with over 700 outputs would be very problematic, not to mention wiring 700+ wires would be, well, crazy.  Likewise, controlling the intensity of each LED with any level of granularity leads to all sorts of other complications.

I knew multiplexing would be in the future, so researched all the popular mechanisms and prototyped the more popular ones: Matrix Multiplexing and Charlieplexing.  Then I investigated ways to control the intensity, which included Pulse Width Modulation (PWM), Binary Code Modulation (BCM), and a couple other techniques.

Multiplexing and controlling many LEDs with as few pins as possible is well plowed ground.    The Internet is full of ideas, circuits, and code.  After much, much research, I decided a traditional matrix was the best solution.

“Requirements”

The power tower is approximately 25 inches tall.  I felt it would look very odd with only one side lit so I decided I wanted to have LEDs on all 4 sides.  I also determined a single strip of LEDs per side would look very odd.  So I settled on a column of LEDs on each corner of the tower, working out to 8 strips of LEDs, approximately 25″ long.

I designed and manufactured some LED strips for my research with multiplexing (shown below).  The strips are each 3.625″ long, with 6 groups of 3 LEDs each, totaling 18 LEDs per strip.  That means 6 outputs per strip and a common anthode.

LED Strip Schematic v1.0

LED Strip PCB v1.0

Here’s where the real world enters and I start doing the math.  25″/3.625″ = 6.89 strips; I’ll round down and make it 6.  8 columns x 6 strips/column = 48 strips.  18 LEDs/strip = 864 LEDs.  Holy crap.

Ok, so despite the Internet being full of a lot of useful information, nothing I came across led to a matrix of 864 LEDs. Further complicating the situation, my LEDs were grouped in 3’s and powered by 12 volts instead of the more “traditional” 5 volts.  I’ll get to why that’s important later.

I determined none of the “out of the box” solutions would work for me.  I needed more drivers than the solutions provided, or I required more current than the solution offered.

In Part 2, we will discuss the design and the build.