Receiving DMX with STM32F070

[declareupdate]

Posted on February 05, 2016 at 18:34

Howdy, 

I'm working on a project that will receive DMX using the STM32F070CBT6. I have PA1, configured as USART4_RX, connected to my DMX input via an RS485 transceiver. Most of this is straightforward, but I have a couple of questions. DMX packets start with a 88us ''Break'',  followed by a 12us ''Mark After Break'', followed by 512 data bytes. What I'm working on is how to properly detect the ''Break'' and ''Mark After Break'' on the RX pin. Input capture would be the obvious choice to measure the length of incoming pulses, but I'm not sure if I can implement it on the same pin here. a couple of questions: 1: Is there a standard way to detect incoming DMX packets? 2: PA1 can also be connected to TIM15_CH1N. Can CH1N of a timer be used for input capture? 3: Can PA1 configured as USART4_RX be read as GPIO? (I could just read the pin and count usecs to detect these signals)4: Can PA1 configured as USART4_RX trigger an external interrupt as if it were just GPIO? While typing this out, I came across some folks using the ''framing error'' detection to detect a ''break'' condition. Any info or ideas on this would be great. I get the feeling I'm overthinking this, considering so many devices receive dmx. Engineers can't be reinventing this every time. I appreciate any pointers or info! Thanks!  #usart #dmx #framingerror

[Tesla DeLorean]

Posted on February 05, 2016 at 19:46

2) N-Channels are not usable a timer inputs. I can't see the USART RX and TIMx_CHx sharing an input, although you could change the Mux setting to pick each alternately.

3) You can read the current state of a pin via its GPIO->IDR4) You might be able to use it as an EXTI input, haven't tried, seems like a practical application.5) Guess you'd have to look at the parts they used, and how they solved it. DMX/MIDI aren't particularly mainstream applications, and time-stamping data edges on USARTs isn't something most design include. You can infer when something started based on the assertion of RXNE when it's fully arrived.

[declareupdate]

Posted on February 06, 2016 at 04:28

Thanks, Clive. Reading the state of the RX pin via GPIO->IDR sounds like my solution.