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
December 7th, 2015
Similar Threads
Threaded Mode