Henne’s DMX LED matrix schematic (click to download PDF).

Anyway, I fell back on my – ahem – process: first, draw the circuit in Adobe Illustrator and then build it on a breadboard.

(I have been asked in the past why I use Illustrator and not a regular schematic-drawing application such as Eagle or McCad. My first line of defense is the same as when I’m asked why I use InDesign to make slides rather than use the ubiquitous Microsoft PowerPoint: I use the Adobe Creative Suite on a daily basis and am something of an expert with its components. I can create a schematic [or slideshow] faster with the Adobe product than with anything else. Secondarily, I think I get a much better, graphically pleasing, schematic from Illustrator.)

So, there are some changes in this version of the schematic that aren’t electronically or function-driven: instead of the 10-position DIP switch, I have substituted a 2×10 header. This will save only a few cents (around 50) on the bill of materials, but will save some space on the board as well.

These switches signal to the ATMega8515 the DMX start channel to use. They’re set infrequently (probably only once a holiday season, maybe less) and the user (probably someone as unsophisticated as me) needs only to shunt the correct pairs depending upon the channel. How do you calculate the DMX start address? Just Google “DMX DIP switch calculator”.

Also, I eliminated a couple of superfluous components, including the potentiometer, its associated resistor and the J3, J4 and J5 headers (which are now direct connections to the shift register (74HC164).

The additional set of goodies that makes this an LED matrix circuit are the shift register, serial-in, parallel-out chip (U3 – the 74HC164), which in turn drives the sink chip (U4 – the ULN2803A). The shift-register gets us six extra wires (taking the two serial ouput lines and turning them into eight), while the sink-chip (a Darlington transistor array) allows the current load to increase to 500mA per line.

Otherwise, this is the exact same circuit as the transceiver.

Because I’m overtly ambitious, I’m going to redraw this circuit one more time – in McCad PCB-ST, so that I can make Gerber files and then, onward, to a printed circuit board.

Woo-hoo.

Henne’s DMX transceiver schematic (click to download PDF).

So, I’m working on an idea (I’ll post more when I get closer to the finish) that I want to add to my Christmas lights show, and it therefore needs to talk DMX. Numerous previous postings here will tell you that would mean I’d need to do this on an Atmel chip. Though there are a lot of DMX projects done on Microchips (PICs), fewer have been done on Atmels. And pretty much everyone who has done DMX on the Atmel has based some or all of their work on that of Hendrik Hölscher.

Fortunately for those monolinguists among us, Hendrik – who goes by “Henne” – writes in both German and English. He’s also moderately active on one of the Christmas lights forums.

My initial plans were to write my own code to get my idea off the ground; a few months(!) of fiddling around and I was never even able to pull off my main effect, no less receiving DMX.

During that fiddling, I ran across a web site in Germany that sold a bare printed circuit board for Henne’s basic DMX transceiver. It took PayPal, so I bought a couple of boards. And the next time I dropped by Jameco, I took along the bill of materials for the transceiver and bought the parts.

Then life intervened. It wasn’t until earlier this month that I got back on track on this project, which started out with a redrawing of Henne’s schematic. I then wanted to build the circuit on a breadboard. The design requires an external crystal and while I knew of the potential to “brick” the 8515, I didn’t think said bricking would be quite so easy.

So easy, in fact, that I bricked two.

The problem (for me, anyway), was a lack of understanding of terminology. While I’d started out using AVRDude on the command line, I somewhere along the line stumbled across AVRFuses, a Mac application that puts a graphical user interface on top of AVRDude.

Anway, AVRFuses uses the same terminology as FuseCalc and I find (found) both of them to be opaque. Suffice it to say, the 8MHz crystal used in Henne’s design is designated as “Ext. Crystal/Resonator Medium Freq.; Start-up time: 16K CK + 4 ms; [CSEL=1101 SUT=10].”

So, another trip to Jameco and this new-found knowledge (thanks Limor) and I had a functioning 8515.

But not a functioning circuit. The version displayed here clearly shows a ground on Pin 5 of U2, the 75176B, as well as five-volt power to Pin 8. Well, apparently some schematic-drawing programs don’t indicate such niceties and the drawing I was basing my work off of didn’t. So I sat here for almost two days, banging my head against the wall trying to figure out why the breadboarded circuit didn’t work. I wonder if I would have ever figured it out without help.

As Henne says, this is a simple circuit, with virtually all the heavy lifting happening in the software of the 8515. Suffice to say, U2 (the 75176B), an RS485 transceiver, receives the DMX signal and turns it into something the UART on the 8515 can read. The 8515, in turn, processes the signal and outputs it onto pins 32-39 (unless one of the many options is chosen, in which case signals can come out of the J4 Spare port as well).

Henne doesn’t explain why he chose the 8515 – it’s a big chip, taking up quite a bit of board real estate, and it’s not inexpensive (I’m too lazy to look it up, but I’m pretty sure that last winter when I bought the first set of these chips at Jameco, they were $4.50+/-; last week’s purchase they had gone down to $3.50. I just looked them up and at Mouser and Digi-Key, they’re $5.27). But for an eight-channel project (potentially 16-channel) that has DIP-switch control of the DMX start channel (another 10 pins), this really can’t be done in less than a 40-pin chip.

(Oh, and a note on the licensing: I had included my standard Creative Commons, Noncommercial Share-Alike license on the schematic and Henne asked that I remove it. In deference to the original author, I did. None of his schematics have licenses on them and he wrote, “You cannot license the schematic under cc since its based on my schematic / hw where unauthorized commercial production is prohibited. [This is necessary if some companies produce the boards in larger quantities...] I don’t want anyone to get into trouble…” Now you know what I know.)

Using Henne’s “board.hex” testing software, the red LED flashes a steady beat once power is applied; turning on DIP 2 (or, as in my case, shorting Pin 22 to ground), the green LED should light if the crystal fuses are set correctly.

Anyway, I finally got the circuit working on Saturday. Now, to add a couple of sub-circuits and get this idea – which I’ve been working since December 2007 – afloat.

ATTiny13 drives 5 LEDs; programming/test circuit (click to download PDF)

I spent a lot of time with some code that had been created for a Microchip PIC12F675 but it turned out that it was merely random on-off, not fading the way a flickering candle operates. I then spent some time with a second code set, also for a PIC12F675, that did fade nicely, but which had a problem with brightness that I was never able to rectify (it is a duty-cycle issue, I know; I just don’t know how to fix it).

But that second code set did point me in the direction of how to control individual LEDs while within a loop, using bitwise manipulation.

I decided on Sunday that I had a few hours to work on this project and I wanted it finally finished. While the result is not exactly what I wanted, it will suffice.

What I’ve built is a group of four LEDs that fade in and out in an inverse manner. While LED1 fades in, LED2 fades out and LED1 and LED3 work in synch, as do LED2 and LED4. So, when LED1 and LED3 fade out, LED2 and LED4 fade in and when LED2 and LED4 fade out, LED1 and LED3 fade in. It is random enough – and fast enough – that you can’t really tell they’re working inversely.

ATTiny13 drives 5 LEDs; production circuit (click to download PDF)

The fifth LED staying on all the time helps by keeping the candle from ever going completely dark. This effect would work just as well with only three LEDs, but the two extras throw off more light.

The finished code is at the end of this article.

In the prototype I’m using 10mm warm white LEDs that are rated at 85,000 millicandles; they have a 3.3-volt forward voltage, so I’m using 100-ohm, one-eighth watt resisters between the five pins of the microcontroller and the positive leg of the LED.

I have provided two circuit schematics; one is for a circuit to program and test the ATTiny13; the other is an operational circuit. I will be using this candle on my backyard railroad; you can see how I built the other flickering lights on the railroad here and you can assume I’ll use a similar plastic-canistter/wood/glue/screws building technique for this.

These schematics don’t detail the circuit that takes the raw Malibu 12-volt AC of my layout and turns it into filtered, five-volt DC for the microprocessor and LEDS; you can rest assured I built something eerily similar to this circuit.

I will build both circuits on a piece of RS project board, though I plan to attach the LEDs with one-inch long wire in order to be able to point them in various directions.

I’ve provided a video of the LEDs, one scene where they’re running on the breadboard bare and a second with a plastic canister, to give you an idea of how they will look on the layout.

/*
* Digital candle V2
* -----------
* Use random numbers to emulate a flickering candle on five LEDs without hardware PWM 
* 
* David M. Cole <dmcole at dmcole dot net>
* License: 2009 Creative Commons Attribution-Noncommercial-Share Alike 3.0 U.S.
* Target: ATTiny13
* Compiler: AVR-GCC
*/
 
#include <avr/io.h>											// Defines pins, po
#define led1_on PORTB |= 1 << 0										// PortB0 = on
#define led1_off PORTB &= ~(1 << 0)									// PortB0 = off
#define led2_on PORTB |= 1 << 1										// PortB1 = on
#define led2_off PORTB &= ~(1 << 1)									// PortB1 = off
#define led3_on PORTB |= 1 << 2										// PortB2 = on
#define led3_off PORTB &= ~(1 << 2)									// PortB2 = off
#define led4_on PORTB |= 1 << 3										// PortB3 = on
#define led4_off PORTB &= ~(1 << 3)									// PortB3 = off
#define led5_on PORTB |= 1 << 4										// PortB4 = on
#define led5_off PORTB &= ~(1 << 4)									// PortB4 = off
 
//	Declare variables
//	==============================================
	uint8_t y, z, i, j;
//	==============================================
 
	int main(void)
		{
			DDRB = 0b11111111;								// PortB all outputs
 			for(;;)										// loop forever
 				{
					y = rand(1,255);						// bottom of first loop
					z = rand(63,255);						// top of first loop
					for (i = z; i < y; i++)						// first fade loop
						{ 
							led1_off;
							led2_on;
							led3_off;					// set up for first fade
							led4_on;
							led5_on;					// led5 is always on
							for (j=0; j < y; j++)
								{
									if (j > i)
										{
											led1_on;
											led2_off;	// turn off lamps that were on
											led3_on;	// turn on lamps that were off
											led4_off;
											led5_on;	// led5 is always on
										}
								}
							}						// end first fade loop 
					y = rand(1,255);						// bottom of second looop
					z = rand(63,255);						// top of second looop
					for (i = y; i > z; i--)						// second fade loop
						{
							led1_on;
							led2_off;
							led3_on;					// note lamps swap state
							led4_off;					// from first loop
							led5_on;					// led5 is always on
							for (j=0; j < y; j++)
								{
									if (j > i)
										{
											led1_off;
											led2_on;
											led3_off;	// and again, change state
											led4_on;
											led5_on;	// led5 is always on
										}
								}
						}							// end second fade loop
				}
		}

Schematic of circuit to fade, flicker single LED (click to download PDF)

The first solution to that problem was to modify LED tea candles — readily available at crafts stores and even Walgreens — so that they would work off of standard 12-volt garden lighting (aka: Malibu lighting).

The dirty little secret of that method is that all the tea candles flicker at the same time. I’m not quite sure why this is so — perhaps the proprietary microcontroller used in those devices is time based and since they all start at the same time, they seem to work in synch? In any event, it does make looking at all the “fires” on my layout pulse at the same time.

So, in the back of my mind, I knew I wanted something besides tea lights to make flickering light on the layout. I kept looking around the net, and in January a reader of the backyard illumination site pointed me to an Instructables that showed a circuit to increase the current that could pass through a tea light, allowing up to four LEDs to be driven in the circuit.

The Instructables site provides a “related” window in the right-rail and along with the increased current circuit there were a couple of other “LED candles” that caught my fancy.

One, which by March seems to have been removed from the site, used the concept of the linear feedback shift register to control the flickering. Unfortunately, it was written for a Pic12F675, not an AVR (reading the datasheets, I decided that an ATTiny13 would be the equivalent controller).

What I liked about this idea was that it utilized seven of the eight pins of the microcontroller — it drove five LEDs (which is five of the pins and one each for power and ground). There were other circuits on the ’Net and Instructables that used just one LED, but none used all five (this was in January).

So, I bought a handful of ATTiny13s at Jameco and set about to build the circuit and convert the code.

I didn’t really get anywhere. So, I started writing my own code. For the first shot, I decided to control just a single LED (crawl before walking).

The circuit illustrated above and the code below do that. What’s different (it turns out) from what I’ve done here and what others around the ’Net have done is that I’m fading the LED from dark to bright in a random manner.

I do this without using hardware pulse width modulation (PWM); I chose to skip hardware PWM because of the way the ATTiny13 is configured: the PWM pins are also the pins that are used for programming. To use hardware PWM I would have had to program the chip, power down the circuit, connect the LEDs, run the program and to debug, do the steps in the opposite order.

Easier to write my own PWM code, I thought …

The code makes (to my eye, at least) a more realistic candlelight flicker. But, it is just one LED and while that might be enough for somebody else, I’ve got four more pins to use in this project and I’m going to figure out how to use them.

I’m working with another developer over at Ladyada forums and I hope to have a five-LED version of fading code work on an ATTiny13 shortly.

For now, though, here’s Version 1, the single LED fading digital candle:

/*
* DigitalCandle -- Version 1
* -----------
* Use random numbers to emulate a flickering candle on a single LED without hardware PWM
*
* David M. Cole
 
* License: 2009 Creative Commons Attribution-Noncommercial-Share Alike 3.0 U.S.
* Target: ATTiny13
* Compiler: AVR-GCC
*/
 
#include 														// Defines pins, po
 
//	Declare variables
//	==============================================
	uint8_t x, y, z, i, j;
//	==============================================
 
	int main(void)
		{
			DDRB = 0b11111111;										// PortB all outputs
 			for(;;)												// loop forever
 				{
		 			x = 4;
					y = rand(1,255);
					z = rand(63,255);
					for (i = z; i < y; i++)								// the fading in loop
						{
							PORTB = 1 << x; 						// light on
							for (j=0; j < y; j++)
								{
									if (j > i)
										{
											PORTB = 0 << x;	 		// light off
										}
								}
							}								// end fade in
					y = rand(1,255);
					z = rand(63,255);
					for (i = y; i > z; i--)								// the fading out loop
						{
							PORTB = 1 << x;							// light on
							for (j=0; j < y; j++)
								{
									if (j > i)
										{
											PORTB = 0 << x;			// light off
										}
								}
						}									// end fade out
				}
		}

Sample schematic to connect ATMega8 to 6-pin ISP (click to download PDF)

In 2008 I learned a little about Microchip’s PIC series of microprocessors because that was the favored chip by most of the developers in the DIY Christmas lighting world. Though I didn’t actually program PICs, I did learn how to burn HEX code into them using an ADM programmer. These too, had a drawback: you had to write the code and program the chip using, ugh, Windows.

Along the way, though, I heard about the AVR series of chips from Atmel Corp., which had a distinct advantage over PICAXEn and PICs: there was a small community of people who used Macintoshes to make them go. There was a full tool-chain for programming in C (a language I had no experience in) and there were USB devices that allowed for burning the code. Well, hello, sweetheart.

So, somewhere along the line in 2008 I bought myself an USBtinyISP programmer from Adafruit Industries; today’s price in March 2009 is $22 but I think I paid a little less for it than that. I didn’t build it after I got it; the board and components sat unworking for a couple of months while I finished the Christmas lights.

But once the lights were up and running, I decided to get moving on learning to program an AVR in C (maybe someday I’ll tackle assembly code, but I’m really a path-of-least-resistance guy). My first step was to set up a breadboard and get a chip in a position to program.

And herein I ran into a small problem: I had bought a bunch of ATMega8s to learn on and lo and behold, I couldn’t find how to connect a USBtinyISP to a Mega8.

Through trial-and-error and posting questions on Adafruit’s forums, I worked out a method to hook them together, but thought it would be worthwhile to post here not only the method, but draw up a schematic as well.

I should point out that for my initial set up I used a six-pin header that I soldered to six wires, which I then plugged into the breadboard; today I would advocate buying the header adapter sold by Sparkfun Electronics. Though initially designed to be an interface between 10-pin and six-pin headers, it has been adapted to allow you to put a row of header pins into one side that can plug directly into a breadboard. They’re only a buck, so I was forced to buy some other stuff to justify the postage …

The code that I wrote for the ATMega8 is pretty rudimentary (it flashes a single LED) but I reproduce it here for full disclosure.

/* Name: main.c
 * Author: David M. Cole
 * License: 2008-2009 Creative Commons Attribution-Noncommercial-Share Alike 3.0 U.S.
 * Target: ATMega8
 * Compiler: AVR-GCC
 */
 
#include <avr/io.h>									/* A file that defines inputs and outputs */
 
void delay_ms(uint16_t x)								/* Declare substitute delay function, bring in variable x */
	{
		uint8_t y, z;								/* Declare the variables y, z */
		for ( ; x > 0 ; x--)							/* Loop while x is less than zero; decrement */
			{
				for ( y = 0 ; y < 90 ; y++)				/* Loop while y is less than 90; increment */
					{
						for ( z = 0 ; z < 6 ; z++)		/* Loop while z is less than six */
							{
								asm volatile ("nop");	/* Inline assembler code: no operation performed; i.e.: do nothing */
							}
					}
			}
	}
 
int main(void)										/* Main function; every program has a main */
	{
		DDRD = 1 << 4;								/* make Pin 6 (PortD4) an output */
			for(;;)								/* Loop like forever */
				{
					char i;						/* Define the variable i */
					for(i = 0; i < 10; i++)				/* Loop while i is less than 10 */
						{
							delay_ms(50);			/* Hang on for a moment */
						}
					PORTD ^= 1 << 4;				/* toggle the LED; if it's off, turn it on */
				}
		return(0);								/* never reached */
	}