What is the basic requirement to implement RDM?

[wcai_cypress]

Dear all,

I am a newer with RDM.

Currently, I need to implement a solution for RDM responder. I have read the RDM standard, but still not clear about What is the basic requirement to implement RDM? I plan to use MCU to implement RDM responder. I just wonder how to select MCU, what features are required to implement RDM responder? Is that enough to have only one UART in the MCU?

If use UART to implement RDM responder, how to detect the break header during receiving and how to generate break header during transmitting?

Sorry for the stupid question, but I need the answer definitely.

Vincent.

[sblair]

Vincent,

There are some others on here that will be able to better answer your questions as far as minimum hardware as we have some folks that have implemented on PIC processors even.

Only 1 UART is required for RDM so that you can both transmit and receive. The main requirements are being able to adhere to the timing requirements, have enough processing still to do whatever the main function of your device is and then also parse and respond to the RDM messages that you choose to implement.

I tend to work with some of the larger Freescale processors (ColdFire family) so they are able to easily generate and detect Break conditions. Some of the lower end parts may require you to do it yourself. If you tell us which MCU you are using there are others here that may be able to give you some more detailed info.

[wcai_cypress]

Hi Scott,

Thanks a lot for your quick reply!
Actually, I am using PowerPSoC which is a newly introduced chip for lighting.

I am still wondering if use UART to implement RDM responder, how to detect the break header during receiving and how to generate break header during transmitting?

You mentioned that some of the larger Freescale processors (ColdFire family) being able to easily generate and detect Break conditions, how?? Does it provide special hardware feature to do that? If yes, what know of feature?

I like this forum,
Thanks

[Nigel Worsley]

Originally Posted by wcai_cypress

If use UART to implement RDM responder, how to detect the break header during receiving and how to generate break header during transmitting?

For receiving, a framing error with data of 00H can be assumed to be a break.

For transmitting, then assuming that the UART doesn't support sending of breaks then either of the following should work:

1. Set the baud rate to 100kbps and send 00H - after the byte has been sent ( which is usually NOT when the UART is ready for more data, due to a buffering register ) set it back to 250kbps.

2. Turn off the UART, set the I/O pin low, wait for at least 88uS, set the pin high again and turn the UART back on.

The first method has the advantage of accurate and repeatable timing without needing any additional processor resources ( eg. timers ), but does depend on being able to tell when the UART shift register is empty - this is often not possible.

[wcai_cypress]

Dear Nigel,

Your answer is definitely useful for me.
Now, I have the idea to implement RDM Responder based on UART, thanks!

Because I am a firmware engineer, I have one more stupid question, normally, the UART module in MCU works in full-duplex mode, how to make it work in half-duplex mode.

[Nigel Worsley]

Originally Posted by wcai_cypress

Because I am a firmware engineer, I have one more stupid question, normally, the UART module in MCU works in full-duplex mode, how to make it work in half-duplex mode.

The easiest way is not to bother!

Tie the RS485 driver chip's Driver Enable signal to the Not Receive Enable and the UART will never see the transmit data in the first place.

[sblair]

One thing to amend Nigel's post...

In RDM the minimum transmit time for the Break is 176uS and not 88uS. Minimum receive time is 88uS. In practice of course it is always good to transmit a bit longer than the minimum to be safe.

In terms of Full-Duplex/Half-Duplex I'd say it is really more about how you connect your TxD and RxD lines to your RS485 transceiver than anything.

[sblair]

Originally Posted by Nigel Worsley

The easiest way is not to bother!

Tie the RS485 driver chip's Driver Enable signal to the Not Receive Enable and the UART will never see the transmit data in the first place.

There is a really important point here that Nigel is making. If you do have your driver chip wired such that you can see the transmit data on the receive then make sure your code ignores the receive while transmitting otherwise it is very easy to receive your own transmitted messages and parse them. (I've made that slip a couple times myself).

[Nigel Worsley]

Originally Posted by sblair

In RDM the minimum transmit time for the Break is 176uS and not 88uS.

I stand ( well, sit actually... ) corrected!

I don't have a copy of the RDM spec to hand, I was intending to check that figure this evening. This means that the UART will need to be run at 50kbps or slower for the first method that I suggested to give the correct timing.

[wcai_cypress]

Is there any existing schematic or sample code can speed up my development and reduce mistakes that might be triggerred?

Thanks again,
Vincent.

[sblair]

There's a number of schematics out there. I'd suggest looking at the schematics for recent products such as moving lights from some of the larger manufacturer's support websites (hint, hint).

Wybron has made their Responder sample code available.

I would also highly suggest coming to the RDM Plugfest in Dallas as you'll get a chance to get a lot of first hand knowledge and experience from everyone.

More info here: http://www.rdmprotocol.org/forums/showthread.php?p=1578

[wcai_cypress]

Hi Scott,
I am very appreciate for your reply.
But I still can't find any reference.
If you can show me some free download websites, that would be more useful.

BTW, I will recommend my boss to attend the RDM Plugfest .

Thanks again,
Vincent.

[ericthegeek]

Originally Posted by Nigel Worsley

For receiving, a framing error with data of 00H can be assumed to be a break.

In Null Startcode only systems, you could usually get away with this, but it's not enough for reliable RDM operation. 0x00+Framing Error only tells you that the line has been held low for about 40us.

During the discovery period, it's common to see the line held low for >40us due to response collisions.

Building a reliable RDM device requires a lot of work tuning the DMX receive engine.

[wcai_cypress]

Hi Eric,

Thanks for the reply.
Hope someone can share more experience.

[wcai_cypress]

Dear all,

Could anybody provide some information about the requirements of Flash/RAM space(8-bit MCU) to implement minimum-RDM responder, normal-RDM responder and full-featured-RDM responder?

Thanks in advance,
Vincent.

[ericthegeek]

Just about any 8-bit microcontroller with a UART and a few K-bytes of flash should be sufficient for RDM. Add more flash if you want to program in C instead of assembly, and having >1K-byte of RAM makes things easier. Many RDM products have been built with PICs (16F and 18F series) and 8051 derivatives.

For the most complex products that are likely to need a Full Featured responder, the resources needed to support RDM will be insignificant compared the total computational load on the processor.

[dangeross]

We've just completed as design with DMX, RDM, Closed loop PID control and a rather large ASCII interface for bench testing and calibration during manufacture. The RDM also has an additional 10 manufacturer PID's above the minimum required. All of the code was written in C and used the manufactures library routines to interface to the peripherals, the library does not produce the most effiecent code i.e. function A calls function B calls function C that writes the value passed into function A to a peripheral register.
After looking at the listing output files I remember the code being around 28K including the constant storage space.
If you can stand the slightly higher cost I would suggest a 32-bit micro, we used a ARM Cortex-M3 and if you get to a point where you need to start optimizing code its nice to not have to handle 512 channel, 16-bit pan/tilt, and other data larger than 8-bits with a 8-bit micro. In the past we've used 8051 and Z8 variants and I don't think well ever go back with the new Cortex hardware available from Luminary Micro, ST Micro, and soon Atmel and NXP.

[wcai_cypress]

My MCU only has 16K flash and 1K RAM.
So, based on the info above, the conclusion is we can't implement full-featured-RDM responder, but we can implement minimum-RDM responder. And I don't know if we can implement normal-RDM responder ?

Thanks,
Vincent.

[dangeross]

I may have misled you a little bit my code is a bit large. Each PID has its own function with a lot of redundant code that could be removed by combining the common parts of the PIDs. I do think though that if you want a full featured RDM implementation you might be looking at some assembly language. What processor are you using and where are you located.

[wcai_cypress]

Actually, I am using PowerPSoC from cypress.
I am located in ShangHai, China.

[wcai_cypress]

For receiving, a framing error with data of 00H can be assumed to be a break.

I met a problem, For example:
Break Header = 88 us
MAB = 8 us
With the quoted method,
for the first 80us, UART will detect 2 bytes of 0x00 with frame error.
80~84us of the break header will be taken as start bit of a new byte,
85~88us of the break header & MAB & some bits in start byte will form this new byte.
So this method will lead to wrong result.

Hope someone can help me.
If you don't understand my meaning , please let me know, I will add more comment.
Thanks in advance,
Vincent.

[ericthegeek]

Not all UARTs can reliably detect a break. You may have to use a timer input, GPIO or something else to ensure you can separate breaks from noise.

[wcai_cypress]

Hi Eric,

Thanks for you reply.
I just wanna make sure that in the case I described above, UART can't detect the BreakHeader correctly, is it right? Or maybe I miss something.

Thanks again,
Vincent.

[ericthegeek]

Every UART is different, and I've never use the PSoC devices, so I can't tell you how their UART behaves. Usually it takes a few hours with some simple test code and an oscilloscope to determine when the actual interrupt is generate and how it handles error reporting.

[wcai_cypress]

Quote:
For receiving, a framing error with data of 00H can be assumed to be a break.
I met a problem, For example:
Break Header = 88 us
MAB = 8 us
With the quoted method,
for the first 80us, UART will detect 2 bytes of 0x00 with frame error.
80~84us of the break header will be taken as start bit of a new byte,
85~88us of the break header & MAB & some bits in start byte will form this new byte.
So this method will lead to wrong result.

Does anything wrong with my description?