Alan's Ramblings - spi tag

Connecting a HL1606 strip to an ATmega

Wed, 09 Mar 2011 23:29:00 GMT

I've been left a comment asking how the HL1606 strips are connected up to an Arduino. The wiring is really pretty simple, but depends on exactly which ATmega version you have, as the hardware SPI pins vary from MCU to MCU. The following assumes it's a ATmega328P as used on the more modern Duemilanoves, you'll need to refer to the MCU documentation and the board schematic to find the correct ports and pins for different Arduino versions.

The 328P uses the following pins for hardware SPI:

/CS    Port B Pin 2    (Arduino pin 10)
MOSI   Port B Pin 3    (Arduino pin 11)
MISO   Port B Pin 4    (Arduino pin 12)
SCK    Port B Pin 5    (Arduino pin 13)

I used Timer 2 to drive the fade clock on the strips. The output of Timer 2 uses the following pin:

TIMER2 Port B Pin 1    (Arduino pin 9)

The strips themselves have the following labelling on the inputs:

S-I    Fade clock input
D-I    Data input
CK-I   Data clock input
L-I    Data latch input

So you need to wire up the strip as follows:

ATmega      Strip
/CS     to  L-I
MOSI    to  D-I
SCK     to  CK-I
TIMER2  to  SI

Note that if you want to wire up more than one strip you'll need to work around the fact that the HL1601 strips don't implement the SPI protocol properly. The easiest way is to gate the SCK signal with the /CS line so that when a strip is not being accessed it doesn't see the data clock. I've detailed the problem and the solution more fully in this earlier post,

Radio-controlled HL1606 strips

Sat, 15 Jan 2011 18:07:19 GMT

Well, I've finally finished the design and implementation of the radio-controlled LED strips I've been asked to make for The Travelling Light Circus. It's taken far longer than I expected, but I've learned an immense amount in the process. The remaining tasks are to construct some more boards, put the boards into suitable enclosures and to sort out how best to package and connect the strips, so now seems like a good point to write up what was involved in the project. Some of the items are worthy of posts of their own, but first I'll give an overview of how everything fits together. The system is composed of two parts, a single controller and a number of LED strip drivers. The controller is used to select the required pattern and to synchronise the LED drivers, with the communication being done with 2.4GHz radio transceivers. I've put a video together to show everything in operation, and there are some annotated photos of the controller and LED strip drivers at the start.

Hardware

As I've said, the hardware consists of two parts, the controller and the LED strip driver. At the moment these are made using discrete parts on a hand-built breadboard, but version 2 will be a PCB with most of the components mounted directly on the PCB.

Controller

The controller consists of the following parts:

Arduino Pro Mini. This uses a ATMega328p microcontroller and runs the controller software.
4-digit 7-segment display, from SparkFun. Whilst this works, getting it to work cause me an inordinate amount of problems, as I documented in an earlier post.
Voltage regulator - a 7805, which I've discussed in an earlier post.
nRF24L01+ radio transceiver. This a a reasonably complicated SPI device, capable of working in several different modes. I'm using a breakout board from SparkFun, but in future revisions the radio chipset will probably be integrated onto the controller PCB.
A rotary encoder/switch used to select and activate the required pattern. I've already discussed this in an earlier post.
A simple voltage divider to sense external battery voltage and shut down when the battery is discharged.

LED strip driver

The LED strip drivers consist of the following parts:

An Arduino Pro Mini. This runs the software that drives the LED strips.
A nRF24L01+ radio transceiver, which receives the control and timing messages from the controller.
74125 glue logic to make the HL1606 strips behave like proper SPI devices. Despite the manufacturer's claims they aren't true SPI devices, a topic that I covered at length in an earlier post.
Voltage regulators - two 7805 linear regulators. Two are needed to provide the 4 amps that is required to drive the 4 LED strips. In future revisions this will probably be replaced by a switched-mode supply as the 7805s get very hot under high load and are quite inefficient, both of which are issues for portable use.
A simple voltage divider to sense external battery voltage and shut down when the battery is discharged.
A thermistor used to sense the temperature between the regulators. When it reaches 60C the strips are turned off to protect the hardware. When it drops back below 40C the patterns are resumed.

Software

The software is the most complicated part of the system, and it's divided into four main parts, described below. The various parts of both the controller and LED driver are implemented as tasks, implemented using the task manager described in the library section below.

Library code

This is code that is used in the LED strip project but that is used in other projects as well.

SPI master library

The nRF24L01+ radios, the 7-segment display and the LED strips are all SPI devices, so it seemed useful to abstract the core SPI master functionality into a separate library.

nRF24L01+ driver

This driver builds on top of the SPI master library and provides access to the low-level nRF24L01+ functionality such as device configuration and message transmit/receive.

Task library

This library has been described in an earlier post. It is a simple non-preemptive task scheduler with fixed priority scheduling and a 1 millisecond timer tick. It is available for download from here.

Common code

This is code that is specific to the LED strip project, but that's shared between both the controller and the LED strip drivers.

Global configuration and LED strip colours

Some aspects of the system such as the colour definitions for the HL1606 strips, timing intervals, radio channels etc are shared between the master controller and the slave LED strip drivers.

Radio message

This is a simple definition of the control messages that are sent from the master to the slaves.

Pattern animator

Both the master and the slave units run the same pattern animation code. In the case of the master, the output is a series of synchronisation radio messages that keep the slaves in synchronisation. In the case of the slaves, the output is a series of SPI commands that drive the LEDs. This means that if a slave temporarily loses the radio signal from the master, it will continue to display the pattern. The resonators used on the Arduino pro Mini boards are not very stable, so in early testing it became apparent that the slaves would have to be kept in synchronisation by the master. To achieve this, the master sends a constant stream of synchronisation messages no more than 13 milliseconds apart to ensure the pattern generators in the slave remain in step.

Animation output and animation fade clock base classes

As the master and the slave are both running the same animation code, the animation output and fade clock output code were implemented as empty base classes, with the master and slave providing implementations appropriate to their roles in the system.

Pattern definitions

As has been noted, both the master and the slave run the same pattern animation code, so they both need access to the pattern definitions. Each of the 4 strips on the slave are animated separately, so the pattern definitions are a reasonably complex tree of data structures containing colour, movement and timing information that are interpreted at run-time. The pattern definitions are too large to fit in the ATmega's limited 2Kb of SRAM, so they are stored in program memory and the subset necessary for the current pattern step is extracted into SRAM and interpreted at run time.

Master controller

The software in the master is implemented as a set of tasks, implemented using the library descried above. The main program simply initialises the tasks before transferring control to the task scheduler. The tasks are as follows:

Display driver task

This manages the 7-segment display described in the hardware section above. Updating the display is not time-critical, so updates are made by saving the new display contents and scheduling the display update when no other high-priority tasks need to run.

Radio transmitter task

The radio task is responsible for transmitting the synchronisation messages via the nRF24L01+. Transmitting a message consists of storing the message details and scheduling the transmitter task to run. When it runs the message is transferred to the radio via SPI and transmitted. As synchronisation is key to the correct operation of the slaves, this is the highest-priority task.

Four animation synchroniser tasks, one per strip

These are derived from the Animation output base class that is defined in the shared code section. They are called by the pattern animators when the next step for an animation pattern needs to be output, at which point they queue a synchronisation message that is subsequently send by the transmitter task to the slaves.

Four pattern animator tasks, one per strip

Each strip is animated separately, so each requires its own animator instance. The animators extract the pattern definitions from PROGMEM and interpret them. At each new step the animators call the synchronisation tasks to output the appropriate synchronisation message.

Encoder/switch handler task

The rotary encoder and switch need to be read and debounced as described in this post. This task is responsible for doing that.

Voltage monitor task

The voltage monitor task samples the battery voltage every second via a voltage divider. Once the battery voltage drops below a certain level, the subcomponents of the master are powered down and the ATMega is put into suspend mode.

Interaction and pattern switching objects

These objects simply marshal and redirect the internal messages between the various tasks. They are called directly by tasks and call non-blocking operations on other tasks, although they themselves are not implemented as tasks.

Slave LED strip driver

As in the master, the software in the slave is implemented as a set of tasks, implemented using the library descried above. Again, the main program simply initialises the tasks before transferring control to the task scheduler. The tasks are as follows:

Four LED strip driver objects, one per strip

These are called by the pattern animators when the next step for an animation pattern needs to be output, at which point they output the new LED settings to the strips via SPI. They aren't tasks as they merely transmit the LED setting bytes to the strips.

LED clock object

The LED strips need a fade clock to drive the pattern fades as described in this post. This object manages the internal ATMega timer that is used to generate the fade timing clock pulses.

Four pattern animator tasks, one per strip

Each strip is animated separately, so each requires its own animator instance. The animators extract the pattern definitions from PROGMEM and interpret them. At each new step the animators call the LED strip driver objects and the LED clock object to output the appropriate synchronisation message.

Radio receiver task

This task receives the incoming radio messages from the master, decides which strip they refer to and makes any necessary adjustments. This could be to switch to a new pattern, to adjust the current pattern step of a strip if it leads or lags the controller, or to adjust the delay until the next pattern step if the clocks on the master and the slave have drifted.

Voltage and temperature monitor task

This task samples the battery voltage and temperature every second via a voltage divider and a thermistor. Once the battery voltage drops below a certain level, the subcomponents of the slave are powered down and the ATMega is put into suspend mode. If the temperature exceeds 60C the strips are turned off until the temperature drops below 40C, at which point the pattern output will be resumed.

Summary

This project is reasonably complex for a microcontroller - about 5000 lines of code with the master and slave binaries both being 13K in size. There are a number of non-obvious design constraints and decisions that I haven't had space to fully explain in this post, I'm intending to write some follow-ups to explore those areas in more depth.

Waiting for O(1)

Tue, 19 Oct 2010 17:14:11 GMT

Due to a misconfiguration the notification emails from my blog weren't reaching me, so I missed a couple of interesting comments on my earlier HL1606-related posts. The ones from Dan from over at Waiting for O(1) were particularly interesting, and he's written a SPI library for driving the HL1606 as well as other similar LED drivers such as the LPD6803 and WSC2801 - if you are looking for alternatives to the HL1606 he has some links on the googlecode page for his project. Dan is actually doing PMW fading of the strips, so he's driving them via timer-generated hardware interrupts. Dan has a lot of useful tips and observations about speed and power limitations he's run into and how he's solved them that are well worth checking out, check out his blog.

SparkFun are less than electrifying

Sat, 28 Aug 2010 19:10:57 GMT

As part of my LED strip project I needed a 7-segment display capable of displaying two or more digits. I could have built something myself, but I'm short of time as it is so the SparkFun kelly green seven-segment serial display seemed like a good trade-off between cost and speed of implementation. It can be driven either over a serial link or via SPI. SparkFun also do the same unit in yellow, red and blue. The units use a ATMega328 to drive the display, which is the same microcontroller that's in the Arduino Pro Mini's that I'm using for the project. I therefore bought two of them from one of SparkFun's distributors in the UK.

As I'm already using SPI for most of the peripherals, the obvious thing to do was to use the display's SPI interface to drive it. I spent an absolute age trying to get the display to work, but no matter what I tried, the output on the display was a seemingly random collection of characters and garbage. After a lot of wasted time I eventually got it to work most of the time by dropping the SPI clock rate down from the specified 2MHz to 0.5MHz, but even at that it was still glitchy.

I tried unsuccessfully over a period of several weeks to get some help from SparkFun with the problems I was having, first trying the SparkFun IRC channel, then an unanswered question on the product page and then and equally unanswered forum post. In the end I emailed their tech support group, and finally got a response. A 30-mail thread then ensued, with the tech support person playing piggy-in-the-middle between mself and the SparkFun engineer who is responsible for the product. They had no clue as to what the problem was - initially I suspected that the CLKDIV8 fuse bit had been mis-programmed as the SPI interface would only work at approximately 1/8th of the specified clock rate, but as I didn't have anything capable of reading them I couldn't be sure. Plus, if that was the case I'd expect the serial interface not to work properly either, which wasn't the case. The engineer then said he thought that the problem was that the boot loader fuse bits were wrong. I thought that was hokum as the device doesn't use a boot loader, but they wanted to send me two new units with the 'fixed' fuse bits which they assured me would fix the problem. I asked instead if they could send me a STK500 programmer instead so I could fix the fuse bits myself and end up with something I was probably going to buy anyway but they refused because it was "Too difficult" to arrange. I wasn't happy, but agreed to try two new displays.

The displays duly arrived, and to my complete lack of surprise they were just as broken as the original ones. I fed this back to SparkFun tech support who duly admitted they were completely stumped. Great.

I then did something I should have done in the beginning, and downloaded the firmware source for the displays and had a look, at which point the cause of the problems became immediately apparent. Oh boy, what a complete pile - probably some of the shoddiest code I've seen in quite some time. Here's a brief description of the issues I found:

The immediate cause of the problem is the ISR that services the SPI interface. The ATMega328 is being clocked at 8MHz using the internal oscillator, and when in slave mode the maximum SPI data rate is FCPU/4, i.e. 2Mhz. Each SPI transaction transfers one byte, which works out at 32 CPU clock cycles per byte. That means the ISR has to use less than 32 clock cycles if it isn't to drop data. The ISR in the code is much longer than that, not least because it calls a two-page subroutine for each processed byte!
The firmware consists of one .c and one .h file, with all of the global variables and about a quarter of the functions being defined in the .h file rather than the .c file. Huh?
Globals are shared between the ISRs and the main loop without any of them being declared volatile. Plus there's no locking whatsoever around any of the shared multibyte globals - see the avr-libc documentation for an explanation of why this is a problem.
Many of the globals are unnecessarily long, e.g. 16 bits to hold a value that ranges from 0 to 4. Also, multiple variables are used where a single state variable would be sufficient.
The timer delay code is completely bizarre. There's a delay_us() microsecond delay function that takes a delay of up to 2^16 microseconds, yet the delay_ms() millisecond delay function consists of a string of four delay_us(250) calls in a loop rather than a single delay_us(1000) call. No idea why. Oh, and the comments (such as they are) make absolutely no sense.
There are many other doozies as well, for example switch statements that only have 1 case, blocks of code where some members of a set of conditionals are handled by a switch block and others are handled by if statements,

I proved that the ISR overrun was the cause of the problem rather than the SPI data rate by leaving the SPI data rate at 2MHz in the master and inserting a delay between each SPI transaction. With a 15msec delay, the driver ISR can keep up and the display works correctly.

I fed back the information about the ISR overrun to SparkFun, and included pseudocode for a suggested fix. The reply I got back was that the engineer had "checked the clock speed again and claimed that the SPI bus was talking at 2MHz". Well duh - yeah. I also asked when I could expect a fix, the reply being that the tech support person had asked the engineer and that "he said it is on his list to review and rewrite the ISR. So no ETA, could take months.". I pushed back again, saying that at least the product pages and datasheet should be updated. As of writing, the product pages still don't note this issue, but the datasheet has been updated to say that the SPI interface won't run above 250kHz, so that's one small step, at least.

I really don't think this sorry saga is acceptable. Yes, SparkFun has offered me a refund, but I'm not quite sure how that's going to work out when I bought the parts via a distributor - when I asked for a STK500 as compensation, they cited the fact that I'd gone through a distributor as a reason why I couldn't return the original displays to SparkFun. I've subsequently bought a STK500 anyway so when I eventually find the time I can fix the firmware myself and reprogram the displays, but I really don't think that having to go down that route is acceptable. Plus I've wasted many hours trying to get these bloody things to work, and in the end I diagnosed the faults in their product - their engineer had absolutely no clue as to why it didn't work.

As I was still unhappy with the response I'd had, I mailed their customer support manager just under two weeks ago, and as of the date of this post, I've still not had a reply, which is just adding insult to injury.

I've always been a SparkFun fan in the past, but no more. Their hardware seems fairly well put together, but if the firmware I've looked at is representative, anything with a software component is going to be of extremely dubious quality, Plus their tech support truly sucks - they had no clue about what the problem was, and as I said I've had no reply from the support manager,

Be warned.

AVR SPI gotcha

Sun, 13 Jun 2010 21:30:00 GMT

I've had all sorts of problems getting a SPI radio device to work for the last few days - I wasn't using the default /SS pin to select the slave as I was reusing some code from another program that already used the default /SS pin for a different device. For the life of me I couldn't figure out why I couldn't get it work reliably unless I used the standard /SS pin - if I used a different pin it sometimes worked, but most of the time didn't, or it just worked very slowly, or only if I waggled wires - most baffling. It's perfectly possible to drive multiple SPI devices using a different /SS pin for each, so I was completely stumped as to what was causing the problem. Eventually I noticed this in the documentation:

If /SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the /SS pin of the SPI Slave. If /SS is configured as an input, it must be held high to ensure Master SPI operation. If the /SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the /SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it.

And then the penny finally dropped - because I wasn't using the default /SS pin it wasn't being explicitly configured, which meant it was in the default post-reset state. The default post-reset state for pins is to be configured for input. That meant that any noise on the pin would trigger the logic that switched the AVR from SPI master to SPI slave mode, and things would apparently lock up, or generally start behaving oddly. It was easy enough to confirm this, I simply configured the default /SS pin to be an output pin, even thought I wasn't using it, and the problem went away.

Moral of the story: When using multiple SPI devices, always use the default /SS pin to control one of them.

Meta-moral of the story: Always re-read the documentation thoroughly when you have unexplained problems :-)