Duet Non-Volatile Variables
amclain Posts: 41
Anyone know how to access a master's non-volatile memory from inside Duet? Basically the equivalents of what the NON_VOLATILE and PERSISTENT NetLinx keywords do. Or can Duet data only be saved between reboots by writing to disk?
If you wanted to keep some data in NetLinx's non volatile or persistant memory you could modify your module stub to take these variables in as arguments. This would bring them into the scope of you module stub. From there it would require some parsing of data events on a virtual to allow you to write to these from within Duet.
However, that whole virtual device concept gives me some ideas to play around with later. Defining each non-volatile variable in NetLinx first sounds like it could quickly become a maintenance headache (like you alluded to). Taking that idea further, it sounds like there’s nothing stopping you from defining a non-volatile char array in NetLinx and then writing a software memory manager of sorts in Duet that decides how to utilize that memory block. That way the process could be encapsulated into simple method calls like Memory.write(“MyVariableName”, value).
note: you'll probably want to do a delayed write and buffer changes so that you don't kill the CF card.
The concern in the back of my head, which I have never personally tested on a NetLinx device, is memory corruption. I know this is an issue in typical embedded systems, since the power could be shut off without warning in the middle of a write or between delayed writes to the file system. I also don’t know if the operating system of a NetLinx device is already performing delayed writes to the CF card or not (based on what you said, it sounds like no). I’ve written desktop apps and know that writes are delayed by the O/S on there.
The attractive part about using the non-volatile memory is the higher tolerance of read/write cycles than a flash card. However, it sounds like the convenience of using the CF card in Duet outweighs the potential pitfalls. I guess I’ll just have to see what actually causes problems when I start writing code. It seems like the Duet community is fairly limited, but I’ll probably publish this as an open-source project if the prototype functions correctly.
Thanks for the input!