E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old January 31st, 2011   #1
Argh!!
Junior Member
 
Join Date: Nov 2010
Posts: 2
Default Device Discovery

Hello,

I am new to this group and so I guess maybe I am allowed to ask a dim question

Should Device Discovery be included in a RDM protocol stack or is it something that will be implemented by a developer in their application?

Thanks.
Argh!! is offline   Reply With Quote
Old January 31st, 2011   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

It really depends on the product. Most of the time developers are working directly with the hardware so it will be implemented in the application. In other cases developers are using common 3rd party hardware with API's to the hardware, in which case it may be implemented in the hardware with an API call to access it.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 31st, 2011   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

It's not a dim question at all. There's no right answer to that question.

If you're writing a protocol stack for yourself, then it really doesn't matter, you can draw the division wherever makes sense to you. If you're planning a more generic framework for others to use, then it's a bit more complicated. What follows are my personal opinions only, and how I would probably do it were I implementing a generic stack.

In the case of an RDM controller, I would not include discovery in the protocol stack. There are dozens of ways to optimize discovery, and it's a major differentiator between products. If you implement the controller side in the API, everyone who uses it will perform similarly well (or badly). But if you leave it to the application, they can tune the performance. Also, different applications will want different behavior. Some will want low-rate background discovery, others will want to preempt Null Startcode traffic and prioritize discovery. Writing an API that can handle all cases is impractical. If you let the application code send RDM when it want, and NSC when it wants, it's much more flexible for the protocol stack's user.

The controller-side stack would simply include an API for sending a "Discover Unique Branch" style packet, and pass the response data (if any) back to the caller. (You'd also need a different API call for sending standard, non-discovery packets since they handle responses differently). I'd then include sample code for how to do discovery to help get them started.

If you're writing a responder protocol stack, then it probably should be included in the stack. I don't know how light-weight your OS is, but responders have strict timing requirements. Passing data to user code, and then responding it time may be difficult. Also, the discovery response from a responder's perspective is pretty tightly constrained. Give the user a way to set the UID at initialization, and perhaps a few time constants for the discovery response (response delay, etc.), and then handle the response in the stack. I'd probably provide a callback to let the application code know that a DUB has occurred, but they don't have to do anything with that callback if they don't want to (most responders won't need it).

Remember that RDM implementation vary widely. There are RDM devices that run on everything from 8-bit microcontrollers written entirely in assembly to multi-GHz, Multi-Core processors with a commercial RTOS. What kind of environment you're planning to use for your Protocol Stack will drive many of the decisions. If you're able to tell us more about your application, we may be able to provide better advice.
ericthegeek is offline   Reply With Quote
Old February 1st, 2011   #4
Argh!!
Junior Member
 
Join Date: Nov 2010
Posts: 2
Smile Device Discovery

Thank you very much for such informative replies, they have helped me a lot.
Argh!! 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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Figure 7-2: Device Discovery Process mike_k RDM General Implementation Discussion 2 October 1st, 2009 02:28 PM
4.2.1.1 In-line device Port Turnaround during Discovery prwatE120 RDM Timing Discussion 1 August 7th, 2006 10:52 PM


All times are GMT -6. The time now is 06:02 PM.


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