You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This concept is for tracing execution (AKA Autopsy for JPL folks). Tracing allows an on-board log to be built of software execution where various points in the software a sample point can be saved with a time tag. The data would be stored on a per-thread basis. The data is stored in buffers, and then save to storage as a Data Product for later downlinking.
The work would consist of:
1) New FPP specification (for example):
trace StartRateGroup (
cycle: U64 @< The cycle count
) \
type execution \
id 0x01
This would turn into code-generated functions that the user could call when a trace event happens. The FPP can specify arguments like cycle that are custom, and they would be serialized into a trace record that includes the id, a time tag, and the user arguments.
Trace points would be automatically generated for the following autocoded actions:
Action
Stored
Port call
Port id, arguments
Command port call
Command opcode, arguments
Message Wait
Message dequeue
Message ID
Output port call
Port ID, arguments
The trace entries could be put in the dictionary so a ground system could automatically decode the trace data.
2) Implement a new trace port type. It could look a lot like an event port:
port Trace(
$id: FwTraceIdType @< Trace ID
ref timeTag: Fw.Time @< Time Tag
$type: TraceType @< The trace type argument
ref args: TraceBuffer @< Buffer containing serialized trace entry
)
3) Implement a basic in-memory logger with data products to dump the buffers. Projects could write more sophisticated versions or embedded versions if they like.
Since this feature could consume significant code and processing, it should be a feature that can be turned on and off.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This concept is for tracing execution (AKA Autopsy for JPL folks). Tracing allows an on-board log to be built of software execution where various points in the software a sample point can be saved with a time tag. The data would be stored on a per-thread basis. The data is stored in buffers, and then save to storage as a Data Product for later downlinking.
The work would consist of:
1) New FPP specification (for example):
This would turn into code-generated functions that the user could call when a trace event happens. The FPP can specify arguments like
cycle
that are custom, and they would be serialized into a trace record that includes the id, a time tag, and the user arguments.Trace points would be automatically generated for the following autocoded actions:
The trace entries could be put in the dictionary so a ground system could automatically decode the trace data.
2) Implement a new trace port type. It could look a lot like an event port:
3) Implement a basic in-memory logger with data products to dump the buffers. Projects could write more sophisticated versions or embedded versions if they like.
Since this feature could consume significant code and processing, it should be a feature that can be turned on and off.
Beta Was this translation helpful? Give feedback.
All reactions