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 November 27th, 2015   #1
dj41354
Member
 
Join Date: Nov 2015
Posts: 30
Default 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.
dj41354 is offline   Reply With Quote
Old November 28th, 2015   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

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.
ericthegeek is offline   Reply With Quote
Old December 7th, 2015   #3
dj41354
Member
 
Join Date: Nov 2015
Posts: 30
Default

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
dj41354 is offline   Reply With Quote
Old December 7th, 2015   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

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
ericthegeek is offline   Reply With Quote
Old December 8th, 2015   #5
dj41354
Member
 
Join Date: Nov 2015
Posts: 30
Default

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..
dj41354 is offline   Reply With Quote
Old December 8th, 2015   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

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.
ericthegeek 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
SELF_TEST_DESCRIPTION index range tim_ecue RDM General Implementation Discussion 16 February 25th, 2011 10:25 AM


All times are GMT -6. The time now is 04:58 PM.


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