Lava lamp project, part 2 — firmware

In part 1, I described the hard­ware of my project of a com­put­er con­trol­lable lava lamp. In this sec­ond part, I want to dis­cuss the nec­es­sary firmware, which is the soft­ware nec­es­sary to teach the Picaxe Micro­con­troller the desired functionality.

We need to keep two areas in focus:

1. We need to be able to read the desired col­or val­ues from the USB ser­i­al port, defin­ing the desired inten­si­ties of the col­ors green, red and blue.
2. These desired val­ues have to be turned into actu­al light in desired col­or and inten­si­ty. This means, the LEDs have to be turned on.

A few words about the Picaxe

The Picaxe has a pre­de­fined set of com­mands, which is sim­i­lar to BASIC and which is quite pow­er­ful. For exam­ple, a sin­gle com­man­nd can read in a row of input data assign them to mem­o­ry. But the proces­sor speed is lim­it­ed. This is under­stand­able, greater work­ing speeds would mean more heat dis­si­pa­tion and then the micro­con­troller would need cool­ing. This would sig­nif­i­cant­ly increase the effort required for design­ing a device with this kind of processor.

The Picaxe is avail­able in dif­fer­ent ver­sions, which dif­fer in pack­age size and spe­cial equip­ment, such as the num­ber of digital/analog con­vert­ers or pulse width mod­u­la­tors. The small­est mod­el is avail­able as a 8 pin dual-in-line chip and sports the fol­low­ing pin out:

• 2 pins for 5V and ground (pow­er supply)
• 2 pins for ser­i­al input and out­put. These pins are being used for pro­gram­ming and lat­er for trans­mis­sion of the desired col­or val­ues. They could also be used as nor­mal input or out­put pins if desired.
• 1 dig­i­tal input
• 3 very ver­sa­tile input/output pins with numer­ous spe­cial functions

Here is the data sheet for the PICAXE. 

The Picaxe has an inte­grat­ed devel­op­ment envi­ron­ment (IDE), called “Picaxe Edi­tor 6″, which can be used for devel­op­ing, sim­u­lat­ing and trans­fer­ring pro­grams to the Picaxe. There are cost effec­tive pro­to­typ­ing boards avail­able as well. I bought myself his board for my first attempts.

Functional principles of the firmware

The light­ing inten­si­ty of LEDs is not con­trolled by vary­ing the pow­er sup­ply volt­age (which could be done using a ana­log out­put), as is done for light bulbs. Instead it is done by vary­ing the width of puls­es at an appro­pri­ate fre­quen­cy fast enough so that the flick­er is not noticed by the human eye. The small Picaxe-08M2 used by me has one pulse-width-mod­u­la­tion (pwm) out­put, as can be seen in the above pin out. But that is only enough for one of the col­ors red, green or blue, not for all three of them. Only the sig­nif­i­cant­ly larg­er mod­els 14M2 or 20M2 would have 3, or even 4, pwm out­puts. For this rea­son, I have to pro­gram my own pwm out­put man­u­al­ly, which, alas, can only be done with lim­it­ed speed, which means that my LED flick­ers slight­ly. That is a pity, but it can not be avoid­ed with­in the lim­it­ed space. The larg­er Picaxe chips would require more space not avail­able inside the lava lamp.

To use the pro­cess­ing pow­er of the Picaxe as effec­tive as pos­si­ble, I built my firmware like this:

One big loop is repeat­ing for ever. Inside this loop, the fol­low­ing things are happening:

1. First, all three col­or LEDs are turned on, if their cor­re­pond­ing num­ber of duty cycles is greater than zero.
2. In an inside loop, which is always per­formed the same num­ber of times
3. …each col­or, whose duty cycle expired, is being turned off.
4. …also, we wait 3 Mil­lisec­onds for the begin­ning of an input datagram
5. If a char­ac­ter “C” is rec­og­nized, we jump to a sub­pro­gram, which reads the rest of the data­gram and recal­cu­lates and adjusts the duty cycles of each color.
6. After the num­ber of inside loop cycles is reached, we jump back to the out­er loop and the whole cycle starts from scratch.

 

The length of an out­side loop cycle deter­mines the amount of flick­er­ing of the LEDs. The short­er one out­side loop cycle, the less flickering.

The inside loop cycle length is deter­mined by the ser­i­al input wait­ing time, which has to be per­formed reg­u­lar­ly, in order to read desired col­or changes trans­mit­ted from the con­nect­ed com­put­er. The longer this wait­ing time, the more reli­ably data­grams will be rec­og­nized, but the more flick­er­ing occurs as well. I fig­ured 3 mil­lisec­onds should be quite ok. If dur­ing this time, a char­ac­ter “C” is noticed, we quick­ly jump out of the inside loop and per­form a subp­gram to read three more char­ac­ters, whose val­ue defines the bright­ness of the col­ors red, green and blue, respec­tive­ly. The pos­si­ble bright­ness val­ues go from 0 (“con­stant off”) to n+1 (“con­stant on”).

The num­ber of inner cycles defines the “flick­er fre­quen­cy” of the LEDs, inverse­ly pro­por­tion­al. This means: The less the LEDs are sup­posed to flick­er, the less times the inner loop can be per­formed, and the less num­ber of bright­ness lev­els are pos­si­ble. The more lev­els of bright­ness are desired, the more the LEDs will flick­er. I thought that 7 inner cycles make a use­ful compromise.

The ser­i­al port receives the desired col­or and bright­ness through a “data­gram” con­sist­ing of four bytes of data. Every data­gram starts with a “C”, and the fol­low­ing three dig­its define the num­ber of inner cycles for the col­ors red, green and blue. Here are a few examples:

• ‘C000’ — LED is com­plete­ly turned off, or dark
• ‘C888’ — LED is com­plete­ly turned on, or white
• ‘C800’ — LED is rot
• ‘C080’ — LED is green
• ‘C008’ — LED is blue
• ‘C440’ — LED is yel­low with about half intensity
• ‘C808’ — LED is pur­ple with full power
• ‘C740’ — LED is brown
• etc.

 

Unfor­tu­nate­ly, the ser­i­al receiv­er is not depend­able enough to receive every data­gram clean­ly. Most of the time, the com­put­er has to send the data­gram mul­ti­ple times until it is received. An acknowl­edge­ment is not cur­rent­ly imple­ment­ed in my code.

Possible improvements

The code could be made more flex­i­ble, for exam­ple by mak­ing the num­ber of inside loop cycles vari­able. With this, the com­put­er could reduce the flick­er, if only a few bright­ness lev­els are required.

An ack­owledg­ment mech­a­nism for sig­nalling suc­cess­ful recep­tion of a data­gram to the com­put­er would be use­ful so that it knows it can stop repeat­ing its last datagram.

Also, it would be nice to make the switch or key do some­thing, such as turn­ing the LED on or off, or start­ing a spe­cial col­or pro­gram on the LED.

You can, of course, also exper­i­ment with the adjustments:

• Clock fre­quen­cy of the proces­sor. Cur­rent­ly set to 16 MHz. The faster, the less flick­er. 16 MHz is the max­i­mum fre­quen­cy pos­si­ble for the Picaxe 08M2.
• Num­ber of inner loop cycles for one work­ing cycle. Cur­rent­ly 7. The less cycles, the less flick­er. The more inner cycles, the more lev­els of bright­ness are available.
• Wait­ing time for begin of data­gram. Cur­rent­ly 3ms. The longer this time the more reli­ably data­grams will be rec­og­nized, but the greater the flicker.

 

Listing

I don’t want to list the whole firmware pro­gram here. Just ask me, if you are interested