为什么要trace机制

为什么要trace机制

因为erlang很多进程,用debuger来调试有点痛苦,如果用log的话,要在代码里面写入对应的“眼”,累了程序员不说,还影响了性能。而erlang提供了强大的trace机制,可以更好的了解整个系统的所有情况。

dbg:tracer用法

  • dbg:tracer().
    开启dbg的tracer

  • dbg:p(Item, Flags) -> {ok, MatchDesc} | {error, term()}
    设置跟踪属性.
    第一个参数Item是设定要跟踪的对象:

    • 如果Item是一个pid(),则只会trace 对应的进程,如果是在集群中,只要节点在traced nodes列表内,可以跨节点trace那个进程.

    • 如果Item是一个atom all,就会trace 整个系统所有的进程,同样可以监控整个集群。

    • 如果Item是一个atom new,就会trace 系统在此刻开始所创建的新进程,可以监控整个集群。

    • 如果Item是一个atom existing,就会trace 系统此刻之前所创建的进程,可以监控整个集群。

    第二个参数Flags是设置要监听的动作:

    • s(send) trace 进程发送的消息

    • r(receive) trace 进程受到的消息

    • m(messages) trace 进程收的或者发的消息 -.- m = s+r

    • c(call) 通过tp/2设置的匹配规则后,可以trace 进程所有的call匹配的动作。

    • p(procs) trace 与目标进程相关联的进程

    • sos(set on spwan) 使监控的进程所产生的进程继承所以trace flags

    • sol (set on link) 如果有另外的进程p2 link被监控的进程,p2会继承所有的trace flags

    • all 所有的flags

    • clear 清除所有flags

  • dbg:tp({Module, Function, Arity}, MatchSpec) -> {ok, MatchDesc} | {error, term()} 与 dbg:tpl({Module, Function, Arity}, MatchSpec) -> {ok, MatchDesc} | {error, term()}

    tpl和tp类似,只是tpl会trace 未导出函数。

    • dbg:tpl(Module, '_', []). 会trace 该module的所有的调用。

    • dbg:tpl(Module, Function, '_', []). 会trace module:function,不限定参数个数。

    • dbg:tpl(Module, Function, Arity, []). trace module:function/arity。

    • dbg:tpl(M, F, A, [{'_', [], [{return_trace}]}]). 会跟踪返回值。

附上自家项目用的tracer

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
%%%-------------------------------------------------------------------
%%% @author dp <>
%%% @copyright (C) 2012, dp
%%% @doc
%%% 项目的tracer ,用于运行时排错
%%% @end
%%% Created : 16 Oct 2012 by dp <>
%%%-------------------------------------------------------------------
-module(dika_tracer).
%% API
-export([t/3,t/2,t/1,stop/0,p/1]).
 
%%%===================================================================
%%% API
%%%===================================================================
 
%% 指定要监控的模块,函数,函数的参数个数
t(Mod)->
dbg:tpl(Mod,[{'_', [], [{return_trace}]}]).
 
 
%% 指定要监控的模块,函数
t(Mod,Fun)->
dbg:tpl(Mod,Fun,[{'_', [], [{return_trace}]}]).
 
 
%% 指定要监控的模块,函数,函数的参数个数
t(Mod,Fun,Ari)->
dbg:tpl(Mod,Fun,Ari,[{'_', [], [{return_trace}]}]).
 
 
 
%%开启tracer。Max是记录多少条数据
p(Max)->
FuncStopTracer =
fun
(_, N) when N =:= Max-> % 记录累计到上限值,追踪器自动关闭
dbg:stop_clear(),
io:format("#WARNING >>>>>> dbg tracer stopped <<<<<<~n~n",[]);
(Msg, N) ->
case Msg of
{trace, _Pid, call, Trace} ->
{M, F, A} = Trace,
io:format("###################~n",[]),
io:format("call [~p:~p,(~p)]~n", [M, F, A]),
io:format"###################~n",[]);
{trace, _Pid, return_from, Trace, ReturnVal} ->
{M, F, A} = Trace,
io:format("===================~n",[]),
io:format("return [~p:~p(~p)] =====>~p~n", [M, F, A, ReturnVal]),
io:format("===================~n",[]);
_ -> skip
end,
N + 1
end,
case dbg:tracer(process, {FuncStopTracer, 0}) of
{ok, _Pid} ->
dbg:p(all, [all]);
{error, already_started} ->
skip
end.
 
stop()->
dbg:stop_clear().
 
%%%===================================================================
%%% Internal functions
%%%===================================================================
<think>好的,用户现在问的是“trace port 选什么”。首先,我需要回顾之前的对话历史,用户之前询问过关于Keil使用ITM机制输出的问题,我详细介绍了ITM的配置和实现方法。现在用户的问题转向了Trace Port的选择,这可能是在配置ITM或更广泛的调试跟踪功能时遇到的后续问题。 首先,我需要确定用户的具体需求。Trace Port通常涉及更复杂的调试跟踪系统,比如使用ETB(Embedded Trace Buffer)还是外部TPIU(Trace Port Interface Unit)。用户可能是在配置芯片的跟踪功能时,遇到了选择不同Trace Port的情况,比如选择并行Trace Port还是串行的SWO(Serial Wire Output)。不同的Trace Port有不同的硬件要求和性能特点,用户可能需要根据他们的具体应用场景、硬件资源以及调试需求来选择合适的类型。 接下来,我需要考虑用户的背景。用户可能是一位嵌入式开发人员,正在使用ARM Cortex-M系列芯片,并且在使用Keil进行开发。他们可能已经熟悉了ITM的基本使用,现在需要进一步扩展调试功能,比如进行更详细的总线跟踪、指令跟踪或者性能分析,这就需要配置Trace Port。用户可能不太清楚各种Trace Port之间的区别,或者在选择时遇到了困难,比如硬件连接、调试器支持、带宽需求等问题。 用户可能没有明确说明他们的具体应用场景,比如是需要高带宽的指令跟踪,还是只需要低速的调试信息输出。比如,如果用户在进行实时性能分析,可能需要使用并行Trace Port来获取更高的带宽;而如果只是需要输出调试信息,SWO可能已经足够。此外,用户可能对硬件连接有疑问,比如是否需要额外的引脚,或者调试器是否支持特定的Trace Port类型。 接下来,我需要整理Trace Port的不同类型及其适用场景。常见的Trace Port包括: 1. **SWO(Serial Wire Output)**:基于单线输出,适合低带宽的ITM数据(如printf调试),不需要额外的引脚,但带宽有限。 2. **TPIU(Trace Port Interface Unit)**:支持并行或串行输出,具体取决于芯片实现。并行TPIU需要多个引脚,但提供更高的带宽,适合指令跟踪(ETM)或总线跟踪。 3. **ETB(Embedded Trace Buffer)**:芯片内部集成的存储缓冲区,不需要外部引脚,但存储容量有限,适合短时间的高带宽跟踪。 4. **并行Trace Port**:使用多个数据引脚(如4位、8位或16位),提供最大带宽,适合需要捕获大量实时数据的场景,如指令执行流。 用户可能需要根据以下因素来选择: - **调试需求**:是否需要指令跟踪(ETM)或仅需ITM输出? - **硬件资源**:是否有可用的引脚用于并行Trace Port? - **调试器支持**:使用的调试器是否支持特定的Trace Port类型(如J-Trace支持并行Trace,而J-Link仅支持SWO)? - **带宽要求**:高带宽跟踪需要并行接口,低带宽则SWO足够。 - **成本考虑**:并行Trace可能需要更昂贵的调试器(如J-Trace)和更多的硬件布线。 此外,还需要考虑芯片的具体型号和支持的跟踪功能。例如,某些Cortex-M7芯片可能支持ETM和TPIU,而低端芯片可能仅支持SWO。用户需要参考芯片的数据手册和调试架构文档来确认可用的Trace Port类型。 可能用户在选择时遇到的困惑包括如何平衡带宽和硬件复杂度,或者不确定他们的调试器是否支持所需的Trace Port。例如,使用SWO虽然简单,但带宽有限;而使用并行Trace Port需要更多的引脚和更复杂的调试器,但能提供更高的数据吞吐量。 在回答中,我需要分步骤解释不同的Trace Port类型,它们的特点、适用场景,以及选择时的考量因素。同时,提供配置示例和常见硬件搭配,帮助用户根据自身情况做出选择。还需要提醒用户检查芯片手册和调试器规格,确保兼容性。 最后,总结建议,根据不同的使用场景推荐合适的Trace Port类型,帮助用户做出决策。</think>以下是关于 Trace Port 选择的详细指南,结合实际应用场景和硬件特性进行说明: --- ### **Trace Port 选择指南** #### **1. 常见 Trace Port 类型及对比** | **类型** | **协议/接口** | **带宽** | **硬件需求** | **典型应用** | |-----------------------|--------------------|----------------|---------------------------|--------------------------------| | **SWO (Serial Wire Output)** | 单线串行 | ≤ 2 Mbps | 需 SWO 引脚 | ITM 调试输出(如 printf) | | **TPIU (并行模式)** | 多线并行(4/8/16位) | 10-200 Mbps | 需多引脚 + 高速布线 | 指令跟踪(ETM)、总线分析 | | **TPIU (串行模式)** | 高速串行(如 SWV) | 1-5 Mbps | 需 SWO 引脚 | 中速数据流(带时间戳的调试信息) | | **ETB (片上缓存)** | 内部缓冲区 | 取决于缓冲区容量 | 无需引脚 | 短时间高密度跟踪(如异常捕获) | | **外部 Trace 接口** | 专用协议(如 Aurora)| 可达 GBps | 专用硬件接口 + FPGA 支持 | 超高速实时跟踪(航空航天、通信) | --- #### **2. 选择依据** **① 调试需求优先级** - **仅需调试输出**:选择 **SWO**(成本最低,无需额外硬件) - **指令级跟踪(ETM)**:必须使用 **并行 TPIU** 或 **ETB** - **实时总线监控**:需 **并行 TPIU + 外部 Trace 分析仪** - **长时间数据记录**:需 **ETB + 外部存储** 或 **高速串行接口** **② 硬件限制** - **引脚资源紧张** → 优先 **SWO** 或 **ETB** - **PCB 布线复杂** → 避免并行 TPIU(需要等长布线) - **高频信号完整性** → 选择串行接口(如 SWV) **③ 调试器支持** - **J-Link**:支持 SWO,需 **J-Link Pro** 支持并行 TPIU - **J-Trace**:全功能支持(并行 TPIU + ETM) - **ST-Link**:仅支持 SWO(V3 版本支持有限高速模式) --- #### **3. 典型场景推荐** | **场景** | **推荐方案** | **配置示例** | |------------------------|---------------------------------|--------------------------------------------| | 基础调试(printf 输出) | SWO + ITM | Cortex-M + J-Link + SWO 引脚 | | 实时性能分析 | 并行 TPIU + ETM | Cortex-M7 + J-Trace + 4-bit 并行 Trace 接口| | 低功耗设备调试 | ETB 缓存 | 芯片内置 ETB(如 NXP LPC55xx 系列) | | 高速信号采集 | 外部 Trace 接口 + FPGA | TI Sitara + Xilinx Aurora 协议 | --- #### **4. 硬件配置步骤(以并行 TPIU 为例)** 1. **芯片端配置** ```c // 启用 ETM 和 Trace 端口(参考芯片手册) CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; TPI->ACPR = 15; // 预分频,根据主频调整 TPI->SPPR = 2; // 选择并行模式 TPI->FFCR &= ~0x1; // 禁用格式转换 ``` 2. **Keil 设置** - `Options for Target → Debug → Settings → Trace` - **Trace Port**: 选择 Parallel - **Port Width**: 匹配硬件(如 4-bit) - **Trace Clock**: ≤ 1/5 芯片主频 3. **物理连接** - 连接 `TRACECLK` + `TRACEDATA[0:3]` 到调试器 - 确保信号线长度匹配(误差 < 50mil) --- #### **5. 常见问题解决** - **时钟不同步** → 检查 `TRACECLK` 是否稳定,调整预分频值 - **数据丢失** → 降低 Trace 时钟频率或增加 Port 宽度 - **Keil 无法识别** → 更新调试器固件,确认芯片支持 ETM 功能 --- #### **6. 成本-性能权衡** | **方案** | **成本** | **性能** | **易用性** | **推荐指数** | |----------------|---------|---------|-----------|------------| | SWO | ★☆☆ | ★★☆ | ★★★★★ | 首选基础方案 | | 并行 TPIU | ★★★★ | ★★★★★ | ★★☆ | 专业调试场景 | | ETB | ★★☆ | ★★★☆ | ★★★☆ | 资源受限场景 | --- **总结建议**: - 大多数应用选择 **SWO** 即可满足需求 - 关键任务系统建议 **SWO + ETB** 组合 - 深度性能优化必须使用 **并行 TPIU + ETM** 实际选择时,请务必查阅芯片的《参考手册》和调试器规格文档,确认硬件兼容性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值