Duet Non-Volatile Variables

amclain

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?

PhreaK

Writing the data of interest out to a file is the only way to achieve persistance... easily.

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.

amclain

Thanks Phreak, that confirms my thoughts. It sounds like writing to a file is the easiest way to get this immediate project wrapped up.

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).

PhreaK

If you're writing your own persistant memory manager class why don't you just take out the middle man and write it out to a file from there. Much more efficient.

note: you'll probably want to do a delayed write and buffer changes so that you don't kill the CF card.

amclain

Yeah, after my last post I was thinking the same thing. Since the memory manager would most likely have its own cache, it wouldn't make much of a difference on the back end as to where the persistent data is stored.

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!