Data monitor

From DIDEAS Wiki
Jump to: navigation, search

purpose

The purpose of the 'data monitor' is to provide in the 'background' the reading and modification of 'global variables' on an active platform.

design goals

  1. periodic sending of groups of telemetry packets.
  2. multiple streams of 'printf'
  3. ability to change in real time the telemetry being returned.
  4. minimum RAM and cycles load on the system
  5. limit specialize coding.

proposal

As remote reading and writing of memory address is easy, the challeng becomes determining what addresses to modify. The robotic firmware has been organized to have a relatively few number of global data structures. To avoid the need to parse linker map files, the address of each accessable data strcutre will have its address in a table as follows:

#define MONITORED_OBJECT(type, name)   (&name)
const void * data_monitor_address[] = {
  MONITORED_OBJECT(ROBOT_PARAM_T, robot_param),    // description of the object
  MONITORED_OBJECT(SENSORS_T, sensors),            // all local sensors on the platform
}


  • Create a data structure 'monitored_locations' that contain a list of addresses, and object sizes
  • Create a empty telemetery message packet large enough to store data from 'monitored_locations'
  • A function runs over entries in 'monitored_locations'. and copies the referenced data into a telemetry message packet.

issues

  • The proposed system does not lock data structures. Depending on the application layer implementation, data in a state of transition may be read/written.
  1. Reads of data structures could accrue at the end of the statemachine.
  2. Writes to data structures would be queued, and implemented before the statemachine.
  • Header files on the PC could be inconsistant with the memory map on the robot