Clearify ACK_TIMER than QUEUED_MESSAGE - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · May 15th, 2018

I recommend writing the EEPROM in the lazy loop to avoid this problem rather than blocking your RDM routine for the entire time that it takes to complete the EEPROM write.

These older posts have more details:
http://www.rdmprotocol.org/forums/sh...61&postcount=6
http://www.rdmprotocol.org/forums/sh...12&postcount=2

You don't always have 2ms to process a SET. You can take but to 2ms to respond to a unicast request, but that doesn't apply to broadcast/vendorcast requests. The controller can broadcast a SET command, and then issue a GET for the same data 176 microseconds later. If you're blocked handling the broadcast set, you'll miss the next request.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
QUEUED_MESSAGE - must controllers support this?	berntd	RDM General Implementation Discussion	4	December 11th, 2024 08:53 AM
QUEUED_MESSAGE & Status Types	pkleissler	RDM Interpretation Questions	13	August 1st, 2019 03:23 AM
Please clarify: QUEUED_MESSAGE (10.3 Collection of Queued and Status Messages)	berntd	RDM Interpretation Questions	1	September 27th, 2013 06:33 PM
QUEUED_MESSAGE - ?	berntd	RDM General Implementation Discussion	9	November 24th, 2009 08:48 AM

May 15th, 2018	#1
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	I recommend writing the EEPROM in the lazy loop to avoid this problem rather than blocking your RDM routine for the entire time that it takes to complete the EEPROM write. These older posts have more details: http://www.rdmprotocol.org/forums/sh...61&postcount=6 http://www.rdmprotocol.org/forums/sh...12&postcount=2 You don't always have 2ms to process a SET. You can take but to 2ms to respond to a unicast request, but that doesn't apply to broadcast/vendorcast requests. The controller can broadcast a SET command, and then issue a GET for the same data 176 microseconds later. If you're blocked handling the broadcast set, you'll miss the next request.