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/history.dox
+32-3Lines changed: 32 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,38 @@
1
1
/**
2
2
@page history Revision History
3
3
4
+
5
+
@section qtools_6_9_1 Version 6.9.1, 2020-09-28
6
+
7
+
The main purpose of this release is to adjust @ref qutest and @ref qview to the new @ref qs_local "QS Local Filter" design implemented in [QP/C](https://www.state-machine.com/qpc) and [QP/C++](https://www.state-machine.com/qpcpp) 6.9.1. Specifically, the loc_filter() and ao_filter() functions in @ref qutest_script "QUTest scripts" and in @ref qview_script "QView scripts" have been re-designed. Additionally, the @ref qview_loc "QView Local Filter menu" have been adjusted accordingly.
8
+
9
+
@note
10
+
The change in the loc_filter() command has implications for the existing @ref qutest_script "QUTest scripts". Specifically, the parameters of loc_filter() are no longer object names but rather "QS-IDs" (see the documentation to loc_filter()).
11
+
12
+
__Changes in QSPY__
13
+
14
+
The @ref qspy "QSPY host application" has been updated to handle the redesigned local-filters and the new predefined #QS_QF_NEW_ATTEMPT trace record. Also the default version compatibility with the @ref qs "QS target-resident component" (the `-v` @ref qspy_command "command-line option") has been increased from 6.2 to 6.6.
15
+
16
+
Additionally, the QS_U64() and QS_I64() data elements have been made available for all types of CPUs, whereas previously they were available only on 64-bit CPUs (see also [feature#181](https://sourceforge.net/p/qpc/feature-requests/181)).
17
+
18
+
Additionally, QSPY now can format @ref qs_app "application-specific data elements" in hexadecimal. Here are a few examples of QS trace records in the Target and the generated QSPY output:
- [feature#181 "use of QS_U64() on 32 bit machine"](https://sourceforge.net/p/qpc/feature-requests/181)
31
+
32
+
4
33
@section qtools_6_9_0 Version 6.9.0, 2020-08-21
5
34
6
-
This release represents a major overhaul of QTools. Specifically, this release brings the new @ref qview component, which replaces QSpyView written originally in Tcl/Tk. The new @ref qview "QView" is written in **Python** (3.3.+) and brings much commonality with the @ref qutest, which has also been re-structured and improved.
35
+
This release brings the new @ref qview component, which replaces QSpyView written originally in Tcl/Tk. The new @ref qview "QView" is written in **Python** (3.3.+) and brings much commonality with the @ref qutest, which has also been re-structured and improved.
7
36
8
37
@note
9
38
Starting with this version, both @ref qview and @ref qutest require **Python3** (3.3+) and are **no longer compatible** with Python2. The support for Tcl/Tk has been dropped entirely in QTools.
@@ -26,7 +55,7 @@ qtools/
26
55
+---qview/ # <== new qview location
27
56
+---qwin/
28
57
+---Unity/
29
-
@endcode
58
+
@endcode
30
59
31
60
@note
32
61
The changes in the QTools directory structure have impact on the QUTest testing, because the Makefiles (or any other build tools you might be using) need to be adjusted to the new location of the `qutest.py` script.
@@ -39,7 +68,7 @@ This new feature replaces the previous support for MscGen and is no longer relia
39
68
40
69
- QSPY now recognizes the new QS trace record #QS_QF_RUN
41
70
42
-
@note
71
+
@note
43
72
The #QS_QF_RUN record is now generated in @ref qutest "QUTest", which requires adjustments in the existing @ref qutest_script "test scripts". Specifically, the test scripts that provide their own on_reset() callback must now also call expect_run().
Copy file name to clipboardExpand all lines: doxygen/qpspy.dox
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -110,9 +110,9 @@ The QS protocol transmits each trace record in an HDLC-like frame. The upper par
110
110
111
111
1. Each frame starts with the Frame **Sequence-No** byte. The target QS component increments the Frame Sequence Number for every frame inserted into the circular buffer. The Sequence Number naturally rolls-over from 255 to 0. The Frame Sequence Number allows the QSPY host component to detect any data discontinuities.
112
112
113
-
2. Following the Fame Sequence Number is the **Record-ID** byte, which is one of the predefined QS records, or an application-specific record.
113
+
2. Following the Fame Sequence Number is the **Record-Type** byte, which is one of the predefined QS records, or an application-specific record.
114
114
115
-
3. Following the Record-ID is zero or more **Data** bytes.
115
+
3. Following the Record-Type is zero or more **Data** bytes.
116
116
117
117
4. Following the data is the **Checksum**. The Checksum is computed over the Fame Sequence Number, the Record ID, and all the Data bytes. The next section gives the detailed Checksum computation formula.
118
118
@@ -127,11 +127,11 @@ One of the most important characteristics of HDLC-type protocols is establishing
127
127
128
128
Of course, now the Escape byte itself must also be transparent to avoid interpreting an unintentional Escape byte as the two-byte escape sequence. The procedure of escaping the Escape byte is identical to that of escaping the Flag byte.
129
129
130
-
The transparency of the Flag and Escape bytes complicates slightly the computation of the Checksum. The transmitter computes the Checksum over the Fame Sequence Number, the Record-ID, 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.
130
+
The transparency of the Flag and Escape bytes complicates slightly the computation of the Checksum. The transmitter computes the Checksum over the Fame 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.
131
131
132
132
An example may make this clearer. Suppose that the following trace record needs to be inserted to the trace buffer (the transparent bytes are shown in bold):
133
133
134
-
Record-ID = 0x7D, Record Data = 0x7D 0x08 0x01
134
+
Record-Type = 0x7D, Record Data = 0x7D 0x08 0x01
135
135
136
136
Assuming that the current Fame Sequence Number is, say `0x7E`, the Checksum will be computed over the following bytes:
137
137
@@ -141,7 +141,7 @@ and the actual frame inserted into the QS trace buffer will be as follows:
Obviously, this is a degenerated example, where the Frame Sequence Number, the Record-ID, 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.
144
+
Obviously, this is a degenerated 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.
0 commit comments