DMX and RS-485

[EPAC_Matt]

Hiya,

I'm planning on rolling my own little DMX controller using a PIC16C84 (or whatever the newer one is called) microcontroller.

Basically, I know how to use the chip's pins to create an RS-232 signal over a 2-conductor line ( neg voltage is a high, and pos voltage is a low), but how do I create high's (0'?) and lows (1's?) 3-conductor RS-485 line?

Thanks!

Regards,
Matt

 

[DMXtools]

There are a number of RS-485 line driver/line receiver and transciever chips on the market that go from single-ended 5V logic-level to differential RS-485 and back. Transceivers are more common than separate transmitters and receivers - in your application, you'd just ignore the receiver section. The one I use is available in pin-compatible versions from at least 3 manufacturers - LTC491 from Linear Technology, MAX491 from MAXIM or AD489 from Analog Devices. All have extra ESD protection. Also important for me is the fact that the transmitter and receiver are completely separate, letting me run both at the same time. But that comes at a price - it's about a two-dollar chip. The old SN75176, from Texas Instruments, shares pins on the RS-485 side - it can only be used half-duplex - but that shouldn't matter in your case: you only need the transmitter part of it anyhow. It costs about 69 cents.

I'm not all that familiar with the PIC line, but it's important that the microcontroller you choose has a hardware UART built-in. DMX-512 runs at 250 Kbps. If you try to build a software UART, it means you have to be able to shift a new bit out the port pin every 4 microseconds reliably. To do so means no interrupts between bits - even on a blazing-fast processor you'd have little time for anything else.

With a hardware UART, you only need to make sure you can get a complete packet done and a new one started in under a second - each byte takes exactly 44 microseconds, but you can spend a lot of time doing other things between bytes without violating that spec.

John

 

[EPAC_Matt]

Yea, I will be writing my own software UART. From my understanding, the inter-frame time can be up to 1 second long?

Since the PIC16F84A only has 86 bytes of ram, I think I'll have the PIC request channel values from a PC via a RS-232 serial interface during the inter-frame time, then load that up and have the PIC send each frame to a TI SN75176 chip to convert the PIC's output into RS-485 compatible signals.

Thanks for the reply DMXTools

 

[DMXtools]

Yea, I will be writing my own software UART.

Good luck! I always worry about jitter with a software UART. 4 microseconds per bit is awfully quick, but it can be done.

From my understanding, the inter-frame time can be up to 1 second long?

Theoretically... if your packet is only one frame long. The inter-packet time, from the starting mark of one to the starting mark of the next, is also one second max.
A one-frame packet makes no sense, because the first frame of the packet is the packet type... it doesn't actually control anything, just says what the rest of the packet is meant to control. If you have a full 513-frame packet, your inter-frame time is down to under 2 milliseconds max. If your RS-232 link is running at 9600 bps or faster, you should be okay... depends on your request/response protocol - I'd recommend a hardware handshake: no extra bytes to handle and decode.

It's important to beat the 1 second per packet time for a couple reasons, the most important of which is the way a dimmer behaves on loss of data. There's no definition in the DMX-512 spec. Some will hold the last received value forever, some go to 50% on all channels, some go to blackout, some go to max and some (if you're really lucky) allow you to program how they'll behave. Oh, and some of the cheap DJ-class shift into sound-activated chase mode - that might be interesting in the middle of Henry V Beyond that, even if your dimmers will hold their last setting forever, the faster you refresh the DMX data, the smoother your fades will be. Imagine a 5-second fade -done in five discrete and highly visible steps.

If the PIC has a hardware UART that you're planning to use for the RS-232 link to the PC, you might want to see if it can be set up with separate baud-rates for transmit and receive. If so, maybe you can use the receiver and a hardware handshake for the PC and the transmitter for the DMX output to the 75176.

John