I want to make a DMX512 transmitter with a STM32F103 using HAL, CubeMX.

I found some documentation like here about the protocol: Lighting-Control-using-DMX512-protocol-on-STM32.

Sadly it does not show code, however, I have some questions about the protocol itself mainly:

These are excerpts from chapter 2 from the manual:

enter image description here enter image description here enter image description here


  1. "MARK" time between slots: 0 - <1.00 s ... so if the minimum time is 0, why not leave it out completely?
  2. "MARK" before BREAK (MBB): 0 - <1.00 s ... same here? why bother to 'implement' it?
  3. Also in the diagram START TIME is mentioned, but there are no timing requirements for it... how can I know what is allowed?
  4. In this GitHub file some code (non HAL, but STM32) is shown where there are many remarks about time critical functions, but according to Table 1 there is for most items max. 1 second time, this I would not call time critical. I know HAL/CubeMX tend to have quite a lot of overhead code, so I wonder if this will give problems.

If someone has more information about a DMX512 transmitter, preferably using HAL/CubeMX, I would like to hear about it (couldn't find any example/code).


DMX transmitters are superficially easy, but there are a number of traps if you want your kit to play nice with at least most of the really trashy end of the DMX receiver market....

In particular if you stick to max rate (especially max rate on minimum channel count, ~1.2ms per packet) you will find a lot of cheap shit that does not correctly decode it (Cheap LED cans, looking at you). Even a full 512 channel packet running at max rate can cause problems with the "Third tier" kit, which is why grown up lighting desks usually have a way to diddle the DMX timings to something slightly more conservative.

Another nice trap is moving lights that do interpolation, these really need your movement calculations to be synchronous with the DMX frame timing, to minimise jitter, doing the sums at 100Hz when the transmitter is getting ~40 frames a second on the wire does NOT work well.

The real timing pain is in the receivers, especially in a receiver on a minimal cost micro, on the transmitter side, just be very conservative in what you generate (and give the operator the option to slow things down if necessary).

  • \$\begingroup\$ Thanks for this useful information, I'm indeed using cheap LED cans, so I will need to do tests after I finish the DMX transmitter to see if they can cope with it. I'm not intending to make moving lights yet (but who knows, in future). \$\endgroup\$ – Michel Keijzers Sep 21 '18 at 10:19

1 and 2 - if this line was missing from the table it would be difficult to see the maximum values. This table is showing you the range of values for that parameter that you must deal with as a receiver.

3 Start time is the bit time of a Start Bit, which is the same as the bit time of any other bit.

4 The reason DMX code is time critical is that receivers have to cope with what the transmitter sends, which can have some very short times that have to be recognised such as the MAB. As a transmitter, you can slow things down, you have that freedom, but as a receiver you have to work with anyone else's transmitter which can be using the minimum values in for transmission timings.

It's always preferable to use the definitive source document when it is freely available than secondary documents. That would show you that you are looking at Table 7, the timing for receivers, when you need Table 6, the timing for transmitters.

  • \$\begingroup\$ Thanks for this elaborate answer; it seems that I should not have many problems with timing, even using the STM32 HAL library. Thanks also for the official document. \$\endgroup\$ – Michel Keijzers Sep 21 '18 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.