Difference between revisions of "Data monitor"
From DIDEAS Wiki
m (Created page with "=purpose= The purpose of the 'data monitor' is to the permit the reading and modification of 'global variables' on an active platform with minimum overhead to the system. =pro...") |
m |
||
Line 1: | Line 1: | ||
=purpose= | =purpose= | ||
− | The purpose of the 'data monitor' is to the | + | 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= | ||
+ | #periodic sending of groups of telemetry packets. | ||
+ | #multiple streams of 'printf' | ||
+ | #ability to change in real time the telemetry being returned. | ||
+ | #minimum RAM and cycles load on the system | ||
+ | #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: | ||
+ | |||
+ | <pre> | ||
+ | #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 | ||
+ | } | ||
+ | </pre> | ||
− | |||
* Create a data structure 'monitored_locations' that contain a list of addresses, and object sizes | * Create a data structure 'monitored_locations' that contain a list of addresses, and object sizes |
Latest revision as of 15:56, 6 November 2010
Contents
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
- periodic sending of groups of telemetry packets.
- multiple streams of 'printf'
- ability to change in real time the telemetry being returned.
- minimum RAM and cycles load on the system
- 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.
- Reads of data structures could accrue at the end of the statemachine.
- 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