How long does this take to execute

[Ioannis]

I have a feeling that this project is on the limit of the 18F series chips with PBP.

Eventually you may need to do a lot in assembly or finally select a 24F chip and C compiler...

I really have not seen the spec's of the DMX512. Is it necessary to send data continually?

Ioannis

[tumbleweed]

I have to admit I haven't done this using PBP, but I don't see any reason why an 18F25K22 @ 64MHz using DT-INTS wouldn't work out just fine.
There's plenty of ram and speed available. For that matter, if you're just transmitting DMX you don't even need to use interrupts... they just make it easier to transmit one packet while generating the next one.

DMX calls for a fixed baudrate of 250K with 8 bits of data + 2 stop bits, so that's 11 bits total (START + 8 data + 2 STOP) for 44us/byte. Note that if you're using a pic uart to send data you'll have to generate the second stop bit using a delay of 4us between bytes, but that's not normally a problem.

DMX uses packets of 513 bytes (a START_CODE byte + 512 bytes of data). Normally packets are send continuously about 44 times/sec (22.7msecs) which is the max full-out time for 513 bytes, but as long as you send one packet every second that meets the spec. As the transmitter, there's no other byte-to-byte time limit so things are pretty flexible.

If you're the receiver then things are a bit trickier since you HAVE to assume that you could get 513 bytes at the full-on speed of one byte/44us. That's still doable with a 25K22, but you almost have to use RX interrupts to collect a packet. That said, I've done both transmitters and receivers without using interrupts at all. Sometimes they just complicate things more than they help.

[tumbleweed]

Oh, and somethings else I forgot to mention...

DMX packets start with a BREAK signal, which is a low on the TXD pin of between 92-176us.

For the transmitter I found it easier to generate the DMX BREAK signal using an extra IO pin.
Put a 1-5K series resistor between the pic TX output and the 485 transceiver txd input pins, and tie the IO pin to that junction.

PIX TX out ---/\/\/\---------->RS485 TX IN
IO pin     ____________|

Normally, set the IO pin as an input so it's floating. When you want to generate the BREAK signal set it to output low
for between 92us-176us and then make it an input again. You can also generate the BREAK timing by fidgeting around with the uart baudrate
and transmitting a single 00 byte, but I found this to be a lot simpler.

[dsicon]

thanks for that BREAK idea tumbleweed

[HenrikOlsson]

I have a feeling that this project is on the limit of the 18F series chips with PBP.
Eventually you may need to do a lot in assembly or finally select a 24F chip and C compiler...

If they could do this in the early 90's then we sure as hell should be able to do it now, with PICs running PBP code at 64MHz, DT-Ints or no DT-Ints.....

I really have not seen the spec's of the DMX512. Is it necessary to send data continually?

The specification really only says 1 frame per second minimum but that obviously won't work in practice.

Note that if you're using a pic uart to send data you'll have to generate the second stop bit using a delay of 4us between bytes, but that's not normally a problem.

Not sure about that, may depend on the PIC used but at least the 25K22 family supports 9bit transmission, the 9th bit normally being used for parity. Simply enable 9bit transmission and keep the 9th bit at a logic '1' and you'll have your second stop bit.

For the transmitter I found it easier to generate the DMX BREAK signal using an extra IO pin.

Good idea, however I'd just disable the UART for the duration of the BREAK period, this drives the output pin to whatever state the LAT register dictates. Equally simple but saves an output pin.

use two 512 byte packets... one for the main loop to fill (#1) and one for the ISR to transmit (#2).

Using a double buffer may have its merits but since each channel is a single byte I don't really see the need for it. Is there REALLY a need to keep all channels in sync within 25ms or even less?
Perhaps some special type of fixtures/lamps/whatever uses TWO channels combined to get a 16bit value in which case you COULD potentially change one byte of that value while the other one is being sent but then again, if the update rate is >40Hz, will anyone even notice?

Nah, based on the tests I made, running a PIC at 64MHz should allow you to keep up with the theoretical maximum framerate - even WITH DT-Ints.

/Henrik.

[tumbleweed]

Simply enable 9bit transmission and keep the 9th bit at a logic '1' and you'll have your second stop bit

Now that's a slick idea! I'll have to remember than one.