尧图网页设计 
RIOT 中 Mulle 板的 OpenOCD 调试配置指南从 FTDI 编程器到 GDB 服务器【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOT本文面向 RIOT 操作系统GitHub_Trending/riot/RIOT中 Eistec Mulle 物联网开发板的开发与调试场景。Mulle 板通过自带的 FTDI FT2232H 编程器实现 USB UART 与 JTAG 一体化调试本文将完整解析仓库中 boards/mulle/dist/openocd/README.md 所记录的使用方法并深入其背后的 OpenOCD 配置文件、RIOT 构建系统集成与openocd.sh工作流。读完本文你将掌握 Mulle 板从搭建 OpenOCD 环境、启动 GDB 服务器到执行make flash、make debug的完整实战技能。Mulle 板与 OpenOCD 调试背景Mulle 是 Eistec 推出的一款微型无线嵌入式物联网开发板主控为 NXP Kinetis K60 系列MK60DN512VLL10Cortex-M464 KiB RAM、512 KiB Flash板载 AT86RF212B sub-GHz IEEE 802.15.4 收发器、2 MiB 外部 NOR Flash、512 B 外部 F-RAM 与 LIS3DH 加速度计具体板级信息可参考 boards/mulle/doc.md。Mulle 调试链路的关键在于其专用编程板Mulle programmer board该编程板使用一颗 FTDI FT2232H 芯片将USB 转 UART 与 JTAG 功能合二为一——既充当串口终端又充当 JTAG 调试适配器。因此在 RIOT 中调试 Mulle 板的标准工具链是 OpenOCD仓库中的配置文件正是为这套硬件调试链路准备的。环境准备OpenOCD 版本与编译要求按照 boards/mulle/dist/openocd/README.md 的说明本目录下的 OpenOCD 配置已使用OpenOCD v0.7.0验证通过。由于 Mulle 编程板使用FTDI 芯片作为调试接口interface 为 ftdiOpenOCD 必须以如下方式构建./configure --enable-ftdi make即在配置阶段显式启用ftdi驱动。若使用发行版包管理器安装的 OpenOCD需确认其确实包含了 ftdi 支持例如openocd --version输出中应能看到 FTDI 相关驱动信息。注意ftdi驱动基于 libusb 与 libftdi运行时通常还需要 udev 规则授权普通用户访问 USB 设备否则可能出现权限不足导致无法打开 FTDI 设备。启动 OpenOCD GDB 服务器环境就绪后进入配置目录并启动 OpenOCD GDB 服务器openocd -f mulle.cfg这正是原文档给出的核心命令。其中mulle.cfg为适配器adapter配置文件对应本目录中的 mulle-programmer-0.70.cfg 与 mulle-programmer-0.60.cfg旧版 OpenOCD 语法。命令成功执行后OpenOCD 默认会在本机3333端口开启 GDB 服务随后即可用arm-none-eabi-gdb连接调试。深入解析 Mulle 编程器配置文件本目录下的.cfg文件是整套调试流程的灵魂。以 v0.70 版本为例逐行拆解其含义Mulle Programmer v0.70 配置adapter speed 1000 adapter driver ftdi ftdi device_desc Mulle Programmer v0.70 ftdi vid_pid 0x0403 0x6010 ftdi channel 1 ftdi layout_init 0x0008 0x005b ftdi layout_signal nTRST -data 0x0010 ftdi layout_signal nSRST -data 0x0040 reset_config srst_push_pull srst_gates_jtagadapter speed 1000JTAG 时钟频率设为 1000 kHz。配置注释明确提示如果遇到与 Mulle 板连接丢失的问题可降低该值以获得更稳定的时序。adapter driver ftdi选用 ftdi 适配器驱动对应前文--enable-ftdi的编译要求。ftdi device_desc Mulle Programmer v0.70按 USB 设备描述字符串匹配 Mulle 编程器避免误连其他 FTDI 设备。ftdi vid_pid 0x0403 0x6010FTDI 芯片的标准 Vendor/Product ID——0x0403是 FTDI 的 USB Vendor ID0x6010是 FT2232H 双通道芯片的 Product ID。ftdi channel 1使用 FT2232H 的通道 Bchannel 1承载 JTAG 信号通道 A 通常留给 UART对应make term使用的串口。ftdi layout_init 0x0008 0x005b初始化 FTDI 引脚的输出值value与方向direction掩码。0x0008为初始输出电平0x005b为方向位掩码二者共同决定哪些引脚作为 JTAG 输出。ftdi layout_signal nTRST -data 0x0010/ftdi layout_signal nSRST -data 0x0040将 FTDI 的 GPIO 位 40x0010与位 60x0040分别映射为 JTAG 的nTRST与nSRST复位信号。-data表示低电平有效——注释说明自 v0.70 起编程板上的复位信号为低有效v0.60 曾为高有效。reset_config srst_push_pull srst_gates_jtag从 OpenOCD 视角看复位信号是推挽输出但硬件设计上实际为开漏srst_gates_jtag表明 SRST 生效时会门控封锁JTAG 链路即复位期间无法访问 JTAG。v0.60 与 v0.70 的关键差异对比 mulle-programmer-0.60.cfg 可以看出两个版本仅在两处不同配置项v0.60v0.70ftdi device_descMulle Programmer v0.60Mulle Programmer v0.70nTRST/nSRST极性-ndata高有效-data低有效v0.60 注释明确说明Mulle 编程板会在 FTDI 芯片与 MCU 之间反转复位信号因此必须使用-ndata告诉 OpenOCD 这些信号是高有效的而 v0.70 起硬件改为低有效配置相应切换为-data。这是两个版本配置文件在语法上最重要的区别混用会导致复位失败或 JTAG 时序异常。RIOT 构建系统如何选择 Mulle OpenOCD 配置在 RIOT 中Mulle 板默认的烧录/调试工具就是 OpenOCD。查看 boards/mulle/Makefile.includePROGRAMMER ? openocd PROGRAMMERS_SUPPORTED openocd OPENOCD_TRANSPORT : jtag OPENOCD_DEBUG_ADAPTER ? mullePROGRAMMER ? openocd将烧录器默认为 OpenOCD因此直接make flash/make debug即可调用 OpenOCD。OPENOCD_TRANSPORT : jtagMulle 板通过 JTAG 而非 SWD 访问makefiles/tools/openocd-adapters/mulle.inc.mk 中默认值为 swd但板级 Makefile 覆盖为 jtag。OPENOCD_DEBUG_ADAPTER ? mulle指定使用 Mulle 编程器作为调试适配器。适配器的具体初始化由 makefiles/tools/openocd-adapters/mulle.inc.mk 完成其中有一个非常巧妙的设计——根据编程器序列号自动选择配置文件版本DEBUG_ADAPTER_ID ? $(PROGRAMMER_SERIAL) ifneq (,$(DEBUG_ADAPTER_ID)) # 序列号 100 -- 148 对应 v0.60 # 序列号 301 -- 330 对应 v0.70 ... PROGRAMMER_VERSION 0.60 / 0.70 endif PROGRAMMER_VERSION ? 0.70 OPENOCD_ADAPTER_INIT ? -f $(RIOTBASE)/boards/mulle/dist/openocd/mulle-programmer-$(PROGRAMMER_VERSION).cfg也就是说编译时可通过PROGRAMMER_SERIAL或兼容的DEBUG_ADAPTER_ID指定编程器序列号构建系统会自动判断硬件版本100–148为 v0.60301–330为 v0.70其余默认按 v0.70 处理从而加载对应的.cfg文件。这正是本文所解析的 mulle-programmer-0.60.cfg / mulle-programmer-0.70.cfg 被集成到 RIOT 构建流程的入口。此外makefiles/tools/openocd.inc.mk 会在指定了DEBUG_ADAPTER_ID时追加-c adapter serial id命令实现多编程器环境下按序列号精准匹配设备。板级目标配置openocd.cfg除了适配器配置Mulle 板还提供了板级目标配置 boards/mulle/dist/openocd.cfgsource [find target/kx.cfg] reset_config srst_onlysource [find target/kx.cfg]加载 OpenOCD 自带的Kinetis K 系列K60目标定义包含内核寄存器、Flash 控制器等描述。reset_config srst_only默认只使用 SRST 复位。注释补充说明只有在 MCU 已将 TRST 引脚K60 的 PTA5通过引脚复用正确配置为 TRST 功能时才可将此改为trst_and_srst以启用 TRST。根据 makefiles/tools/openocd.inc.mk 的规则OpenOCD 配置的查找顺序为优先使用BOARDDIR/dist/openocd.cfg即此处文件找不到再回退到公共 STM32 配置。Mulle 板正是命中第一种情况因此适配器配置-f mulle-programmer-*.cfg与板级目标配置-f openocd.cfg会同时传给 OpenOCD前者初始化调试适配器后者定义目标芯片。烧录、调试与复位openocd.sh 工作流所有 OpenOCD 操作最终统一由 RIOT 的工具脚本 dist/tools/openocd/openocd.sh 驱动。该脚本支持flash、debug、debug-client、debug-server、flashr、debugr、reset、term-rtt等动作并与本文的配置配合形成完整闭环make flash # 擦写并烧录烧录后自动 verify_image 校验 make flash-only # 仅烧录 make flashr # 加载到 RAM 运行不写 Flash make debug # 后台启动 OpenOCD GDB 服务器再拉起 arm-none-eabi-gdb make debug-server # 仅启动 GDB 服务器供 IDE 连接 make debug-client # 连接已运行的 GDB 服务器 make reset # 通过 SRST 复位目标板以flash为例openocd.sh 实际执行的关键命令序列为init→targets→reset halt→flash write_image erase image→verify_image→reset run→shutdown期间还会调用OPENOCD_PRE_FLASH_CHECK_SCRIPT等扩展钩子。debug动作则通过gdb_port 3333默认暴露 GDB 服务并以halt作为调试会话的起始目标状态默认OPENOCD_DBG_START_CMD见 openocd.sh。值得特别注意的是 Mulle 板的两个定制点见 boards/mulle/Makefile.includeOPENOCD_PRE_VERIFY_CMDS烧录后会先load_image一个预编译的wdog-disable.bin到0x20000000并resume临时禁用看门狗再由 MCU 自行计算固件校验和以加速 Flash 校验。OPENOCD_PRE_FLASH_CHECK_SCRIPT烧录前调用$(RIOTCPU)/$(CPU)/dist/check-fcfield.sh检查镜像的 Flash 配置字段flash configuration field完整性避免写出无效的启动配置。另外该 Makefile 还定义了PORT_LINUX ? /dev/ttyUSB0与TTY_BOARD_FILTER : --model Mulle Programmer --iface-num 0说明串口终端make term也会通过--model关键字在系统 USB 设备中过滤出 Mulle 编程器与 JTAG 通道共用同一颗 FT2232H。常见问题与排错建议连接丢失 / 时序不稳定降低adapter speed默认 1000可试 500 或更低这是配置文件注释中给出的直接建议。找不到 FTDI 设备检查ftdi device_desc与ftdi vid_pid是否与系统识别到的设备一致可用lsusb核对 VID/PID0x0403:0x6010并确认 OpenOCD 以--enable-ftdi编译。复位失败核对编程板硬件版本对应的极性配置——v0.60 用-ndata高有效v0.70 用-data低有效也可以在编译时通过PROGRAMMER_SERIAL指定序列号让构建系统自动选择。TRST 不可用目标配置默认srst_only如需 TRST 必须在 K60 上先配置好 PTA5 的引脚复用再改为trst_and_srst。小结围绕 boards/mulle/dist/openocd/README.md 这份简短而关键的文档本文还原了 Mulle 板在 RIOT 中的完整 OpenOCD 调试链路基于 FTDI FT2232H 的编程器硬件、--enable-ftdi的 OpenOCD 构建要求、openocd -f mulle.cfg的 GDB 服务器启动方式以及 mulle-programmer-0.60.cfg 与 mulle-programmer-0.70.cfg 两个版本配置的逐项差异。同时结合 boards/mulle/Makefile.include、makefiles/tools/openocd-adapters/mulle.inc.mk 与 dist/tools/openocd/openocd.sh解释了序列号自动选型、看门狗旁路校验、Flash 配置字段预检等 RIOT 工程化细节让你不仅能跑起来更能理解其背后的原理遇到问题时可有的放矢地排查。【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RIOT 中 Mulle 板的 OpenOCD 调试配置指南：从 FTDI 编程器到 GDB 服务器
RIOT 中 Mulle 板的 OpenOCD 调试配置指南从 FTDI 编程器到 GDB 服务器【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOT本文面向 RIOT 操作系统GitHub_Trending/riot/RIOT中 Eistec Mulle 物联网开发板的开发与调试场景。Mulle 板通过自带的 FTDI FT2232H 编程器实现 USB UART 与 JTAG 一体化调试本文将完整解析仓库中 boards/mulle/dist/openocd/README.md 所记录的使用方法并深入其背后的 OpenOCD 配置文件、RIOT 构建系统集成与openocd.sh工作流。读完本文你将掌握 Mulle 板从搭建 OpenOCD 环境、启动 GDB 服务器到执行make flash、make debug的完整实战技能。Mulle 板与 OpenOCD 调试背景Mulle 是 Eistec 推出的一款微型无线嵌入式物联网开发板主控为 NXP Kinetis K60 系列MK60DN512VLL10Cortex-M464 KiB RAM、512 KiB Flash板载 AT86RF212B sub-GHz IEEE 802.15.4 收发器、2 MiB 外部 NOR Flash、512 B 外部 F-RAM 与 LIS3DH 加速度计具体板级信息可参考 boards/mulle/doc.md。Mulle 调试链路的关键在于其专用编程板Mulle programmer board该编程板使用一颗 FTDI FT2232H 芯片将USB 转 UART 与 JTAG 功能合二为一——既充当串口终端又充当 JTAG 调试适配器。因此在 RIOT 中调试 Mulle 板的标准工具链是 OpenOCD仓库中的配置文件正是为这套硬件调试链路准备的。环境准备OpenOCD 版本与编译要求按照 boards/mulle/dist/openocd/README.md 的说明本目录下的 OpenOCD 配置已使用OpenOCD v0.7.0验证通过。由于 Mulle 编程板使用FTDI 芯片作为调试接口interface 为 ftdiOpenOCD 必须以如下方式构建./configure --enable-ftdi make即在配置阶段显式启用ftdi驱动。若使用发行版包管理器安装的 OpenOCD需确认其确实包含了 ftdi 支持例如openocd --version输出中应能看到 FTDI 相关驱动信息。注意ftdi驱动基于 libusb 与 libftdi运行时通常还需要 udev 规则授权普通用户访问 USB 设备否则可能出现权限不足导致无法打开 FTDI 设备。启动 OpenOCD GDB 服务器环境就绪后进入配置目录并启动 OpenOCD GDB 服务器openocd -f mulle.cfg这正是原文档给出的核心命令。其中mulle.cfg为适配器adapter配置文件对应本目录中的 mulle-programmer-0.70.cfg 与 mulle-programmer-0.60.cfg旧版 OpenOCD 语法。命令成功执行后OpenOCD 默认会在本机3333端口开启 GDB 服务随后即可用arm-none-eabi-gdb连接调试。深入解析 Mulle 编程器配置文件本目录下的.cfg文件是整套调试流程的灵魂。以 v0.70 版本为例逐行拆解其含义Mulle Programmer v0.70 配置adapter speed 1000 adapter driver ftdi ftdi device_desc Mulle Programmer v0.70 ftdi vid_pid 0x0403 0x6010 ftdi channel 1 ftdi layout_init 0x0008 0x005b ftdi layout_signal nTRST -data 0x0010 ftdi layout_signal nSRST -data 0x0040 reset_config srst_push_pull srst_gates_jtagadapter speed 1000JTAG 时钟频率设为 1000 kHz。配置注释明确提示如果遇到与 Mulle 板连接丢失的问题可降低该值以获得更稳定的时序。adapter driver ftdi选用 ftdi 适配器驱动对应前文--enable-ftdi的编译要求。ftdi device_desc Mulle Programmer v0.70按 USB 设备描述字符串匹配 Mulle 编程器避免误连其他 FTDI 设备。ftdi vid_pid 0x0403 0x6010FTDI 芯片的标准 Vendor/Product ID——0x0403是 FTDI 的 USB Vendor ID0x6010是 FT2232H 双通道芯片的 Product ID。ftdi channel 1使用 FT2232H 的通道 Bchannel 1承载 JTAG 信号通道 A 通常留给 UART对应make term使用的串口。ftdi layout_init 0x0008 0x005b初始化 FTDI 引脚的输出值value与方向direction掩码。0x0008为初始输出电平0x005b为方向位掩码二者共同决定哪些引脚作为 JTAG 输出。ftdi layout_signal nTRST -data 0x0010/ftdi layout_signal nSRST -data 0x0040将 FTDI 的 GPIO 位 40x0010与位 60x0040分别映射为 JTAG 的nTRST与nSRST复位信号。-data表示低电平有效——注释说明自 v0.70 起编程板上的复位信号为低有效v0.60 曾为高有效。reset_config srst_push_pull srst_gates_jtag从 OpenOCD 视角看复位信号是推挽输出但硬件设计上实际为开漏srst_gates_jtag表明 SRST 生效时会门控封锁JTAG 链路即复位期间无法访问 JTAG。v0.60 与 v0.70 的关键差异对比 mulle-programmer-0.60.cfg 可以看出两个版本仅在两处不同配置项v0.60v0.70ftdi device_descMulle Programmer v0.60Mulle Programmer v0.70nTRST/nSRST极性-ndata高有效-data低有效v0.60 注释明确说明Mulle 编程板会在 FTDI 芯片与 MCU 之间反转复位信号因此必须使用-ndata告诉 OpenOCD 这些信号是高有效的而 v0.70 起硬件改为低有效配置相应切换为-data。这是两个版本配置文件在语法上最重要的区别混用会导致复位失败或 JTAG 时序异常。RIOT 构建系统如何选择 Mulle OpenOCD 配置在 RIOT 中Mulle 板默认的烧录/调试工具就是 OpenOCD。查看 boards/mulle/Makefile.includePROGRAMMER ? openocd PROGRAMMERS_SUPPORTED openocd OPENOCD_TRANSPORT : jtag OPENOCD_DEBUG_ADAPTER ? mullePROGRAMMER ? openocd将烧录器默认为 OpenOCD因此直接make flash/make debug即可调用 OpenOCD。OPENOCD_TRANSPORT : jtagMulle 板通过 JTAG 而非 SWD 访问makefiles/tools/openocd-adapters/mulle.inc.mk 中默认值为 swd但板级 Makefile 覆盖为 jtag。OPENOCD_DEBUG_ADAPTER ? mulle指定使用 Mulle 编程器作为调试适配器。适配器的具体初始化由 makefiles/tools/openocd-adapters/mulle.inc.mk 完成其中有一个非常巧妙的设计——根据编程器序列号自动选择配置文件版本DEBUG_ADAPTER_ID ? $(PROGRAMMER_SERIAL) ifneq (,$(DEBUG_ADAPTER_ID)) # 序列号 100 -- 148 对应 v0.60 # 序列号 301 -- 330 对应 v0.70 ... PROGRAMMER_VERSION 0.60 / 0.70 endif PROGRAMMER_VERSION ? 0.70 OPENOCD_ADAPTER_INIT ? -f $(RIOTBASE)/boards/mulle/dist/openocd/mulle-programmer-$(PROGRAMMER_VERSION).cfg也就是说编译时可通过PROGRAMMER_SERIAL或兼容的DEBUG_ADAPTER_ID指定编程器序列号构建系统会自动判断硬件版本100–148为 v0.60301–330为 v0.70其余默认按 v0.70 处理从而加载对应的.cfg文件。这正是本文所解析的 mulle-programmer-0.60.cfg / mulle-programmer-0.70.cfg 被集成到 RIOT 构建流程的入口。此外makefiles/tools/openocd.inc.mk 会在指定了DEBUG_ADAPTER_ID时追加-c adapter serial id命令实现多编程器环境下按序列号精准匹配设备。板级目标配置openocd.cfg除了适配器配置Mulle 板还提供了板级目标配置 boards/mulle/dist/openocd.cfgsource [find target/kx.cfg] reset_config srst_onlysource [find target/kx.cfg]加载 OpenOCD 自带的Kinetis K 系列K60目标定义包含内核寄存器、Flash 控制器等描述。reset_config srst_only默认只使用 SRST 复位。注释补充说明只有在 MCU 已将 TRST 引脚K60 的 PTA5通过引脚复用正确配置为 TRST 功能时才可将此改为trst_and_srst以启用 TRST。根据 makefiles/tools/openocd.inc.mk 的规则OpenOCD 配置的查找顺序为优先使用BOARDDIR/dist/openocd.cfg即此处文件找不到再回退到公共 STM32 配置。Mulle 板正是命中第一种情况因此适配器配置-f mulle-programmer-*.cfg与板级目标配置-f openocd.cfg会同时传给 OpenOCD前者初始化调试适配器后者定义目标芯片。烧录、调试与复位openocd.sh 工作流所有 OpenOCD 操作最终统一由 RIOT 的工具脚本 dist/tools/openocd/openocd.sh 驱动。该脚本支持flash、debug、debug-client、debug-server、flashr、debugr、reset、term-rtt等动作并与本文的配置配合形成完整闭环make flash # 擦写并烧录烧录后自动 verify_image 校验 make flash-only # 仅烧录 make flashr # 加载到 RAM 运行不写 Flash make debug # 后台启动 OpenOCD GDB 服务器再拉起 arm-none-eabi-gdb make debug-server # 仅启动 GDB 服务器供 IDE 连接 make debug-client # 连接已运行的 GDB 服务器 make reset # 通过 SRST 复位目标板以flash为例openocd.sh 实际执行的关键命令序列为init→targets→reset halt→flash write_image erase image→verify_image→reset run→shutdown期间还会调用OPENOCD_PRE_FLASH_CHECK_SCRIPT等扩展钩子。debug动作则通过gdb_port 3333默认暴露 GDB 服务并以halt作为调试会话的起始目标状态默认OPENOCD_DBG_START_CMD见 openocd.sh。值得特别注意的是 Mulle 板的两个定制点见 boards/mulle/Makefile.includeOPENOCD_PRE_VERIFY_CMDS烧录后会先load_image一个预编译的wdog-disable.bin到0x20000000并resume临时禁用看门狗再由 MCU 自行计算固件校验和以加速 Flash 校验。OPENOCD_PRE_FLASH_CHECK_SCRIPT烧录前调用$(RIOTCPU)/$(CPU)/dist/check-fcfield.sh检查镜像的 Flash 配置字段flash configuration field完整性避免写出无效的启动配置。另外该 Makefile 还定义了PORT_LINUX ? /dev/ttyUSB0与TTY_BOARD_FILTER : --model Mulle Programmer --iface-num 0说明串口终端make term也会通过--model关键字在系统 USB 设备中过滤出 Mulle 编程器与 JTAG 通道共用同一颗 FT2232H。常见问题与排错建议连接丢失 / 时序不稳定降低adapter speed默认 1000可试 500 或更低这是配置文件注释中给出的直接建议。找不到 FTDI 设备检查ftdi device_desc与ftdi vid_pid是否与系统识别到的设备一致可用lsusb核对 VID/PID0x0403:0x6010并确认 OpenOCD 以--enable-ftdi编译。复位失败核对编程板硬件版本对应的极性配置——v0.60 用-ndata高有效v0.70 用-data低有效也可以在编译时通过PROGRAMMER_SERIAL指定序列号让构建系统自动选择。TRST 不可用目标配置默认srst_only如需 TRST 必须在 K60 上先配置好 PTA5 的引脚复用再改为trst_and_srst。小结围绕 boards/mulle/dist/openocd/README.md 这份简短而关键的文档本文还原了 Mulle 板在 RIOT 中的完整 OpenOCD 调试链路基于 FTDI FT2232H 的编程器硬件、--enable-ftdi的 OpenOCD 构建要求、openocd -f mulle.cfg的 GDB 服务器启动方式以及 mulle-programmer-0.60.cfg 与 mulle-programmer-0.70.cfg 两个版本配置的逐项差异。同时结合 boards/mulle/Makefile.include、makefiles/tools/openocd-adapters/mulle.inc.mk 与 dist/tools/openocd/openocd.sh解释了序列号自动选型、看门狗旁路校验、Flash 配置字段预检等 RIOT 工程化细节让你不仅能跑起来更能理解其背后的原理遇到问题时可有的放矢地排查。【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考