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
Copy file name to clipboardExpand all lines: doxygen/qpspy.dox
+7-6Lines changed: 7 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ So the questions are: How can you monitor the behavior of a running real-time sy
9
9
Techniques based on **software tracing** can answer many of these questions. Software tracing is a method for obtaining diagnostic information in a live environment without the need to stop the application to get system feedback. Software tracing always involves some form of target system instrumentation to log interesting discrete events for subsequent retrieval from the system and analysis.
10
10
11
11
@anchor qpspy_framework
12
-
@note
12
+
@remarks
13
13
Software tracing is particularly effective and powerful in combination with the event-driven **reactive programming** model, such as the one implemented in <a class="extern" target="_blank" href="https://www.state-machine.com/products/#QP">QP™ real-time frameworks</a>. Due to the inversion of control, a real-time framework controls almost all interesting interactions in the system, so an instrumented real-time framework can provide much **more comprehensive** and detailed information than can any traditional RTOS kernel.<br>
14
14

15
15
@@ -122,19 +122,20 @@ Of course, now the Escape byte itself must also be transparent to avoid interpre
122
122
123
123
The transparency of the Flag and Escape bytes complicates slightly the computation of the Checksum. The transmitter computes the Checksum over the Frame Sequence Number, the Record-Type, and all Data bytes before performing any “byte-stuffing”. The receiver must apply the exact reversed procedure of performing the “byte-un-stuffing” before computing the Checksum.
124
124
125
-
An example may make this clearer. Suppose that the following trace record needs to be inserted into the trace buffer (the transparent bytes are shown in bold):
125
+
An example may make this clearer. Suppose that the following trace record needs to be inserted into the trace buffer (the transparent bytes are shown in in `code` format):
126
126
127
-
> Record-Type = <b>0x7D</b>, Record Data = <b>0x7D</b> 0x08 0x01
127
+
Record-Type = `0x7D`, Record Data = `0x7D` 0x08 0x01
128
128
129
129
Assuming that the current Frame Sequence Number is, say `0x7E`, the Checksum will be computed over the following bytes:
Obviously, this is a degenerate example, where the Frame Sequence Number, the Record-Type, a Data byte, and the Checksum itself turned out to be the transparent bytes. Typical overhead of transparency with real trace data is one escape sequence per several trace records.
137
+
@note
138
+
This is a degenerate example, where the Frame Sequence Number, the Record-Type, a Data byte, and the Checksum itself turned out to be the transparent bytes. A more typical overhead of transparency with real trace data is one escape sequence per several trace records.
0 commit comments