E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Device Discovery (http://www.rdmprotocol.org/forums/showthread.php?t=1084)

Argh!! January 31st, 2011 07:50 AM

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.

sblair January 31st, 2011 09:57 AM

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.

ericthegeek January 31st, 2011 10:22 AM

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.

Argh!! February 1st, 2011 02:18 AM

Device Discovery
 
Thank you very much for such informative replies, they have helped me a lot.


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

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