---

Persistent_Interface Class Reference

Mechanism for prompting user for values and entering into persistent memory. More...

#include <persistent_interface.h>

Inheritance diagram for Persistent_Interface:

Public Member Functions
	Persistent_Interface (void)
	Note: the HOST constructor reads the file "RAM.ini" and stores in the simulated memory ready for load_configuration.
	Persistent_Interface (void *const, OBJECT)
int	query (int *const variable, char *message, WSIM_ID ID)
	Generic query (both prompts for value and stores away) for associated storage ID (note must be valid STORAGE ID).
void	query_waypoints ()
	gets waypoints to travel.
void	inform (const char *const imessage)
Data Fields
oDialogue	MOS_gui
Protected Attributes
void *	_speaker
OBJECT	_SpeakerType

---

Detailed Description

Mechanism for prompting user for values and entering into persistent memory.

Operation

On the 68332, the makefile etc. needs to reserve a 1K block of RAM that is set. Usually, the top of RAM is used for the stack and grows down, thus I simply moved the top of the the stack pointer down by 1K. The Persistent_Interface class simply reads from and writes to this memory. Note all writes are the same size; i.e., short--thus any other data, must be stored as 16 bit short and then reassembled in the user portion.

Host On the HOST side, it simply allocates a structure of MAX_RAM bytes and uses this

as its storage. The constructor loads this structure from a file "RAM.ini" and the deconstructor rewrites this structure to disk; thus, if the program does not terminate normally and bypasses the deconstructor, then all modifications to persistent storage will be lost. Note, this is not the case on the 68332 side where it is immediately stored in battery backed RAM.

Note:

Ideally, we should be able to use various input/output devices on top of the peristent class, but in reality it becomes difficult to manage without resorting to STL or virtual functions which can cause some embedded platforms grief and incurrs overhead. Again, ideally, this could work if all input/output devices had common API interface call it oInterface, then each specific API subclasses this using virtual methods...oInterface_KeypadLCD, for example, or oInterface_Plasma_Keyboard; finally... just ideas--needs more refinement.

---

Constructor & Destructor Documentation

Persistent_Interface (  void   )

Note: the HOST constructor reads the file "RAM.ini" and stores in the simulated memory ready for load_configuration.

Persistent_Interface (  void *  const, OBJECT  )

---

Member Function Documentation

void inform (  const char *const  imessage  )

int query (  int *const  variable, char *  message, WSIM_ID  ID )

Generic query (both prompts for value and stores away) for associated storage ID (note must be valid STORAGE ID).

void query_waypoints (   )

gets waypoints to travel.

---

Field Documentation

void* _speaker [protected]

OBJECT _SpeakerType [protected]

oDialogue MOS_gui

---