Separate operating RDAC state from retained EEMEM
The value controlling the wiper and the value kept for later restoration are different state domains. ADI describes AD5235's RDAC register as the live operating state and EEMEM as retained storage. The interface can therefore have a present wiper setting while a separately retained value exists. Calling both the potentiometer setting would conceal which state the requirement concerns.
The live register directly concerns the operating resistance setting. Its volatile nature is different from the persistence of the stored EEMEM value. These descriptions concern where information resides and how it is used, rather than the nominal resistance option or the relationship between the end terminals and wiper. The electrical meaning of a setting and its retention domain remain separate questions.
This provides a useful starting point for a persistence requirement. Identify the state that must control the wiper during operation and the information intended to survive for later loading. A change to one is not evidence that the other has changed. Keeping those domains distinct avoids assigning automatic persistence to every live adjustment, without making a universal statement about every digital-potentiometer family or a current claim about an offered device.
Distinguish a live change from a completed nonvolatile store
AD5235 provides an explicit relationship between changing a live setting and storing information in nonvolatile memory. ADI describes a storage operation rather than treating every RDAC change as an automatic update of retained memory. The distinction means that an application can adjust its operating value while the value kept for restoration remains a separate question. A live adjustment and persistence have different completion meanings.
The storage process also has a busy interval and a completion indication in the source description. Starting the process is therefore different from knowing that the described internal operation has finished. A requirement about retained information needs to preserve that distinction. The fact that a live wiper already reflects a desired value does not independently identify the state of the nonvolatile operation.
These are functional stages rather than instructions for operating the interface. The useful comparison asks whether the application needs live adjustment, a retained update, or evidence associated with completion of that update. Each refers to a different part of the state relationship. No programming duration, signal level or transaction sequence is needed to explain why observing an adjusted output cannot substitute for establishing the intended retained-state operation.
Keep power-on refresh and runtime recall separate from erasure
Refresh moves retained information into the live operating domain. ADI describes power-on loading of the retained EEMEM value into RDAC and also discusses refreshing during operation. Both concern a transfer towards the state controlling the wiper. This is a different direction and purpose from storing the current operating value for future retention.
The direction matters when interpreting reset or recall terminology. In this context, recalling a value does not mean erasing retained storage. It uses retained information to establish the live setting. Reading the word reset without its source and destination could therefore reverse the meaning of the documented action, turning restoration into an unsupported claim that the stored value has become blank or returned to a universal default.
Distinguish when the transfer is expected from what information it transfers. Power-on refresh belongs to the initial establishment of live state, while runtime refresh concerns restoring that relationship during operation. Neither description establishes the actual contents of a particular device. The requirement can state the intended restoration behaviour without prescribing a control waveform, selecting a command or assuming that a retained factory description identifies the present setting of every unit.
Read back the intended state domain
Readback needs an explicit target. ADI distinguishes reading RDAC state from reading EEMEM information. The first concerns the live value associated with the wiper; the second concerns retained data. Those results answer different questions even when the application intends the two values to correspond. A generic request to read the setting would leave the state domain unidentified.
The distinction is especially useful after a live change or a refresh. Observing live RDAC describes that operating domain at the time of the observation. It does not, by itself, show that a nonvolatile store completed or that the retained value was updated to match. Likewise, information read from retained memory should not be described as an observation of the complete analog behaviour at the wiper.
Keep the intended association between the values visible while preserving their separate meanings. A persistence requirement can then distinguish the operating state, stored information, restoration direction and observation target. These four responsibilities explain the memory feature more clearly than a single nonvolatile label. This guide performs no device readback and supplies no command format; it defines which state information the application would need to establish under its own applicable implementation.
Sources and further reading
AD5235 saved prose intervals on physical pages 16, 18 and 19. State domains, store completion, refresh direction and readback roles only; SPI encodings, command sequences, programming times, endurance, current values and present-device settings are excluded.