Lawrence's Musings

STM32 and DMX interfacing.

Introduction

I am in the process of building a DMX controlled LED driver, this is not to drive big LEDs but to provide a largish number of low power LED channels for use in controlling the mimic LEDs in switch plates in a home automation setup. I decided to start with a DMX controller as I had a working DMX lamp and could get an idea of the issues around what looks like a very simple protocol.

Architecture

The DMX protocol is relatively simple but with one slightly awkward issue, it uses a long break signal to syncronise the data stream. This break signal is longer than can be created by the hardware UART itself. The possibilities are: i) to use an additional GPIO to control the synchronization, ii) to switch the UART baud rate so it can create a suitable long break signal or iii) switch the IO pin from the UART to being GPIO during the synchronization phase. I chose to do the later.

I have a state machine that goes through a number of states, states 0 to 512 are the data phase states, states beyond 512 are the sync phase. We initialise the state machine into the synchronisation phase.

I have some code that uses the systick timer to call functions periodically so that the main loop for this code is just a continuous loop waiting for interrupts.

I use the transmit empty interrupt during the data phase and the transmit complete interrupt to switch to syncronisation phase.

Hardware

I used a couple of ST disocvery boards, the value line STM32F100 and the Cortex M0 STM32F051 board along with an RS422/RS485 driver chip. With my STM32 code I am aiming to be able to build it for more than one processor family so have copies of 3 of the STM standard driver libraries, the STM32F0xx, the STM32F1xx and the STM32L1xx.

Issues

What I find with ARM processors is that once you get the various IO blocks configured properly the rest just works. Remember to enable the clock to the the IO blocks you are using!

Suggestions

Have a signal that an oscilloscope can use as external trigger, i.e. the heartbeat LED should go on at a single known point in the protocol flow. I added this when I was having problems with the sync phase so I could trigger everytime I got there and see the data waveform.

Moving this to the little NXP LPC810, an ARM in an 8 pin DIP package. I see a little dongle that handles all the timing critical code connected to a controller host over serial.

Lawrence's Musings

Other articles

STM32 and the standard peripheral libraries

Other articles

social