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)
-   -   What is range of typical Controller traffic? (http://www.rdmprotocol.org/forums/showthread.php?t=1232)

dj41354 November 27th, 2015 07:37 AM

What is range of typical Controller traffic?
 
Is there anything that can be said about what a responder can expect as typical RDM Controller traffic? ie.. how many RDM packets per minute would be considered heavy RDM traffic?.. how many packets per minute would be considered light RDM traffic? The reason I ask is that I'm trying to be smart about how I schedule my eeprom writes (from SET_DMX_START_ADDRESS). Thanks in advance..
Doug.

ericthegeek November 27th, 2015 11:10 PM

It's going to vary widely. During discovery, systems startup, or user configuration activities you could see several hundred requests per second. During normal operation, one RDM request per second is a common behavior in my experience, but some controllers don't send any background traffic unless the user specifically does something that requires it.

Nearly all of this background traffic will be GETs and background discovery. SETs typically only happen in response to the user deliberately making a change.

dj41354 December 7th, 2015 03:32 PM

Ok... I'm thinking about a algorithm for scheduling the eeprom write.. how about if I start a timer, say 1second, when I get a SET_DMX_START_ADDRESS command.. then if I get ANY RDM command to me (broadcast, vendorcast or unicast) I restart the time to 1second before writing the new DMX address to eeprom. What this does is tries to fins a "lull" between responding before the eeprom writes take place. Maybe 1second isn't the right value.. maybe 500msec?... Can anyone help me here?
Thanks..
Doug / BlackTank

ericthegeek December 7th, 2015 08:32 PM

Your delay/write proposal makes me uncomfortable. Depending on how traffic is scheduled on the bus, it could be a very long time before you see a long enough idle period to start the write. If the controller is collecting queued or status messages with an interval of less than your timer, the write may never happen.

What are you trying to accomplish? Are you worried about burning out the EEPROM with too many writes if the controller sends continuous SET DMX_START_ADDRESS requests? Or are you trying to find a time period when the 485 bus will be idle so your processor can ignore the UART for long enough to write the EEPROM?

If you're looking for an idle period, there only guaranteed idle you have is the 176us between packets. After that time expires, the next packet can start any time.

You really need to be able to write the EEPROM in the background. It's bad practice to ignore RDM during the few milliseconds it typically takes to complete an EEPROM write.

You might find this thread helpful, it talks a bit about scheduling NVM writes:
http://rdmprotocol.org/forums/showthread.php?t=1218

dj41354 December 8th, 2015 10:23 AM

Yeah, I was trying to find idle time to let the eeprom sequences do their thing uninterrupted. (they read back what's been written and write again if they don't match) I was hoping that if no-one has RDM'd me for say 500msec (or whatever) that I could take the next few milliseconds to execute any eeprom write that may have been requested... I'll have to think about this..
Thanks..

ericthegeek December 8th, 2015 09:26 PM

I usually do EEPROM writes in the lazy-loop, or a low-priority thread if I'm using an RTOS. The RDM handler writes the new address to RAM, and then passes a flag out to the lazy loop telling it to commit the new values to EEPROM.

The lazy loop has all of the non time-critical stuff. No one will notice an LED that blinks for 10ms longer because it's busy writing, but the time-critical stuff can proceed as a higher priority interrupt or thread.


All times are GMT -6. The time now is 11:37 PM.

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