E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Physical Layer/Hardware Discussion

RDM Physical Layer/Hardware Discussion Discussion and questions relating to the physical or hardware layer of RDM.

Reply
 
Thread Tools Search this Thread Display Modes
Old June 11th, 2009   #1
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Smile What is the basic requirement to implement RDM?

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.
wcai_cypress is offline   Reply With Quote
Old June 11th, 2009   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old June 11th, 2009   #3
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

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
wcai_cypress is offline   Reply With Quote
Old June 12th, 2009   #4
Nigel Worsley
Junior Member
 
Join Date: Jun 2006
Location: London
Posts: 13
Default

Quote:
Originally Posted by wcai_cypress View Post
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.
Nigel Worsley is offline   Reply With Quote
Old June 12th, 2009   #5
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

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.
wcai_cypress is offline   Reply With Quote
Old June 12th, 2009   #6
Nigel Worsley
Junior Member
 
Join Date: Jun 2006
Location: London
Posts: 13
Default

Quote:
Originally Posted by wcai_cypress View Post
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.
Nigel Worsley is offline   Reply With Quote
Old June 12th, 2009   #7
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old June 12th, 2009   #8
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by Nigel Worsley View Post
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).
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old June 12th, 2009   #9
Nigel Worsley
Junior Member
 
Join Date: Jun 2006
Location: London
Posts: 13
Default

Quote:
Originally Posted by sblair View Post
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.
Nigel Worsley is offline   Reply With Quote
Old June 12th, 2009   #10
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

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

Thanks again,
Vincent.
wcai_cypress is offline   Reply With Quote
Old June 13th, 2009   #11
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old June 14th, 2009   #12
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

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.
wcai_cypress is offline   Reply With Quote
Old June 15th, 2009   #13
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by Nigel Worsley View Post
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.
ericthegeek is offline   Reply With Quote
Old June 16th, 2009   #14
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

Hi Eric,

Thanks for the reply.
Hope someone can share more experience.
wcai_cypress is offline   Reply With Quote
Old June 24th, 2009   #15
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

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.
wcai_cypress is offline   Reply With Quote
Old June 25th, 2009   #16
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old June 25th, 2009   #17
dangeross
Junior Member
 
Join Date: Feb 2009
Posts: 13
Thumbs up Code size

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.
dangeross is offline   Reply With Quote
Old June 25th, 2009   #18
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

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.
wcai_cypress is offline   Reply With Quote
Old June 25th, 2009   #19
dangeross
Junior Member
 
Join Date: Feb 2009
Posts: 13
Default Code Size

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.
dangeross is offline   Reply With Quote
Old June 25th, 2009   #20
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

Actually, I am using PowerPSoC from cypress.
I am located in ShangHai, China.
wcai_cypress is offline   Reply With Quote
Old July 8th, 2009   #21
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

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.

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.
wcai_cypress is offline   Reply With Quote
Old July 8th, 2009   #22
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old July 8th, 2009   #23
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Default

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.
wcai_cypress is offline   Reply With Quote
Old July 8th, 2009   #24
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old July 8th, 2009   #25
wcai_cypress
Junior Member
 
Join Date: Jun 2009
Posts: 12
Smile

Quote:
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?
wcai_cypress is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 12:14 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.