The goal of this project is to implement a basic DMX lighting controller using an EFM32 Giant Gecko microcontroller.

 

So, what’s DMX? DMX512 or 'DMX' is a serial protocol used in the control of lighting equipment. Traditionally for stage light dimming, its use has expanded to laser scanners, fog machines, actuators, residential holiday lighting, etc.

 

A few milestones were set to achieve the goal: 

 

• Verify my research of the DMX specification: Capture live DMX traffic on a scope using “loopback” DMX break-out terminators (provides access to the signal conductors) between a standalone DMX controller console and a DMX LED “PAR” Can

• Interface to external RS-485 transceiver chip and verify functionality: Giant Gecko STK running USART demo code driving external transceiver -> scope observation of D+/D-
• Develop software to implement simple DMX protocol traffic: Drive minimal spec-compliant DMX packet to transceiver -> verify timing by scope observation
• Demonstrate DMX lamp control in 7-channel mode: Drive 7-channel DMX Universe with GG STK -> verify expected lighting responses by LED “PAR” Can

 

DMX Communication

 

DMX communication is on a unidirectional network, and a DMX controller can drive between 1 and 512 devices in the serially connected 'DMX universe'. The protocol includes asynchronous serial data at 250 kb/s in 8N2 format and a DMX Packet which equals 8b frame for each channel in the universe.

 

1.png 

Figure 1. A single transmission (DMX Packet) includes synchronizing elements and channel data for up to 512 channels Image Source

 

2.png

 

Figure 2. DMX Packet Image Source

 

An example of a DMX device is an LED "PAR" Can Lamp, which can be operated in 3 or 7 channel mode.

 

  • Assign device to a specific DMX “base” channel
  • Reacts to DMX frames for base thru +2 (or +6) channels
  • In 3 channel mode
    • 1-3: Red, Green, Blue intensity (0:255 == 0%:100%)
  • In 7 channel mode
    • 1-5: Master dimmer, RGB intensity, Strobe rate (none:fast)
    • 6: if ch7=0 or >250, no effect; 0<ch7<251, sets cycle rate
    • 7: if >0, internal prgm; if >250, mic-activated program

3.png

 

4.png

 

 

Hardware Setup

 

5.png

Figure 3. “Off the shelf” DMX solution

 

6.png

Figure 4. EFM32 Giant Gecko-driven DMX solution

 

 

Software: DMX Packet Transmission

 

DMX Packet transmission was ported from DVK UART RS-232 example. DMX Universe stored in 513B array (StartCode + 512 channels).

 

  • GPIO: Minimum BREAK time exceeds max low-time of USART, so GPIO drives low while US1_TX is not EN
  • TIMER0: Overflows @ 22.8ms (~period for full 512-channel DMX Universe)
  • IRQ handler:
    • Enables US1_TX (overrides GPIO, idle TX drives high) for 1 TIMER0 cycle for MAB (Mark After Break)
    • Returns overflow to full 22.8ms period enables USART TX Buffer Level interrupt (fires TXBL interrupt)
  • USART1:
    • TXBL interrupt handling transmits all DMX frames in packet (walks DMX Universe array)
    • TXC interrupt handling detects end of DMX Packet, returns US1_TX control to GPIO for BREAK
  • Core sleeps in EM1 between interrupts

 

Software: DMX Packet Transmission

 

An array holds 6 sets of data for channels 2-7 of the DMX “PAR” lamp while Ch 1 (Master Dimmer) is left at 0xFF (no dimming) throughout.

  • GPIO:
    • Callback interprets pushbutton activity, writes one of 6 sets to DMX Universe
    • PB0 loads the next lower-ordinal set of channel data to the DMX Universe array
    • PB1 loads the next higher-ordinal set of channel data to the DMX Universe array

Updates to the DMX Universe are then transmitted during the next DMX packet.

 

7.png

DMX Packet: Set # 1

8.png

DMX Packet: Set # 2

9.png

DMX Packet: Set # 3

10.png

DMX Packet: Set # 4

11.png

DMX Packet: Set # 5

12.png

DMX Packet: Set # 6

13.png

 

Video

 

 

EFM32Giant Gecko DMX Control In Action!

 

Accomplishments

 

  • All milestones reached!
  • No isolation between EFM32GG STK and DMX bus-attached devices -> tying DMX bus GND to EFM32GGSTK GND caused USB debugger to lose enumeration
  • Leaving DMX bus GND floating -> EFM32GG maintained Host USB connection
  • USART/UART modules don’t support MTBF (Mark Time between Frames) but DMX lamp was functional when using minimum MTBF (0 sec) so no problem

Next Steps

 

  • Replace breadboard with a more robust soldered solution, arranged for minimum wire/trace lengths to minimize SI impact (relevant when driving more fully-populated DMX Universes)
  • Add isolation (and external 5v power for RS-485 transceiver chip). Two sample approaches:
  • Utilize 2nd timer or USART1->CTRL.TXDELAY to implement 3 (max) baud periods (12us) of MAB, instead of current approach of adjusting TIMER1 overflow value on the fly
  • Implement DMA for low-overhead transmission of DMX frames from RAM  USART1
  • Condense DMX Packet transmit repetition (from the “default” 22.8ms) for faster transitions when DMX Universe populated by <512 channels
  • Investigate adding wireless to decouple small/light user input functions from isolated and energy-abundant RS-485/DMX transmission
  • Develop a DMX Library to support:
    • Various DMX control configurations to accommodate multiple device types (simple 3-channel RGB dimming, multi-channel with angular/linear position control, internal program/GOBO control, etc.)
    • Various sensor input structures (cap sense linear/radial sliders, expansion board proximity sensors, temperature/humidity sensors, heart rate monitors, pressure sensors, audio FFT, etc.) to enable DMX responses to a broader array of stimulus/events
    • Complex DMX programs (pre-recorded, multi-channel sequences), minimally managed (program select, progression/cycle rate, etc.) by simple user control (button/slider)

Materials used

 

  • EFM32GG STK3700
  • RS-485 Transceiver
  • XLR3-3P DMX Loopback Terminal
  • DMX Cable
  • DMX Terminator
  • 3/7ch DMX LED "PAR" Can

 

Source Code:

  •  EFM32GG DVK (Development Kit) “UART RS-232” software example in Simplicity Studio: I ported the development kit software example to the EFM32GG STK (Starter Kit) hardware. Once that example is ported, I then modified main.c into the attached file to implement the DMX example code.
  • main.c source file in the attachment 

 

References:

http://www.dmx512-online.com/

http://elationlighting.com/pdffiles/dmx-101-handbook.pdf

https://wiki.openlighting.org/index.php/DMX512-A

https://en.wikipedia.org/wiki/DMX512

https://www.holidaycoro.com/v/vspfiles/downloads/UnderstandingDMX.pdf

http://www.lutron.com/en-US/Education-Training/Documents/DMX%20webinar_7-29-2010.pdf

 

 

This Hack a Gecko project is a result of a "fun hacking session" and are provided as is, free of charge with no guarantees or support from Silicon Labs, to partially or fully show and demonstrate EFM32 Gecko microcontroller capabilities. Get inspired, use at own risk, and build some awesome and cool applications."

 

  • Projects
  • 32-bit MCUs
  • Very interesting, considering my close ties to stage theatre and that I have a Giant Gecko. Are you at Silabs HQ?

    Whenever I've shopped around for DMX, I always found it overpriced, when I could just use one-hot GPIO and roll out the control signals on ribbon cable, or use a proprietary UHF wireless scheme. I never understood what exactly DMX buys me, except perhaps legacy. But now you're talking a $30 DIY controller. That might warrant another look.
    0
  • Hi,

     

    To drive the DMX cabling you'll need the external RS-485 transceiver (also relatively inexpensive) and external power (you're not going to want to drive the full DMX controller from a battery, but in any environment with DMX lights, etc. you'll likely have access to mains power anyway).  That said, there's nothing magical about the DMX standard and this approach is effective.  I would solve the isolation issue (see "Next Steps" section) before rolling out to something I needed to depend on and/or would be positioned with public access.  And to be of much use "live" you'd want to expand on the DMX universe manipulation (i.e. input and/or complexity of pre-recorded scenes) beyond what is featured in this quick demo.

     

    But I enjoyed making it, and when I get some time (someday) I hope to follow-thru with some of these improvements also Robot Happy

     

    Best regards,

    - Phillip

    0
  • I still feel like DMX is the legacy standard, while giving all your stage equipment IP addresses on your subnet is the future. Silabs is positioning itself to make money on the IoT. If we come up with bridge technologies with DMX, we can roll stage productions into the IoT fold.

    Referring to my video I posted yesterday on the Projects page (Part 2 under Smart Bamboo), I'm doing similar stuff with sound & lighting, only without DMX. Moving to IoT means I don't have to purchase an expensive custom DMX controller, and I can instead move that to a web browser and write the UI in software. Travelling theatrical troops on small budgets certainly won't complain about that. Backwards compatibility with existing DMX equipment could be a major selling point.
    0
  • Good points, and that's a neat idea in your video (I'd love to have a system to monitor moisture levels - I'm horrible at keeping my garden sufficiently watered without drowning everything).  Best of luck with your builds, and let us know if you add DMX support to your theater kits!

    0
  • I don't think I will be working on DMX soon, unless a lot of the work has already been done for me.  That's partly why I'm here--to assess how much has already been done.

     

    I see Silabs coming out ahead on this on the EZR32's.  DMX is not really low power, and DMX Arduino shields sell for between $18-$40, with isolation included at the higher end of that.   However, existing wireless DMX is at 2.4GHz, yet we are packing 1,000 people in one auditorium, all using 2.4GHz.  How many offerings are there for 315MHz with programmable MCU's?

    0
  • Hi,

     

    I don't anticipate that we'll be doing any work to develop a DMX controller, but given your thoughts on the current market we may someday see an OEM/vendor provide a DMX solution that leverages our wireless capabilities.  You make a convincing argument, to me anyway Robot Happy

     

    Best regards,

    - Phillip

    0