View Single Post
Old January 31st, 2011   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
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