Dmx Solved !!!!!!!

[oscar]

thanx for the info bruce. ur a star !!!!!!!!

found just what i wanted n seems as if the code should be compatible enough.

[bcd]

Could you share your code - I'd be very interested !!

Thanks,
Bill

[alanmcf]

I would love to see your code on that-- that very problem (DMX in PICBasic only) has been plaguing me for years and I've never had the time on a project to sit down and figure it out. Seeing your code would be immensely helpful! Also, I have a subroutine implemented as inline assembler that you might find helpful-- it does 8 simultaneous channels of PWM. Let me know if you're interested!

Thanks--

--Alan

[DynamoBen]

Yes, please post your code.

[JEC]

DMX isn't too bad if you spend a while in the datasheet. Depending on the chip you use, there are a few 'optimal' clock speeds which will allow you to send and receive zero error.

It's just asynchronous serial @ 250 kbaud.

I've used both '628s @ 20MHz and F88 chips @ 16Mhz, both transmitting and receiving.

Just receive through an appropriate level shifting chip (MAX485, SN75176 or similar).

The first thing I do is watch for the 'break' signal. PULSIN works remarkably well for this. I set a reasonable timeout duration and just keep watching for that 80 uS minimum break period.

Then, I use a WHILE RCIF = 0 : WEND loop to sit there and wait for something else to come through the USART.

Once I've found a valid break, the next byte is the start code. For dimmers, it should be zero.

Then I just increment a counter each time a byte comes through and when I've received what I want, I exit the loop.

I've not ever tried to implement a full interrupt based receiving system, as my other housekeeping code was fairly lightweight. However, it shouldn't be hard to do in theory.

Transmitting is almost the same: just generate a 'break' signal (I like 120 uS), send out a zero byte and then however many bytes of channel data you need. With tight code, I can output 512 channels @ almost 40 Hz...

John

[alanmcf]

John, thank you so much for pointing me in the right direction!

I'm using a 16F877 at 20MHz, so the UART RX is pin 26, aka RC7. I'm using a 75176 also. I have no experience using the UART at all. Regarding your use of PULSIN, can I just do something like this?

loop:
PULSIN portC.7,1,pulse_word 'if portC.7 is set up at the UART input,
'will PULSIN work? Is 1 the correct polarity?
IF pulse_word<40 then loop '40 = 80uS with a 20MHz osc

WHILE RCIF = 0
HSERIN [dmx_val] 'throw away first value at it is the start code

channel_loop:
HSERIN [dmx_val] 'get channel 1 value
count0 = count0 + 1
if count0 = target_channel then exit
goto channel_loop

Since you've already done this, have you found any issues with UART overflow and needed to toggle that CREN bit? Also, I've read elsewhere that the data is in 8N2 value-- does that require any additional code to handle? I'm also wondering if having the UART enabled causes issues with then using PULSIN on the UART RX pin, PortC.7, and is the PULSIN polarity a 1 or a 0 for the break signal following the 75176?

Thanks so much for your help so far!

--Alan

[JEC]

>>overflow and needed to toggle that CREN bit? Also, I've read elsewhere that the data is in 8N2 value-- does that require any additional code to handle?

Ooops. So what I usually do is check for my break signal with the USART turned completely off. Then, when the break is detected, I turn on the USART and read RCIF twice, just to make sure it's totally empty.

Then, the next value that comes through is my start code.

Don't just throw it away, though! The official spec (well worth the $30 paid to the USITT) talks about how dimmer data has a zero start code, but not everything needs to. It's totally OK for a manufacturer to send 'proprietary' data after a non-zero code. So if you're just blindly accepting everything after the first byte as valid, you may get burned down the road.

Having said that, I've 'scoped the output of a GrandMA, a few different Hogs, a dozen or so ETC consoles, and some cheap throwaway DJ gear and never *not* found a zero start code...

With one exception. It made me so mad I vowed never to buy or use that particular company's equipment again. I'd programmed *my* receiving equipment to flash an error LED if the data stream had a non-zero code for some reason.... Grrrrrrr.

As an aside, if you tell your lighting controller to create a start code of, say, '10', only the 'proprietary' dimmers you've designed will work with that particular console. The marketing folks love that, because it fakes a case for using equipment only from one company.

>>I'm also wondering if having the UART enabled causes issues with then using PULSIN on the UART RX pin, PortC.7, and is the PULSIN polarity a 1 or a 0 for the break signal following the 75176?

After you've run the signal through the level shifter chip, you should see that the data line idles high. So you're watching for an active-low pulse of 80-120 uS.

And the bit about 8N2 vs 8N1 doesn't really matter, because the stop bits are both high. So 8N2 is just a slightly 'slower' version of 8N1. It makes lots more sense if you can see it on a 'scope.

So here's a loop in pseudocode:

1. With the USART off
2. Loop around until you find a decently long break

3. If you've found a break, turn the USART on and clear RCREG twice (it's double-buffered, according to the datasheet. So it can receive two bytes without overflowing)
4. When the RCIF flag is set, you've received a start code. Decide what you want to do with it.
5. Then start counting and grab the rest of the data you're interested in.
6. Turn off the USART

Hope this helps some.

Seriously, spend the $30 and get a copy of the DMX documentation. There's a lot of valuable design information included in what they'll send you.

John