Posts Tagged ‘LED’


Misc updates


I’ve kindof neglected my blog for the past week, so I thought I’d post an update of what I’m up to.  Mostly I’ve been fighting with rebuilding the debugging console for my primary contract, updating it to support Bluetooth.  More on that in a bit, first the other various things I’ve done:

  • I’ve managed to get DMA working for DMX-512 transmission, after a bunch of bizarre fighting with both the DMA engine and GCC.  They conspired to blow about 3 hours of headbanging, compared to the roughly 15 minutes it took me to get the baseline write,wait,write,wait style working.  The next step will be to enhance it to use a timer and interrupts, so it can happen entirely in the background.  That should reduce the overhead of continuously sending a full DMX universe to about 0.025% of a 32MHZ chip!
  • Some more thinking about how to drive a large number of LEDs with BAM without using too many chip resources.  At this point I’ve got a theoretical configuration that drives 64 channels at 12 bit resolution at nearly 8KHz refresh (bits and refresh can be traded off) while using one timer, one DMA, and around 1KB of RAM.  All this should use 0.005% – 0.0075% of a 32MHz CPU….
  • Some quick tests with the QFP version of the Xmega-A4 board confirms that I can hook the anode of an LED to 3.7V and switch the cathode connected directly to the MCU.  Combined with a resistor for the red element, that means direct drive of RGB LEDS, as intended.  That makes the 64-chan RGB driver that much more viable, once I finish hotwiring my AVR-PDI screwup (I assume the data line could be shared between all the chips…)

As for my debugging console, it’s a Python beast designed to handle the overlap in serial port usage between debugging and bootloading.  The Arduino app does something a lot like this, but not nearly as slick.  The goal of the application is to provide full terminals for each of the devices hooked up to my system,  but allow AVRdude to reset and reprogram them as quickly and easily as possible.  In its original incarnation, terminals would be created for each expected device statically, and only if they were actually attached via USB would they be active.

In addition to providing the terminals, each instance created a socket for AVRdude to communicate with while programming the device.  These sockets answer and simply act as conduits (just like a serial port) to the device.  When the socket is connected, the console resets the device into the bootloader (either by command or by bit-banging the reset line on the FT232), then hands over control to the programming socket.  Once the socket closes, control switches back over to the terminal, and you see the boot screen from the program that was just uploaded.

The new version is designed to respond to devices as they connect, rather than constantly checking for particular units.  In addition, it must support both the rev2 boards which are FT232-based, and the newer rev3 boards, which use a Bluetooth serial module.  The biggest pain so far has been trying to coerce the Bluetooth stack to do my bidding.  It seems very fragile as far as connecting devices and various protocols (such as serial), so I’m having to be very rigorous with my error checking and whatnot.

A feature of my Bluetooth adapter boards is that not only are the serial debug lines attached, but two more are wired from the AVR-PDI interface (which includes RESET#) to GPIOs on the module.  I haven’t gotten the GPIOs to work fully yet, but the hope is that I’ll actually be able to implement an STK500 stack in the programming console that allows the installation of a bootloader on a bare chip.  This would be a handy place for my “logic helper” stack as well.

Anyway, back to the grind, currently toasting up another board stack so I have two complete copies of the rev3 hardware and can get back to bus testing.


PCB design showcase


A few minutes ago I sent an email to the dorkbotpdx mailing list offering to review and tweak people’s PCB to improve them as far as both aesthetics and immunity to assembly and interference problems.  The first example board ended up being Scott Dixon’s IR temp-controller board, which he’s posted on the dorkbot blog along with his original artwork.  The eventual goal is to develop a workshop with handout materials and live demonstration of what it takes to make a shiny-clean board.

However, I thought I’d also start posting some of my existing board artwork as examples.  Between these and the process of reviewing others’ boards, I hope I can help advance the “state of the Art” in the DIY electronics world.

The first board I’ll post here is one that I am actually starting to bootstrap and write firmware for right now, between working on my contract and spec “job” projects.

64-channel RGB LED controller

This is a 4×2.5″ board with 4 microcontrollers and a whole lot of header pins.  The ATXmega16A4 on the left is the master interface to the world, with the top-left 2×5 header providing VCC/GND as well as I2C, SPI, and serial interface options.  The 2×2 header is a debug serial port for development.  Bottom left 2×5 are for main V+ and ground to drive the LEDs.  A +3.3V regulator provides logic power for all 4 chips.  The 3 big uC’s are ATXmega128A1’s with 64 I/O’s each wired directly to the bulk headers.  Each column of 4 pins provides V+ and R,G,B cathode drivers for a single RGB LED.  The 3 main uC’s are connected to the driver uC via I2C for internal communications, and all 4 chips have their PDI programming interfaces routed to the 2×4 header on the right.

Identical software on each x128A1 will use Bit-Angle-Modulation to drive all 64 pins in 8 phased groups, controlled by the x16A4, which will interpret data from a variety of interfaces and formats up to the limits of flash size.  An x64A4 could be fit in the same place if the software gets too bulky.

The intent is to wire 5mm, 10mm, or Piranha-style common-anode LEDs to directly to 1×4 headers and plug them straight into the board.  Depending on the V+ fed to the board, one or more of the elements will need resistors.  A +3.6V supply would only require a single 60-ohm resistor  on the red LED.  Higher voltages can be used because the software will be switching the I/O drive rather than the level, and since they are being pulled to ground rather than up to a given voltage, I anticipate no problems with I/O’s going south.

I have 3 of these PCBs on hand, and one of them is currently populated and being bootstrapped.  I hope to be able to sell these as kits at some point, as this radically simplifies the task of building a large-scale display.  This design was posted on Hackaday today, and demonstrates the insane expense and lengths to which one has to go currently to drive a decent number of LEDs…


First-generation LED project


I first built LED lighting hardware around 3 years ago, after first reading about the BAM technique from Artistic License.  I ended up building a kit from scratch consisting of a controller and 8 fixtures.  The controller has 2 boards with ATmega8515’s each driving 16x 2N2222’s grouped in 4’s, with RJ-45 connectors.  The fixtures are 4x4x2″ enclosures with PCBs holding a total of 96 LEDs each, 24 each of red, green, blue, and white, again with RJ-45’s.  The first round of 4 fixtures were strictly resistive-ballast, while the second round used LM317’s in constant-current mode.  This coupled with a slightly higher drive voltage allows the fixtures to be strung on anywhere from 3ft to 100ft of standard Ethernet cable.

Last Christmas I decided to go a little overboard on the first tree of my own…  4 of the fixtures are embedded in the tree, while 4 more are behind the curtains as uplights.  Control is via DMX-512 driven by an ENTTEC Open-DMX USB bridge, with a cable running to my computer running custom color-changing code written in Python.

2008 Christmas tree