View Single Post
Old August 18th, 2011   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

The best solution is to make sure your responder can always handle back to back broadcast requests. That means either fully processing the request within 176 us, or saving the request for processing as a background (low priority) task.

Take the common case of an EEPROM write which can take several ms. I keep a copy of the DMX address in both RAM and EEPROM. When the Set DMX Address broadcast request happens, I immediately update the RAM copy, and set a flag that the EEPROM needs to be updated. Then, the lazy loop (low priority task that handles EEPROM writes, display updates, housekeeping, etc.) writes it to EEPROM whenever it gets around to it. If a GET DMX Address comes in before the EEPROM write is finished, it sends the address from RAM because the EEPROM may be busy or out of date.

There's a slight risk that if the system loses power between the request and the end of the EEPROM write that the address change could be lost, but the window is very small (a few ms) and the impact if it does occur is minimal.

If you can't do this, then you may have to drop the request. RDM Broadcasts are not guaranteed to be reliable, so you are allowed to drop the packet. However, this should be avoided if at all possible.

That's really all that a responder can do.


If you're building a controller, it's a good idea to wait 10 to 20ms after sending a broadcast request before you send another broadcast packet. This will allow any poorly implemented responders time to finish processing the previous broadcast.
ericthegeek is offline   Reply With Quote