STM32L4 With DMX512

Question

Hello there,

I am trying to control 2 LED strips (one with a WS2811 LED driver and one with a USC512C4 LED driver) with my STM32L4 with integrated RS485.

Do you have any idea how to do this?

Best regard.

P.Congré

michaelkellett · Answer

In xxx_project.h, #ifndef __C459_PROJECT_H #define __C459_PROJECT_H // INCLUDES #include "stm32f0xx.h" #include #include #include // DEFINES #define VERSION 100 #define VERSION_STR "1.0.0" #define FALSE (false) #define TRUE (true) #define MAX_GCI_SKIPS 10 #define FLASH_SIZE 0x200000 #define SECTOR_SIZE 0x10000 #define FLASH_SECTORS 32 #define CONTEXT_SECTOR 0 #define CONTEXT_BLOCK_SIZE 1024 #define SERIALISE_VERSION 0 // must never be 0xff because also used to loactae written areas of flash //#define SET_DMX_TX_EN {GPIOA->BSRR = DMX_TX_EN;} //#define CLR_DMX_TX_EN {GPIOA->BSRR = (DMX_TX_EN) << 16;} //#define SET_FLASH_NSS {GPIOB->BSRR = FLASH_NSS;} //#define CLR_FLASH_NSS {GPIOB->BSRR = (FLASH_NSS) << 16;} //#define SET_FLASH_WP {GPIOB->BSRR = FLASH_WP;} //#define CLR_FLASH_WP {GPIOB->BSRR = (FLASH_WP) << 16;} //#define SET_PROX_STX {GPIOC->BSRR = PROX_STX;} //#define CLR_PROX_STX {GPIOC->BSRR = (PROX_STX) << 16;} //#define SET_PROX_MD {GPIOC->BSRR = PROX_MD;} //#define CLR_PROX_MD {GPIOC->BSRR = (PROX_MD) << 16;} //#define SET_PROX_SC {GPIOC->BSRR = PROX_SC;} //#define CLR_PROX_SC {GPIOC->BSRR = (PROX_SC) << 16;} // PORTA #define IR_RX 1 << 8 #define DMX_TX 1 << 9 #define DMX_RX 1 << 10 #define DMX_TX_EN 1 << 11 #define LED_9 1 << 12 #define UART2_RX 1 << 15 // PORTB #define FLASH_SCK 1 << 3 #define FLASH_MISO 1 << 4 #define FLASH_MOSI 1 << 5 #define FLASH_NSS 1 << 6 #define FLASH_WP 1 << 7 #define LED_8 1 << 15 // PORTC #define LED_2 1 << 0 #define LED_3 1 << 1 #define LED_4 1 << 2 #define LED_5 1 << 3 #define PROX_PRX 1 << 6 #define PROX_STX 1 << 7 #define PROX_MD 1 << 8 #define PROX_SC 1 << 9 #define LED_12 1 << 10 #define LED_13 1 << 11 // PORTF #define LED_6 1 << 4 #define LED_7 1 << 5 #define LED_10 1 << 6 #define LED_11 1 << 7 #define ASC_LF 0x0a #define ASC_CR 0x0d #endif Hope this helps. MK

jc2048 · Answer

I should have added that there's also useful material about DMX512 here on the community. Here are a couple of good examples from shabaz and from genebren

DMX Explained; DMX512 and RS-485 Protocol Detail for Lighting Applications

DMX diagnostic tool - Getting started
DMX diagnostic tool - Sending and Receiving Data

DMX diagnostics tool - running out of time

jc2048 · Answer

This might help get you started http://www.emcu.it/STM32/Lighting-Control-using-DMX512-protocol-on-STM32/DOC/UM1004%20DMX%20512%20based%20LED%20lighting%20solution.pdf

jc2048 · Answer

It probably ranks very well on a search engine as original content. You aren't simply rehashing content from elsewhere - you've written your own text, done your own illustrations, and the outgoing links are on-topic and relevant. If I do a search on Bing for "DMX512", your blog comes up on the second page of results. That's a good result considering all the other quality material from manufacturers, standards bodies, and on-line reference sources that appears. You might also give element14 a little of the credit as, beyond any SEO that they might be doing in the background, we're all also benefitting from being associated with a group of people who are producing quite technical material and that probably gives us all a few extra 'bonus points'. I'm intrigued - I'm going to have a look at some of my old ones.

jc2048 · Answer

If you don't mind a hardware engineer telling you how to deal with debugging, here's how I'd tackle it: Does anything at all emerge from the STM32? Can you see any sign of serial waveforms at the output pin, even if it just sends a frame of 513 characters and then freezes at the break? Is your 485 chip matched to the IO voltage standard of the processor? [Not all of the older ones would be ok on 3.3V] What can you see on the A and B outputs of the driver chip? Have you wired the outputs the right way round to the LED strip? If you see a lot of overshoot and the sigals are very messy, look carefully at how you've done the termination on the RS-485. [The strip might be much more fussy than a normal DMX receiver.] If there's still nothing, try hacking together a bit of very simple test code to repetitively send a serial character and look again. If that works, go back to the DMX code and disable the stuff that does the break [the fiddly stuff with a timer that could esily go wrong] and verify that it's sending the character stream ok, then start working on the break code, maybe even isolating it and just repetitively sending the break until you get the timing right.

shabaz · Answer

^ Great debugging tips from Jon.

Right now I'm trying to get hardware and software working. I did not create the hardware nor the software, but I won't raise a case until I've:

1. Verified connections and voltages

2. Connected a 'scope or attached a logic analyzer (they cost less than $20) and examined if the interface signals are what I expect

3. Grabbed debug from the code

4. Tried different hardware and software combinations to try to narrow down the problem

5. Sketch a diagram or take photos or video to show precisely what I'm doing

6. Supply any configurations or log file content

For your scenario, maybe point 2 and 4 are also relevant, since you could compare the working scenario (Arduino) with the non-working scenario, and compare the signals, to see what the difference is.

genebren · Answer

Here are a couple of things to check:

Is the serial port setup correctly? It should be baudrate of 250,000, 8 data bits and 2 stopbits.
Is the Break pulse correct? The Break pulse needs to be at least 80uS, preferably larger (the specs are not always followed). This pulse should be a low going pulse.
Is the post Break correct? The Post break needs to be at least 12uS, preferably larger (again the spec is not always followed).
Is the Start Code (first byte of the DMX stream) correct? Some devices need this byte to be a zero, others may have other special requirements.

Good luck!

genebren · Answer

Paul,

I do not have much (if any) experience with STM32, but I did find this code that might help you along:

https://github.com/carl3721/stm32-dmx512/blob/master/dmx-p103/src/main.c

It was an easy search of "stm32 dmx example", which seem to have lots of results.

I take from all of this that is very new to you. I have found that Google is your friend, and you will likely find lots of help there (and here). You really need to break it down into little pieces when you are looking for help. DMX has been around for quite a while, but there are not many examples, as a lot of people are buying solutions from a small handful of suppliers, that wrap all of the messy stuff up into libraries or standalone hardware.

Gene

michaelkellett · Answer

The two links to code that you posted are both code bases for STM32F10x processors - you are using an STM32L4xxx which will be different.

I can't guess all the things (if any) which will be wrong without:

1) Your code

2) A schematic or detailed block diagram of your set up

3) A pin list showing which processor pins are used for what

It would also help if you told us what software and debugging tools you are using (including do you have a scope or logic analyser).

Pictures often help as well.

MK

Jan Cumps · Answer

genebren wrote:
... If you have the proper experience you should be able to find all you need to know from the documentation available from STM to take the concepts that you used on the Arduino and port them to the STM part.

Porting existing knowing-to-work code to the platform you're learning is an excellent way to get the experience.

You have the luxury to see everything working and know that there's no defects. When stuck, you can always go back to the working example and compare.

I've written a blog here on my approach to port a library between platforms. I'll search for it ...

edit: found: Educational BoosterPack and Hercules LaunchPad: LCD Driver - Part 3: SPI Works

michaelkellett · Answer

Hello Paul, OK, I see your code, and I think I understand what you are trying to do. (For future reference, if you want to share some code the best way is to zip up the top level folder of the complete project (with all the cube files etc) and transfer it by Dropbox or whatever. That way I could just run it - to get your code into a compileable form would take an hour or two - and that's a bit too long for me to do.) A long time ago (2013) I wrote code for a DMX controller and a DMC controlled device. void tx_dmx(uint8_t *data, uint32_t n) { // Timing according to DMX spec // 1 "SPACE" for BREAK - flexible, depends on time between bursts of data, min allowed 92uS // 2 "MARK" after break - min allowed is 12uS, we use 25uS; // 9 "MARK" between slots - min allowed is zero, we use 10uS // 10 "MARK" before break, min allowed is zer, we use 10uS // // we usually only send < 32 bytes so the total time taken is about 25 + (32 * ((11 * 4) + 10)) + 10 = 1763 uS // full length DMX frame would take 27737 uS which is OK occasionally but not good full time. // no need to use interrupts, we just block int d; if (n > DMX_MAX_TX) { n = DMX_MAX_TX; } GPIOA->MODER = (GPIOA->MODER & ~(3 << 18)) | (2 << 18); // set mode bits for A9 to 10 for UART // ends the break and starts the mark TIM2->CNT = 0; while (TIM2->CNT < MARK_AFTER_BREAK) {} for(d = 0; d < n; d++) { USART1->TDR = *data++; TIM2->CNT = 0; while (TIM2->CNT < MARK_BETWEEN_SLOTS + BYTE_TIME) {} } GPIOA->MODER = (GPIOA->MODER & ~(3 << 18)) | (1 << 18); // set mode bits for A9 to 01 for GPIO - DMX BREAK } It blocks rather than use interrupts - not so slick but much easier to debug (because you can step through it one instruction at a time and measure pins with a DMM if that's all you have.) I can post more of it if useful. You will need a debugger (and to to do embedded code development you NEED a debugging tool). The ST Nucleo boards all have one built in. If you have your own board you can buy an ST Link for less than £20. You will notice that I don't use the ST library code to controll USART and GPIO. It might take a little longer to write the code at first but it does mean that you have to understand the peripherals - which is worth the hassle. On a new project, especially if using using a new (to me) processor I usually put a "Blinky" and a hello world in the code. SO it starts by blinking an LED (that tells me that the processor is running at the right speed) and uses the debug UART (there should always be a debug UART in any project where the processor has more than 28 pins) to say "Project XX Build YY". You might want to try these ideas on your project, 1) Get an LED blinking (so you can check timing - I've had a 200MHz uP almost working at 240MHz, took a long time to work out why the IO was flaky but nearly working) 2) Get used to looking at the peripheral registers with the debugger 3) Write your code so it is easy to step through 4) Expect to change code as you get stuff working, don't use interrupts at first unless you really have to, write blocking code, get it working, then apply the DMA and interrupts (and only if necessary). 5) (controversial) never trust the processor manufacturers library code, still less trust code you got free from the web, it can be very useful for getting ideas, learning stuff and so on - just don't count on it being good. MK

STM32L4 With DMX512

Top Replies