View Single Post
Old January 27th, 2015   #3
Task Group Member
Join Date: Aug 2008
Posts: 372

Can you store the values in EEPROM instead of flash? I don't know the xMega family, but skimming the datasheet it looks like most of them have both Flash and EEPROM.

Many microcontrollers that have the ability to self-write their flash memory will stall the CPU core during a flash erase/write. But you can topically start writing to the EEPROM and then keep executing code while the EEPROM write is in progress. With this, you can save the new data in RAM, ACK it to the RDM controller, and then start writing it to EEPROM as a background task. This leaves the CPU free to respond to any new RDM traffic that occurs during the write.

Another option is that some MCUs have multiple flash banks that allow you to execute from one bank white you erase/write the other.

RDM is not a reliable protocol: Any device can drop any packet at any time for any reason (or no reason). Thus, as Scott said, you *could* ACK the request and then just ignore any DMX traffic until you've finished the 8ms write operation. You could also ACK_TIMER and do the same. But best practices call for responders to be able to receive and process all packets on the wire as long as they are sent with valid timing. You should only drop packets as a last resort.

Finally, don't forget about broadcast and vendorcast packets. Responders have 2.0ms to respond to unicast requests (E1.20 table 3-4), but broadcast packets can be sent back-to-back with only 176us between them. So you can't even depend on having 2.0ms to process the SET. A broadcast "SET FACTORY_DEFAULT" is perfectly legitimate, and a well-designed responder will be able to handle a new packet that comes 176us later even if it has to do many milliseconds of work in the background to reset everything to default.
ericthegeek is offline   Reply With Quote