#46 Software Tracing with Binary Protocols
HTML-код
- Опубликовано: 11 ноя 2022
- This lesson explains modern software tracing based on binary protocols instead of ASCII formatting with printf. To focus the discussion, you will see a mature software tracing system called QP-Spy, which is much more suitable for real-time systems than the primitive printf method.
Contents with Timestamps:
-------------------------
1:25 The main problems of printf-style tracing
1:50 Firefighter analogy of printf-style tracing
3:08 General structure of the real-time tracing system
4:02 Introducing QP/Spy as an example of real-time tracing
4:25 Replacing MY_PRINTF with QP-Spy instrumentation
5:58 Adding board-specific code for QP/Spy
7:30 Adding QP/Spy output to the idle callback
8:30 Adding QP/Spy instrumentation in QM model
9:08 Adding QS source code to the spy build configuration
9:53 Excluding the QS group from dbg build configuration
10:50 Obtaining the QSPY host utility to receive the trace
11:43 Launching QSPY and connecting to the embedded target
12:16 Comparing QSPY output to MY_PRINTF() output
13:12 Timing the QSPY execution with a logic analyzer
14:13 Application-specific and pre-defined trace records
14:45 Inversion of control as an opportunity for software tracing
15:02 Event-driven framework as a funnel for system interactions
15:46 Enabling pre-defined trace records for state machines
16:50 Ways of obtaining the symbolic information from the code
17:07 Example: TRICE software tracing system
17:27 Example: Embedded logging with "string_constant" library
18:17 Q-Spy approach of generating symbolic "dictionaries"
19:10 Generating "object dictionaries"
19:28 Generating "signal dictionaries"
19:48 Generating "function dictionaries" (in QM)
20:32 QSPY output with symbolic information from "dictionaries"
20:51 Enabling all pre-defined trace records
21:12 Disabling a specific trace record type
22:08 The QP/Spy data protocol
22:20 Harvesting raw binary data from the embedded target
23:22 Comparision of binary data to formatted trace data
23:58 Detecting errors and gaps in the trace data
24:15 Post-processing binary data in QSPY
24:25 Demonstration of transmission error detection in QSPY
24:45 More features of QP/Spy data protocol
25:17 Benefits for sending data out of the embedded target
26:00 Software tracing as the basis for testing embedded code
26:05 Software tracing as the basis for monitoring devices
End Notes:
----------
Companion web page to this video course
www.state-machine.com/video-c...
Project download for this lesson:
www.state-machine.com/course/...
GitHub repository for projects for this video course:
github.com/QuantumLeaps/moder...
Transcript of this lesson:
www.state-machine.com/course/...
References resources:
---------------------
QP/Spy documentation:
www.state-machine.com/qtools/...
QTools downloads (contains QSPY host utility):
github.com/QuantumLeaps/qtool...
Other software tracing systems mentioned:
TRICE: github.com/rokath/trice
Embedded Logging Case Study -CppNow 2022
• Embedded Logging Case ...
Music credits:
--------------
The background music comes from:
www.bensound.com/royalty-free... 
Наука
You are the best out there supplying top quality embedded contents and open source softwares, a big thanks
A lucid and precious presentation on real time software tracing!
IMHO, the Segger RTT is the best lib for printing stuff while debugging. It's very fast, doesn't require RTOS and UART and is hardware(mcu) independent.
However, it requires the J-link debugger attached to the target and RTT client software.
@iRepair: Yes, absolutely. QP/Spy specifically separates buffering of the tracing output from sending the output out. This sending can be done over any type of connection not just UART. Segger RTT over the J-Tag would be fantastic for that. The "only" problem is the reception of the RTT data on the host, for which you'd need Segger DLL (on Windows), which Segger keep proprietary and not available for open-source software like the QSPY host utility. If you're interested, there is a whole discussion about it on the QP Support Forum: sourceforge.net/p/qpc/discussion/668726/thread/5b598415 . --MMS
Hello ... You are awesome !
Hello,could you please upload more often new lecture videos to your channel?Thanks.
New videos are on the way! If you'd like to see more videos like that, please make sure you *subsrcibe* and spread the word about this channel. That would be a great help! --MMS
I am using segger rtt for printf tracing.
my problem is that my output window on host getting polluted with repeated printf messages because I have multiple while loops which runs every x ms. Some modules runs every seconds so I cannot see the printf messages from these.
do you have any good advice for that?
Hi MMS, I am doing one step by step learning, can the qspy be include without the qpc ? I just want to try to make a dummy test with a simple trace delay in a while loop. I tried to add files from (QPC)/src/qs + (QPC)/include + (QP_PORT_DIR) and "removing" from here, but i am not getting something, should I dig more in that direction or QSPY by conception is linked to QPC and cannot be used alone ?
The QP/Spy software tracing is currently intertwined with the QP/C framework and it is not trivial to separate it. There are some provisions to make the Spy tracing standalone (e.g., there is a separate QS critical section mechanism), but there are a lot of other dependencies. For example, the pre-defined trace records are specific to QP. --MMS
@@StateMachineCOM thanks for your answer, let's then go with a bigger step then; with QP/C 😅
Looks like DMA would serve a very good purpose in QSPY
Yes, absolutely. DMA would relieve the CPU from brain-dead data movement so that the CPU has more time for real-time. But this is also generally true for event-driven programming, where you try to process events quickly in short run-to-completion steps. In that case the CPU would only program the DMA, but will not "babysit" actual data movement.