View Single Post
Old January 27th, 2015   #7
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 369
Default

Quote:
Originally Posted by alvangee View Post
Hell, my supervisor doesn't trust EEPROM in xMegas. He says there's been some incidents where valuable data (for example, start DMX address) in previous projects were lost, so internal flash is my only option.
I've dealt with a lot of NVM (Flash and EEPROM) corruption issues over the years. It's nearly always an implementation problem, I'm sure the Atmel part's EEPROM is fine. Often times when powering up or down, the software will start to execute at a random address. Make sure you have a reset supervisor that prevents the CPU from running unless the power is stable and well within the CPU's operating range.

Also, never write code that looks like this:
write_enable_nvm()
unprotect_nvm()
write_nvm(*addr,data)

Instead,
write_enable_nvm()
(...require some external event...)
unprotect_nvm()
write_nvm(*addr,data)

This way, if the software goes haywire and starts executing at a random address, it can't accidentally overwrite whatever *addr happens to be pointing to at that moment. Also, make sure you disable writes ASAP if the required external event doesn't happen within the expected time period.

This is true whether it's Flash or EEPROM. If your firmware (or bootloader) has code that is capable of writing NVM, you need to make darn sure that code never executes unless it's supposed to.

EEPROM really is the right solution here. If he or she doesn't trust the internal EEPROM, external EEPROMs are cheap.

Quote:
Originally Posted by alvangee View Post
As I see it, there's no way to make a well-designed responder with this configuration, I need to use external memory chip for this. With internal memory there's always will be some 8 ms cycles when responder will drop any messages while it refreshes values in flash.
Unfortunately you are correct. A well behaved RDM responder really shouldn't go out to lunch for multiple milliseconds. You can probably get away with it, but it's not good practice.

Quote:
Originally Posted by alvangee View Post
On the other hand, for me it looks just not right to send an ACK to any "change important parameter" command before this parameter was securely stored in nonvolatile memory of any sort.
Some people feel this way, that you must have stored the new data in Non-volatile memory before you ACK the request. Personally, I don't feel this is necessary. RDM is not a database where you need atomic operations and absolute certainty that the data is written. If someone sets a DMX address, and the rig loses power a few milliseconds later, they won't be shocked and appalled if it has the old DMX address when power comes back on. My personal opinion is that if you've validated the new setting, and have scheduled the write to Flash/EEPROM, it's acceptable to ACK the request.

I also feel this way because ACK_TIMER/QUEUED_MESSAGE isn't implemented perfectly in all RDM controllers. Some controllers don't use Queued Messages at all. Based on this, I believe that overall using ACK_TIMER will cause you more problems than just using ACK and scheduling the write. You can't schedule the write and wait a week to commit it to memory. but a few dozen milliseconds won't hurt anything.
ericthegeek is offline   Reply With Quote