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.