1. 项目概述：在资源受限的ColdFire平台上构建网络通信核心

在嵌入式开发领域，尤其是工业控制、远程监控和早期的物联网节点设计中，为资源受限的微控制器（MCU）赋予网络通信能力一直是个既基础又充满挑战的任务。这不仅仅是简单地移植一个协议栈，更是在有限的RAM、Flash和CPU主频下，对实时性、可靠性和资源消耗进行精妙平衡的艺术。飞思卡尔（Freescale，现为NXP的一部分）的ColdFire系列处理器，凭借其平衡的性能与功耗，曾是许多此类应用的经典选择。而围绕它构建的这套TCP/IP协议栈与轻量级RTOS的集成方案，正是一个典型的、从工程实践中淬炼出来的解决方案。

这套方案的核心价值在于，它没有选择庞大、全功能的开源协议栈（如lwIP的早期版本或uIP），而是基于一个名为“Nichelite”的迷你IP层，深度定制了一套与特定RTOS绑定的网络协议栈。它包含了ARP、IP、ICMP、UDP、TCP等核心协议，并在此基础上实现了HTTP服务器、TFTP、DHCP客户端和DNS客户端等应用层服务。整个系统运行在一个简单的、非抢占式的轮询调度RTOS之上，或者也可以完全绕过RTOS，以“超级循环”（Superloop）模式运行。这种设计哲学非常明确：为特定的硬件平台（ColdFire + Fast Ethernet Controller）和应用场景，做最大程度的优化和裁剪，用最小的资源开销实现可用的网络功能。

对于今天仍在维护或开发基于经典32位MCU项目的工程师来说，理解这种深度集成的设计思路，远比单纯调用某个现成库的API更有价值。它能让你透彻理解数据包从网卡到应用层的完整路径，理解任务调度如何与网络事件处理协同，以及如何在内存捉襟见肘时做出合理的配置取舍。接下来，我将结合文档和实际工程经验，为你拆解这套系统的设计精髓、实现细节以及那些在数据手册里不会写的“踩坑”心得。

2. 系统架构与RTOS深度解析

2.1 双模运行机制：超级循环与多任务RTOS

这套系统的第一个关键设计点是其灵活的运行模式。它提供了两种截然不同的任务调度机制，以适应不同复杂度的应用需求。

超级循环模式 ，通过将 SUPERLOOP 宏定义为1来启用。在这种模式下，RTOS的核心调度功能被禁用。整个应用程序，包括网络协议栈的状态机、菜单系统、用户任务等，都只是一系列在 main() 函数 while(1) 循环中被依次调用的函数。所有函数共享同一个系统栈。

模式选择的核心考量 ：选择超级循环模式的首要驱动力是 极致的内存节省 。因为没有额外的任务控制块（TCB），也没有为每个任务独立分配栈空间，所以RAM开销最小。它的缺点同样明显：所有函数必须是非阻塞的，执行时间不能过长，否则会拖慢整个循环，影响网络响应和实时性。这要求开发者采用严格的状态机编程范式来设计每个“任务”函数。例如，网络包处理函数 packet_check() 必须快速检查是否有数据待处理并立即返回，不能等待一个完整的TCP数据包接收完毕。

多任务RTOS模式 ，通过定义 INICHE_TASKS 宏启用。此时，系统会初始化一个简单的非抢占式轮询调度器。每个任务（如网络栈、菜单、用户应用）都拥有独立的TCB和从堆（heap）中动态分配的独立栈空间。调度器简单地遍历一个TCB链表，如果任务处于“就绪”状态，则执行其入口函数。

RTOS模式下的内存管理玄机 ：在RTOS模式下，每个任务的栈大小是在编译时静态定义的（例如 NET_STACK_SIZE 4096 ）。这里有一个极易被忽略的陷阱： 这个栈大小不仅要满足任务函数本身的调用深度和局部变量需求，还必须为中断服务程序（ISR）的上下文保存预留足够空间 。因为任何任务在执行时都可能被中断打断，中断上下文会保存在当前运行任务的栈中。这意味着，如果你为一个简单任务只分配了256字节的栈，但系统中存在一个嵌套较深或局部变量较多的中断，很可能导致栈溢出，破坏相邻内存区域。因此，在 osport.h 中设置栈大小时，必须进行最坏情况下的评估，通常需要预留数百字节的裕量。

2.2 RTOS内核机制与任务调度实况

这个轻量级RTOS的内核非常简洁，其核心数据结构是任务控制块（TCB）。TCB是一个链表结构，包含了任务栈指针、栈大小、任务名、状态标志和唤醒时间戳等关键信息。

调度器的工作流程完全由应用主动驱动：当一个任务调用 tk_block() 或 tk_sleep() 时，才会发生任务切换。 tk_block() 函数是调度器的核心，它首先检查当前任务栈的“守卫字”以探测栈溢出，然后遍历TCB链表，寻找下一个状态为“就绪”的任务，最后通过汇编函数 tk_switch 进行上下文切换。

实操心得： cticks 全局变量的维护 ：RTOS的时间感知完全依赖于一个全局变量 cticks ，它需要由一个硬件定时器中断定期递增（例如每10ms一次）。这个细节在文档中一笔带过，但在移植时却是致命的关键。如果 cticks 更新不及时或不准确，所有基于时间的操作（如 tk_sleep 、TCP超时重传）都会紊乱。你必须确保初始化代码中正确配置了定时器，并且其中断服务程序能可靠地执行 cticks++ 。此外， cticks 的数据类型是 unsigned long ，需注意其溢出处理，但内核的睡眠比较逻辑 (cticks > TCB->tk_waketick) 在无符号数运算下可以正确处理溢出。

任务间通信的朴素实现 ：除了睡眠，任务还可以通过“事件”机制进行同步。 tk_ev_block(void *event) 使任务阻塞在一个特定的事件值上， tk_ev_wake(void *event) 则唤醒所有等待该事件的任务。协议栈内部正是利用了这一机制来实现阻塞式套接字。当应用调用 recv() 等待数据时，协议栈会将当前任务阻塞在“该套接字地址”这个唯一事件上。当网卡中断服务程序收到属于此套接字的数据包后，协议栈调用 tk_ev_wake() 并传入套接字地址，从而唤醒正在阻塞等待的任务。这是一种非常高效且节省资源的同步方式。

3. TCP/IP协议栈的配置、内存管理与优化

3.1 协议栈的模块化配置与裁剪

协议栈的功能通过 ipport.h 头文件中一系列宏定义来启用或禁用，这是一种经典的“编译时配置”策略，旨在为最终映像节省每一字节的Flash和RAM。

例如：

#define INCLUDE_ARP             1   // 启用ARP协议
#define MINI_IP                 1   // 使用轻量级IP层（Nichelite）
#define MINI_TCP                1   // 使用轻量级TCP层
#define DHCP_CLIENT             1   // 启用DHCP客户端
// #define DNS_CLIENT          1   // 注释掉，禁用DNS客户端以节省空间

配置策略的经验之谈 ：

  1. 按需启用 ：如果你的设备只需要做TCP客户端上传数据，那么UDP、ICMP、TFTP服务器、DNS等模块都可以关闭。特别是 NET_STATS （网络统计）和 QUEUE_CHECKING （队列检查）这类调试功能，在量产固件中务必关闭。
  2. 理解依赖关系 ：启用 DHCP_CLIENT 通常需要 UDP 支持。而 MINI_IP 和 MINI_TCP 是一套精简协议实现，与标准的BSD Socket API可能不完全兼容，启用 BSDISH_RECV/SEND 宏可以提供类似的接口。
  3. 静态IP与DHCP的互斥 ：文档中强调了一个关键点： 若要使用DHCP客户端，必须确保 netstatic[0].n_ipaddr 等字段初始化为0 。如果初始化为一个非零的静态IP，DHCP客户端会误以为这是之前分配的地址，从而进入“续租”流程而非“发现”流程，导致无法从DHCP服务器获取新地址。这个坑我踩过，现象就是设备网络一直不通，抓包发现它在疯狂发送DHCP REQUEST而不是DISCOVER。

3.2 零拷贝缓冲区管理与内存布局

这是嵌入式TCP/IP协议栈设计的精髓所在，直接决定了系统的性能和内存使用效率。该栈采用了独立于系统堆（heap）的专用包缓冲区管理机制，由 pktalloc.c 中的 pk_alloc() 和 pk_free() 函数管理。

系统维护两种尺寸的缓冲区池：

  • 大缓冲区 ：大小为 bigbufsiz ，用于接收以太网帧。因为接收时帧长度未知，必须按最大可能尺寸（如1518字节加上一些对齐开销）分配。
  • 小缓冲区 ：大小为 lilbufsiz ，用于发送较小的数据包（如TCP ACK确认包），以提高内存利用率。

内存布局与硬件（FEC）的交互如图所示：接收缓冲区描述符环（RxBDs）和发送缓冲区描述符环（TxBDs）直接指向这些由 pk_alloc 管理的内存块。当FEC硬件接收到一个包时，DMA会直接将其写入一个空闲的“大缓冲区”，然后产生中断。协议栈的中断服务程序解析以太网头，根据IP和TCP/UDP端口信息，将整个缓冲区（或零拷贝地传递其指针）递交给相应的套接字或应用任务。

零拷贝的实践意义与陷阱 ： “零拷贝”在此上下文中意味着，数据从网卡DMA区域到应用层， 在整个协议栈处理过程中，没有进行内存拷贝 。应用拿到的可能直接就是指向 bigbuff 中某个位置的指针。这带来了巨大的性能优势，但也带来了责任：

  1. 应用必须尽快处理数据 ：因为缓冲区是全局复用的，处理完数据后必须及时调用 pk_free() 释放缓冲区，否则很快会导致缓冲区耗尽，网络瘫痪。
  2. 避免在应用层长时间持有缓冲区指针 ：特别是在RTOS多任务环境下，如果任务在取得数据指针后因等待其他资源而被挂起，会阻塞该缓冲区的重用。
  3. 小缓冲区大小 lilbufsiz 的设定 ：文档建议必须大于一个TCP ACK包的长度（约60字节含以太网头）。在实际中，我建议至少设置为256字节或更大，以容纳常见的HTTP请求/响应头或小的传感器数据包，避免本可用小缓冲区的发送操作被迫使用大缓冲区，造成内存浪费。

3.3 关键网络服务的集成与配置

DHCP客户端的集成流程 ：

  1. 在 ipport.h 中启用 DHCP_CLIENT 。
  2. 在 allports.c 的 netmain_init() 函数中，确保在调用 ip_startup() 初始化IP层后，再调用 dhc_setup() 。
  3. dhc_setup() 会启动一个状态机，依次发送DISCOVER、处理OFFER、发送REQUEST、等待ACK。这个过程是阻塞的（在超级循环模式下，会通过多次循环调用才完成），因此网络初始化阶段需要给予足够的时间（通常2-5秒）来完成DHCP交互。
  4. 成功获取IP后，获取到的地址、网关、子网掩码和DNS服务器地址会填充回 netstatic 结构体。

DNS客户端的用法 ：

  1. 启用 DNS_CLIENT 宏。
  2. 必须在 dnsclnt.c 中手动填充 dns_servers[] 数组，通常是从DHCP获取的DNS服务器地址，或硬编码的公共DNS（如8.8.8.8）。
  3. 应用层通过 gethostbyname() 函数解析域名。首次解析会触发真正的DNS查询，结果会被缓存。后续对同一域名的解析会直接读取缓存，由 dns_check() 函数（需定期调用）维护缓存的超时更新。

4. 从零开始移植与工程实践指南

4.1 硬件抽象层与驱动适配

移植工作的起点是硬件抽象层（HAL）和驱动程序。对于ColdFire平台，核心是Fast Ethernet Controller (FEC) 驱动和PHY芯片的MII管理接口。

FEC驱动适配 ：主要工作集中在 ifec.c 文件。你需要根据自己板卡的SDRAM或SRAM内存布局，正确配置FEC的接收和发送缓冲区描述符表（BD表）的基地址。 NUM_TXBDS 和 NUM_RXBDS 定义了描述符的数量，通常各设置3-5个即可平衡性能和内存占用。最关键的是，每个描述符的数据缓冲区指针必须指向由 pk_alloc 系统管理的内存块。在驱动初始化函数中，你需要调用 pk_alloc(MAX_ETH_PKT) 为每个RxBD分配一个大缓冲区，并将其物理地址（注意可能需要转换为FEC可访问的总线地址）填入BD中。

PHY芯片初始化 ： mii.c 文件提供了MII管理接口的读写函数。你需要根据板载PHY芯片的型号（如DP83848, KSZ8041等），修改PHY的复位、自动协商和链路状态检测流程。一个常见的步骤是在 mii_init() 函数中，写入PHY的控制寄存器以启动自动协商，然后轮询状态寄存器直到链路建立。

踩坑记录：PHY地址与中断 ：ColdFire的FEC可能支持多个MII接口。 mii.c 中的 PHY_ADDR 宏定义了PHY的MII地址，这个地址由硬件电路的上拉/下拉电阻决定，务必与原理图核对。此外，是采用查询方式还是中断方式检测链路状态变化，需要权衡。查询方式简单，但会占用CPU周期；中断方式更高效，但需要正确配置PHY的中断掩码和FEC的中断线。对于稳定性要求高的产品，建议采用中断方式，并在链路中断服务程序中妥善处理网络重连逻辑。

4.2 协议栈初始化流程与主循环设计

一个正确的初始化顺序至关重要，以下是一个典型的 main() 函数流程：

int main(void) {
    // 1. 硬件底层初始化：时钟、GPIO、串口
    sysinit();
    // 2. 初始化堆内存管理器（memio.c）
    memio_init();
    // 3. 初始化RTOS（如果启用），创建主任务
    tk_init(&main_stack, MAIN_STACK_SIZE);
    // 4. 初始化网络硬件：FEC, PHY
    fec_init();
    mii_init();
    // 5. 设置MAC地址（写入ifec.c中的mac_addr_fec数组）
    set_mac_address();
    // 6. 如果使用静态IP，在此处配置netstatic数组
    // netstatic[0].n_ipaddr = IP_ADDR(...);
    // 7. 初始化协议栈核心
    ip_startup();
    // 8. 如果启用DHCP，启动DHCP客户端
    #ifdef DHCP_CLIENT
    dhc_setup();
    #endif
    // 9. 创建网络任务（如HTTP服务器、自定义应用任务）
    TK_NEWTASK(&http_task_info);
    TK_NEWTASK(&my_app_task_info);
    // 10. 进入主调度循环
    for(;;) {
        tk_block(); // 在RTOS模式下，进行任务调度
        // 在超级循环模式下，则是依次调用各个任务函数
        // packet_check();
        // inet_timer();
        // user_task1();
        // ...
    }
    return 0;
}

主循环设计的注意事项 ：

  • 在RTOS模式下， tk_block() 是调度点，所有任务函数内部必须在适当的时候调用 tk_sleep() 或 tk_block() 主动让出CPU。
  • 在超级循环模式下，每个任务函数必须是 非阻塞、短时间执行 的。例如， packet_check() 函数应该只处理当前已接收到的单个数据包，然后立即返回。
  • 无论哪种模式，都必须定期调用 inet_timer() 函数。这个函数处理TCP/IP协议栈内部所有的定时事件，如TCP重传定时器、ARP缓存过期、DHCP租约更新等。通常放在主循环中每100ms调用一次。

4.3 应用层开发：基于Mini-Socket API

协议栈提供了一套名为“Mini-Socket”的API，它比标准的BSD Socket更轻量。创建一个TCP服务器的基本流程如下：

void my_http_server_task(int param) {
    int listen_sock, client_sock;
    struct sockaddr_in my_addr;
    // 创建监听套接字
    listen_sock = socket(AF_INET, SOCK_STREAM, 0);
    // 绑定地址和端口
    my_addr.sin_family = AF_INET;
    my_addr.sin_port = htons(80);
    my_addr.sin_addr.s_addr = INADDR_ANY;
    bind(listen_sock, (struct sockaddr*)&my_addr, sizeof(my_addr));
    // 开始监听
    listen(listen_sock, 1);
    for(;;) {
        // 接受连接（这是一个阻塞调用，在RTOS下会触发任务切换）
        client_sock = accept(listen_sock, NULL, NULL);
        if(client_sock >= 0) {
            // 处理HTTP请求（简化示例）
            char buffer[256];
            int len = recv(client_sock, buffer, sizeof(buffer)-1, 0);
            buffer[len] = '\0';
            // 解析请求并发送响应...
            char *response = "HTTP/1.1 200 OK\r\nContent-Length: 13\r\n\r\nHello, World!";
            send(client_sock, response, strlen(response), 0);
            // 关闭连接
            closesocket(client_sock);
        }
        // 让出CPU，避免独占
        TK_SLEEP(10);
    }
}

开发心得：处理阻塞与超时 ： Mini-Socket的 recv() , accept() , connect() 等函数在 BLOCKING_APPS 宏启用时是阻塞的。这意味着调用任务会睡眠，直到事件发生。这简化了编程模型，但你必须小心 死锁 和 资源泄漏 。

  1. 设置合理的超时 ：协议栈可能支持通过 setsockopt() 设置套接字超时。务必为每个阻塞操作设置超时，并在超时后关闭套接字，清理资源。
  2. 任务栈空间 ：处理网络连接的任务，其栈空间（ APP_STACK_SIZE ）需要设置得足够大，因为HTTP解析、字符串处理等操作可能会使用较多的局部变量。
  3. 连接管理 ：在嵌入式设备中，同时处理的连接数非常有限。务必在代码中严格管理，及时关闭不再使用的套接字。一个常见的错误是只处理了数据收发，但忘记在错误或超时路径中调用 closesocket() 。

5. 调试技巧、性能优化与常见问题排查

5.1 调试基础设施：串口菜单与状态监控

系统内置的串口菜单系统是一个强大的调试工具。通过简单的 install_menu() API，你可以添加自定义命令，用于实时查看系统状态、修改变量或触发测试功能。

例如，添加一个查看所有TCP连接状态的命令：

struct menu_op my_debug_menu[] = {
    "conn",     dump_tcp_connections, "Show all TCP connections",
    NULL,
};
// 在初始化代码中安装
install_menu(my_debug_menu);

tkstats 命令（如文档示例）是 监控系统健康度的关键 。它显示每个任务的栈使用“水位线”。 used 列显示了从栈底开始未被“守卫字”覆盖的深度，这代表了该任务历史最大栈使用量。你需要确保 (stack - used) 的值留有足够的余量（例如20%），以应对未预料到的调用深度或中断嵌套。

5.2 网络问题排查与抓包分析

当设备网络不通时，系统化的排查至关重要：

  1. 物理层与链路层 ：首先确认PHY的链路状态指示灯是否正常。通过菜单命令读取PHY的链路状态寄存器。确保MAC地址设置正确且唯一。
  2. ARP层 ：尝试Ping同一网段内的另一个设备，并在主机上使用 arp -a 查看是否学习到了设备的ARP条目。如果没有，问题可能出在ARP请求/应答上。可以在协议栈中开启ARP调试信息输出。
  3. IP与传输层 ：如果ARP通了但Ping不通，检查IP地址、子网掩码、网关设置是否正确。使用 NET_STATS 宏编译，通过菜单命令打印IP、ICMP的统计信息，查看收发包计数。
  4. 应用层 ：对于TCP服务，使用PC端的Telnet或网络调试助手尝试连接。在设备端，确保套接字正确创建、绑定和监听。 最有效的终极手段是使用以太网抓包工具（如Wireshark） 。在交换机上做端口镜像，或者直接将设备与PC直连抓包。通过分析抓到的数据包，你可以清晰地看到DHCP交互过程、TCP三次握手是否完成、HTTP请求是否发出/响应是否返回，从而精准定位问题在哪一层。

5.3 内存优化与性能权衡实战

对于资源极其紧张的设备，以下优化策略非常有效：

  1. 缓冲区池调优 ：在 pktalloc.c 中，减少 NUM_BIG_BUFS 和 NUM_SMALL_BUFS 的数量，直到系统在最大负载下刚好不丢包。同时，可以尝试减小 bigbufsiz ，如果确认你的应用只会收发小包（例如只发UDP心跳包），可以将其设置为MTU（1500字节）而非默认的最大帧长。
  2. 禁用非必需功能 ：再次审视 ipport.h 。 IN_MENUS （菜单系统）、 NET_STATS 在量产时都可以关闭。如果不需要文件传输，关闭 TFTP_CLIENT 和 TFTP_SERVER 。
  3. 任务栈空间精细化分配 ：在 osport.h 中，为不同任务分配合适的栈空间。一个只点LED灯的任务可能只需要512字节，而处理复杂HTTP请求的任务可能需要2KB甚至更多。通过 tkstats 命令反复测试调整。
  4. 超级循环模式的极致优化 ：如果应用逻辑简单且确定，果断使用超级循环模式。你可以将协议栈的 packet_check() 和 inet_timer() 调用频率提高，并精心设计所有任务函数的状态机，确保每次调用都在极短时间内返回。这能省下RTOS本身和多个任务栈的开销，通常能节省数KB的RAM。

5.4 常见问题速查表

问题现象 可能原因 排查步骤与解决方案
设备完全无网络通信 1. PHY未初始化或链路未建立。
2. FEC驱动未正确初始化，DMA描述符未设置。
3. MAC地址全零或冲突。		 1. 检查PHY状态寄存器，确认链路已建立（Link Up）。
2. 检查FEC控制寄存器，确认收发使能。使用调试器查看RxBD的“空”标志是否被硬件置位。
3. 确认 mac_addr_fec 数组已设置为唯一且有效的MAC地址。
能Ping通但TCP连接失败 1. 应用未创建监听套接字或绑定失败。
2. 防火墙或路由器规则阻挡。
3. 协议栈的TCP资源（如监听队列）耗尽。		 1. 检查服务器任务是否运行， socket() , bind() , listen() 调用是否返回成功。
2. 尝试在局域网内直连测试，排除网络设备问题。
3. 检查协议栈配置，确保支持的套接字数量足够。
设备运行一段时间后死机 1. 栈溢出。
2. 堆内存耗尽（内存泄漏）。
3. 中断冲突或未正确处理。		 1. 使用 tkstats 监控栈使用量，增大溢出任务的栈空间。
2. 启用 MEM_BLOCKS 宏，定期打印堆内存状态，检查 pk_alloc 的缓冲区是否被正确释放。
3. 检查中断向量表配置，确保FEC中断、定时器中断等被正确安装和处理。
DHCP始终获取不到IP 1. netstatic 数组初始IP非零。
2. 网络中没有DHCP服务器。
3. DHCP请求/响应包被过滤。		 1. 确保在调用 dhc_setup() 前，将 netstatic[0].n_ipaddr 等字段清零。
2. 使用抓包工具确认设备是否发出了DHCP Discover广播包，以及服务器是否回复了Offer。
3. 检查交换机或路由器是否禁止了DHCP广播。
串口菜单无响应 1. 串口驱动（ iuart.c ）波特率配置错误。
2. 任务调度异常，菜单任务未被执行。
3. 串口RX缓冲区溢出。		 1. 核对 UART0_SPEED 定义与终端软件设置。
2. 在超级循环模式下，确认 kbdio() 函数被定期调用；在RTOS模式下，确认菜单任务已创建且状态为就绪。
3. 增大 UART_RXBUFSIZE 。

回顾整个项目，将这样一个轻量级TCP/IP协议栈与RTOS集成到ColdFire平台，是一个典型的“麻雀虽小，五脏俱全”的嵌入式网络工程。它的价值不在于功能的繁多，而在于在严苛的资源限制下，通过深度的软硬件协同设计与精准的裁剪，实现了稳定可靠的网络通信。今天，虽然有了更多功能丰富、社区活跃的嵌入式网络栈（如lwIP、PicoTCP），但理解这种底层集成原理，能让你在面对任何平台、任何协议栈时，都具备从芯片手册、驱动代码到应用逻辑的完整调试和优化能力。这种能力，是区分一个嵌入式软件工程师是否真正理解“系统”的关键。最后一个小建议：如果你正在基于此类老式代码进行维护或开发，务必建立清晰的版本管理，并对所有关键的配置宏和缓冲区大小做好详细的文档注释，因为它们的调整往往牵一发而动全身。

Logo
AI硬件创业社区

智能硬件社区聚焦AI智能硬件技术生态，汇聚嵌入式AI、物联网硬件开发者，打造交流分享平台，同步全国赛事资讯、开展 OPC 核心人才招募，助力技术落地与开发者成长。

更多推荐

cover

kubernetes（K8s）学习笔记（第四期）：Pod 管理

avatar AI硬件创业社区
cover

kubernetes（K8s）学习笔记（第三期）：集群基础管理

avatar AI硬件创业社区

STM32CubeMX 里 SYS → Debug 选项含义

标准 4 线 JTAG 调试，占用 4 个专用引脚： PA13 (SWDIO)/PA14 (SWCLK)/PA15 (JTMS)/PB3 (JTDO)5 线 JTAG，多一根复位脚 PB4 (JTRST)，占用 IO 更多，极少使用。低功耗唤醒功能，勾选后启用调试唤醒，一般开发阶段不用勾选。这是最常用、推荐的调试模式，只占用。两线调试，日常开发首选，上面已说明。这个是 HAL 库系统滴答。

avatar AI硬件创业社区