简介基于STM32F103与W5500以太网模块的物联网实战工程面向物联网开发者、嵌入式爱好者及项目实践者解决设备通过RJ45有线网络接入OneNet物联网平台、实现单路状态上报与远程控制的问题。工程采用SPI接口连接STM32与W5500以W5500作为TCP客户端、OneNet作为服务端完整演示DHCP动态获取IP、连接服务器、TCP数据交互及断开连接等网络通信流程。代码基于KEIL开发在STM32F103C8T6上验证同系列其他型号可通过调整芯片型号与Flash容量快速适配并需注意J-Link/S-Link调试器选择。资源包共195个文件大小约6.46MB包含C语言源码(.c/.h)、KEIL工程配置(.uvprojx/.uvoptx)、编译中间文件(.o/.d/.crf)以及生成的可执行文件(.hex/.axf/.map)便于直接编译或分析固件。截至目前已有1034人学习下载适用于具备一定STM32基础、希望快速上手以太网与云平台联调的学习者参考价值较高。1. 不跑协议栈的 STM32W5500怎么把单路状态送进 OneNet 物联网平台一块 STM32F103C8T6、一个 W5500 模块、一根网线就能把现场的单路开关状态送进 OneNet 物联网平台同时还能接收平台下发的控制指令。整套工程里没有 Linux 也没有 RTOSW5500 用硬件拆解了 TCP/IP 协议栈MCU 只通过 SPI 读写寄存器因此不占 Flash 也不依赖烦人的协议移植。对于刚接触 OneNet 云平台接入的开发者来说这是最直接的以太网落地路径。这篇把 DHCP 动态取址、TCP 客户端连接、数据帧构造、远程控制解析的完整链路拆开讲中途会给出可照抄的代码片段和排错命令适合正在做物联网项目实战又不想一上来就换带网络操作系统的 MCU 的人。2. W5500 硬件协议栈与 STM32F103 的 SPI 接线和寄存器读写2.1 选型边界为什么是 W5500 而不是 ENC28J60 或 CH395很多 STM32 以太网项目第一反应会选 ENC28J60理由是便宜。但 ENC28J60 只负责 MACPHYTCP/IP 协议栈必须在 MCU 侧跑 uIP 或 lwIP这类协议栈对内存余量和代码稳定性要求都不低。在 STM32F103C8T6 只有 20KB RAM 的规格下跑一个完整 TCP 客户端还要同时处理复位重连容易在粘包和超时上翻车。W5500 则把 TCP/IP、UDP、ICMPv6、DHCP 等协议全部做进芯片内部MCU 只需要构造以太网帧以上的数据硬件会自动完成三次握手和校验。八个独立 Socket 对单路状态控制这类场景绰绰有余。CH395 同样是硬件协议栈方案但 W5500 的资料、例程和第三方生态更全。尤其在做 OneNet 接入时网上能搜到的 STM32 驱动、ioLibrary、乒乓缓存设计基本都是围绕 W5500 展开的。所以这个工程选 W5500不是因为它比 CH395 快而是因为在“单片机 以太网 物联网平台”这个组合里它的调试成本和移植阻力最小。接口上 W5500 最高支持 80MHz SPI 时钟模块自身 3.3V 供电通过 RJ45 座内置的网络变压器隔离信号物理层几乎不需要额外电路。缺点是模块价格略高于 ENC28J60但对项目实际开发来说省下的协议栈调试时间远比这几十元差价值钱。2.2 原理图关键点SPI1、复位和中断引脚分配常见的 W5500 模块原理图会在芯片旁边放一枚 25MHz 晶振、一组去耦电容和一个网口带变压器电源部分需要干净。STM32F103 这边只需要提供 SPI 主模式、片选、复位、中断四类信号。下面是我一般会使用的接线表基于原子/正点等常见 W5500 模块与 STM32F103C8T6 的映射关系W5500 信号STM32F103 引脚功能说明SCLKPA5SPI1 时钟模式 0 或 3 均可MISOPA6SPI1 主入从出MOSIPA7SPI1 主出从入SCSPA4片选低有效RSTPA3硬件复位低脉冲有效INTPA2中断输出通知 MCU 有事件需要处理VCC3.3V模块供电并联 100nF 和 10uF 去耦GNDGND公共地SCS 建议接 GPIO 推挽输出不要直接硬上拉因为 W5500 的 SPI 帧需要动态拉低才能操作寄存器。RST 引脚在做软件复位时也很有用当 DHCP 长时间拿不到 IP或连接进入异常状态时拉低 RST 再拉高比逐一清寄存器省事。INT 引脚在中断模式下可以高效判断数据到达但如果主循环足够快也可以不用 INT。实际项目中我已经不只一次遇到因为没把 INT 接上导致 W5500 接收缓冲区溢出而不自知的情况建议保留它。2.3 SPI 帧格式与寄存器访问封装W5500 的寄存器映射分成 Common 区、Socket 区和 TX/RX 缓冲三大块。SPI 帧由 16 位地址、8 位控制字段和数据组成控制字段里包含块选择、读/写标志。手工操作寄存器的位运算比较繁琐而且不同 ioLibrary 版本对控制字段的定义不完全一致所以我一般不会在应用层直接拼 SPI 帧而是用 WIZnet 提供的 ioLibrary 并只实现底层 SPI 回调。以下是在 STM32 HAL 库下的适配代码/* w5500_spi.c */ static void W5500_CS_Enable(void) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_RESET); } static void W5500_CS_Disable(void) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET); } static uint8_t W5500_SPI_ReadByte(void) { uint8_t data 0; HAL_SPI_Receive(hspi1, data, 1, 10); return data; } static void W5500_SPI_WriteByte(uint8_t data) { HAL_SPI_Transmit(hspi1, data, 1, 10); } void W5500_Init(void) { reg_wizchip_cs_cbfunc(W5500_CS_Enable, W5500_CS_Disable); reg_wizchip_spi_cbfunc(W5500_SPI_ReadByte, W5500_SPI_WriteByte); wizchip_init(NULL, NULL); }这里reg_wizchip_cs_cbfunc和reg_wizchip_spi_cbfunc是 ioLibrary 的回调注册函数分别绑定片选动作和 SPI 字节收发。wizchip_init(NULL, NULL)会初始化芯片内部 TX/RX 缓冲并把 8 个 Socket 全部关闭。第一次初始化后可以读 W5500 版本寄存器如果返回 0x54 就说明 SPI 链路正常。如果返回 0xFF 或 0x00优先检查 MISO/MOSI 是否接反其次检查 CS 极性。关于控制字节的细节ioLibrary 已经帮你算好不必再在应用层关心。但有一个要注意的点W5500 的 SPI 时钟模式支持模式 0 和模式 3两者对 CPOL/CPHA 的要求不同。很多模块默认是模式 0如果你在 CubeMX 里配置成模式 3 也能通信但要注意是“能通信”而不是“稳定通信”。我会把 SPI1 的时钟频率压到 18MHz 以内太高的速率在杜邦线下容易出现偶发丢字节调试时建议先用 1MHz 跑通再逐步提高频率。3. DHCP 动态取址到 OneNet TCP 连接代码里的时序细节3.1 DHCP 客户端如何嵌进主循环且不卡死W5500 的 DHCP 功能是在芯片内部跑的但 MCU 侧必须持续调用DHCP_run()处理接收到的 DHCP Offer 和 ACK。不能像普通库函数一样一次性等结果因为 DHCP 是一个需要时间片轮转的状态机。最简单可靠的做法是把它放进 1ms 定时中断或主循环中定期调用以下是我常用的一段调度逻辑/* dhcp_task.c */ #define DHCP_TIMEOUT_MS 10000 uint8_t dhcp_status DHCP_RUNNING; uint32_t dhcp_start_tick; uint32_t dhcp_last_tick; void dhcp_tick_task(void) { if (HAL_GetTick() - dhcp_last_tick 1) { dhcp_tick(); /* 驱动 ioLibrary 的 DHCP 定时器 */ dhcp_last_tick HAL_GetTick(); } dhcp_status DHCP_run(); } void dhcp_start(void) { dhcp_start_tick HAL_GetTick(); dhcp_status DHCP_RUNNING; while (dhcp_status DHCP_RUNNING) { dhcp_tick_task(); if (HAL_GetTick() - dhcp_start_tick DHCP_TIMEOUT_MS) { dhcp_status DHCP_TIMEOUT; break; } } }dhcp_tick()是 ioLibrary 要求每 1ms 调用一次的时基函数。DHCP_run()每次调用都会执行一次状态机推进返回DHCP_RUNNING表示还没完成返回DHCP_IP_ASSIGN表示拿到 IP返回DHCP_FAILED表示超时或链路错误。这里有三个常见的坑一是dhcp_tick()只在主循环调用时必须确保主循环周期小于 1ms否则 DHCP 状态机会误判超时二是DHCP_run()内部会用 socket 2 收发 UDP 报文所以不要在 DHCP 完成前手动占用 socket 2三是拿到 IP 后要立即把芯片里的默认网关和子网掩码读出来后面 TCP 连接会用。如果 DHCP 一直失败最常见的原因是路由器没有开 DHCP或者 W5500 的 MAC 地址全为 0xFF。W5500 出厂时并没有写入 MAC必须在wizchip_init()后用setSHAR()设置一个有效 MAC。注意同一个局域网内多个开发板不能使用相同 MAC否则会出现一台能上线另一台反复掉线的怪故障。3.2 作为 TCP 客户端连接 OneNetsocket 参数不要照抄OneNet 接入服务器地址和端口会随平台版本变化不能拿网上旧例程的 IP 死填。当前常见做法是从 OneNet 控制台对应设备页面获取接入地址很多旧工程示例使用私有端口进行 EDP 长连接但新平台也支持标准 MQTT 端口。无论哪种W5500 侧的动作都是先建立一个 TCP socket再用connect()指定远端 IP 和端口。以下是一个带本地端口绑定的客户端连接示例/* tcp_client.c */ #define LOCAL_PORT 50000 #define SERVER_PORT 8765 /* 替换为 OneNet 控制台显示的端口 */ int8_t tcp_connect_server(uint8_t *server_ip, uint16_t server_port) { int8_t sock socket(0, Sn_MR_TCP, LOCAL_PORT, 0); if (sock 0) { return -1; } int32_t ret connect(sock, server_ip, server_port); if (ret ! SOCK_OK) { close(sock); return -1; } return sock; }socket(0, Sn_MR_TCP, LOCAL_PORT, 0)表示使用 socket 0 建立 TCP 客户端。第三个参数是本地端口不是远端端口很多初学者这里会填成 8765。其实本地端口是让 W5500 绑定一个固定来源端口建议用 40000 到 60000 之间的随机值。第四个参数是 Socket 标志位TCP 客户端一般传 0。connect()是阻塞型调用W5500 硬件会在内部完成 SYN 握手正常情况下几十毫秒内返回SOCK_OK如果对端 IP 不可达通常 5 到 10 秒后返回SOCKERR_TIMEOUT所以主循环在做连接前最好加一个软件超时避免界面假死。OneNet 接入地址不要直接写死成某个固定公网 IP因为平台迁移或负载均衡会改。我一般会在工程配置区放一个宏定义表把平台返回的域名解析成 IP 或用接入点 IP然后单独留一个调试入口方便换场地后重新填。若是从旧例程抄来的 IP 长时间连不上优先去 OneNet 控制台重新复制最新接入地址。3.3 保活、超时和断线重连的状态设计W5500 硬件本身没有 TCP keepalive 机制所以应用层必须在成功连接后周期发送心跳OneNet 旧版 EDP 协议通常要求 30 到 60 秒一次心跳。如果协议指定的频率比这更短以平台文档为准。我在工程里会设置一个全局结构体保存连接状态把发送心跳和接收响应放在同一个轮询函数里typedef enum { NET_IDLE 0, NET_DHCP, NET_CONNECTING, NET_ONLINE } net_state_t; void net_loop(int8_t sock) { static uint32_t last_heartbeat 0; switch (net_state) { case NET_ONLINE: if (HAL_GetTick() - last_heartbeat 30000) { send(sock, heartbeat_pkt, heartbeat_len); last_heartbeat HAL_GetTick(); } break; case NET_CONNECTING: /* 连接失败则重置到 IDLE 并整体重试 */ break; default: break; } }这里没有用while(1)阻塞等待重连而是将网络状态机放入主循环由定时器驱动。这样当 OneNet 服务器端主动关闭连接时recv()会返回SOCKERR_TIMEOUT或 0主循环检测到后调用close(sock)再重新走 DHCP 或直接重连。断线重连建议加退避策略比如第一次失败等 3 秒第二次 5 秒最多 30 秒避免服务器还没恢复开发板已经用高频率 SYN 把自己阻塞住了。良好的状态机设计是这套代码能否长时间稳定跑的关键。4. 单路状态上传与远程控制闭环数据帧构造与命令解析4.1 读取 GPIO 状态并构造 OneNet 上行报文单路状态最常见的输入是按键、门磁或者光电开关。STM32F103 这边先配置一个 GPIO 输入读取电平后做一次消抖。然后需要按 OneNet 的接入协议把状态打包成应用层报文。以旧版 EDP 风格为例报文由类型、剩余长度和消息体组成消息体里包含设备标识和数据点。下面的代码展示了如何把状态值压缩进一个长度不超 127 字节的简单帧/* edp_build.c */ #define EDP_TYPE_DATA 0x03 int build_edp_data(uint8_t *buf, uint8_t device_id, uint8_t api_key_id, uint8_t state) { uint16_t offset 0; uint8_t *len_pos; buf[offset] EDP_TYPE_DATA; len_pos buf[offset]; offset snprintf((char *)buf[offset], 16, %d, device_id); buf[offset] api_key_id; offset snprintf((char *)buf[offset], 8, %d, state); *len_pos (uint8_t)(offset - 2); /* 剩余长度不包含类型和长度字节 */ return offset; }这个函数把设备 ID、APIKey 编号和状态值按顺序塞进缓冲区然后用剩余长度字段告诉对端这次收了多少数据。注意剩余长度在 EDP 协议里按 7 位编码超过 127 字节要使用多字节编码这里状态数据很小所以直接一字节赋值。实际开发中如果你用的是 OneNet 的 MQTT 接入就需要把这块替换成 PUBLISH 报文但“类型 长度 消息体”的思路是一致的。发送时不要直接send()缓冲区里的全部内容因为 TCP 是流协议靠长度字段切分数据。我通常的做法是先send(sock, buf, len, 0)然后记录发送时间。OneNet 服务器返回的 ACK 不一定立即到达主循环里的recv()会负责确认。4.2 解析 OneNet 下发的控制命令并驱动输出远程控制环节读取recv()缓冲区按同样的帧结构拆包。这里重点不是如何把rx_buf[2]变成高低电平而是如何处理 TCP 粘包和拆包。如下代码是根据单包固定长度做解析的简化版/* cmd_parse.c */ #define CMD_BUF_SIZE 32 uint8_t rx_buf[CMD_BUF_SIZE]; uint8_t parse_cmd(int8_t sock, GPIO_PinState *out_state) { int32_t len recv(sock, rx_buf, sizeof(rx_buf) - 1, 0); if (len 0) { return 0; } /* 简单处理一帧只包含一个完整命令 */ if (rx_buf[0] EDP_TYPE_DATA len 4) { uint8_t cmd rx_buf[len - 1]; /* 最后一个字节作为命令值 */ if (cmd 0x01) { HAL_GPIO_WritePin(CTRL_GPIO_Port, CTRL_Pin, GPIO_PIN_SET); } else { HAL_GPIO_WritePin(CTRL_GPIO_Port, CTRL_Pin, GPIO_PIN_RESET); } return 1; } return 0; }这段代码能跑通单帧命令但 TCP 底层不保证一次recv()就能收到完整数据。比如 OneNet 下发一个 10 字节的命令可能前 4 字节先到后 6 字节隔几毫秒才到。因此正式的工程里要维护环形缓冲区把收到的不完整帧缓存起来等长度字段背后的数据全部到达后再解析。这个处理不复杂但直接影响远程控制的可靠性。我遇到过很多次“平台显示已下发但设备没动作”的现场问题最后定位都是拆包逻辑把第二条命令的前缀当成了完整帧。4.3 数据上报策略状态变化上报还是周期上报单路状态场景下常见策略是状态变化时立即上报同时每 30 秒周期上报一次作为心跳。这样既能保证控制端看到的曲线实时刷新又能在设备静默时让平台知道链路存活。状态变化立即上报的代码如下if (HAL_GPIO_ReadPin(SENSOR_GPIO_Port, SENSOR_Pin) ! last_state) { last_state HAL_GPIO_ReadPin(SENSOR_GPIO_Port, SENSOR_Pin); uint8_t pkt[16]; int len build_edp_data(pkt, DEVICE_ID, API_KEY_ID, last_state); send(sock, pkt, len, 0); }周期上报和状态量上报共用同一个打包函数只是周期上报可以带一个时间戳。平台侧看到的数据点如果长时间没有更新需要先检查设备是否掉线。在 OneNet 控制台可以查看设备在线状态和最近一次上报的时间。如果设备显示在线但数据流没有更新大概率是上报的报文格式不对平台虽然建立了 TCP 连接但解析失败。4.4 平台侧创建产品、生成 APIKey 和数据流配置OneNet 平台的接入信息不是随便填的需要先注册并登录自己的账号。进入开发者中心后创建产品选择接入协议时要注意你手里的 W5500 代码是老版 EDP 还是标准 MQTT。如果协议不匹配即便 TCP 连接成功平台也会在鉴权阶段拒绝设备。在设备页面创建单个设备后会得到唯一的设备 ID 和 APIKey。APIKey 相当于访问密钥代码里写入时不要提交到公开的 GitHub 仓库泄露后别人可以往你的设备数据流里灌假数据。数据流名称要和设备上报协议里写的字段保持一致。比如代码里上报的是on_off平台就必须提前新建一个叫on_off的数据流否则上报的数据点不会显示在折线图上。这一步是很多新手最容易忽略的W5500 已经成功连接也发了数据但图表里空空如也。在 OneNet 控制台重新生成 APIKey 后旧 Key 会立即失效需要同步改代码并重启设备不存在热更新。5. 用 Wireshark 验证 OneNet 通信以及 Keil 工程迁移要点5.1 抓包验证先看 TCP 握手再看应用层数据把开发板通过网线接到交换机PC 也接同一交换机Wireshark 选择对应网卡抓包过滤器直接写tcp.port 8765其中 8765 替换成你自己的接入端口。如果有数据立刻能看到 SYN、SYN-ACK、ACK 三条报文这说明 W5500 的 TCP 客户端已经建连成功。再往后每 30 秒会出现一次应用层数据包点开 Payload 看十六进制能明显识别出类型字段和剩余长度字段是否正常。如果只看到 SYN 但不断重发说明服务器端口不通或者服务器回包被防火墙拦截。这时先确认板子能 ping 通网关再用arp -a看是否有正确的 W5500 MAC。W5500 出厂的 MAC 如果写成全 F可能导致网关拒绝转发。抓包时不要混淆 PC 自己的网卡流量最好在过滤器里加上eth.src或ip.addr限定 W5500 的实际 IP。5.2 Keil 工程从其他 STM32F103 型号迁移到 C8T6原工程如果是基于 STM32F103ZET6 或别的型号拿到手后第一件事不是改代码而是改芯片型号。Keil 中点击 Options for Target在 Device 页选择 STM32F103C8然后到 Target 页把 ROM 起始地址设为 0x08000000Size 填 0x10000也就是 64KB Flash。如果这一步不修改烧录器会用错误的 Flash 大小擦写轻则下载失败重则让芯片进入锁死状态。在 C/C 选项卡里STM32F10X_HD要改成STM32F10X_MD。这是 ST 标准外设库里的型号宏C8T6 属于中等密度如果用成高密度宏ADC、Flash 等外设的地址映射会错乱。对于 RM0008 系列的库还需要检查stm32f10x_conf.h里是否启用了所有用到的外设头文件。最后在 Flash Download 设置里选 ST-Link 或 J-Link 对应的下载算法C8T6 的算法文件是 STM32F10x Med-density Flash。如果打开工程后 Device 列表里找不到 STM32F103C8说明 Keil 还没装 STM32 芯片包。安装完成后重启 Keil再检查 Utilities 页的 Debug 驱动。工程里如果同时存在stm32f10x_flash.c和stm32f10x_adc.c不要直接删除C8T6 资源有限不用的外设文件可以移除但前提是stm32f10x_conf.h中对应宏要注释干净。5.3 J-Link 与 ST-Link 选择、No STM32 Target Found 的处理在 Project 的 Options for Debug 里右侧下拉框可以选择 ST-Link Debugger 或 J-LINK。选择后点击 SettingsSW Device 一栏如果能看到一个 ARM 内核 ID 说明正常。如果烧录时提示No STM32 Target Found先检查 BOOT0 引脚是否被拉高到 3.3V。调试时 BOOT0 应该接地否则芯片上电后进入 BootloaderSWD 接口通常还能识别但有些板子会因为供电问题导致无法进入调试模式。另一个实用技巧是把 SWD 速率从 4MHz 或 8MHz 降到 1MHz。杜邦线连接 ST-Link 和板载 SWD 接口时过高的时钟容易受寄生电容影响。按住复位键点击下载等软件提示连接后再松开这个“压枪式”烧录方法能解决很多接触不良问题。如果还是不行用逻辑分析仪检查 ST-Link 的 SWDIO/SWCLK 是否分别连着 PA13/PA14接反会直接烧写失败。跑 OneNet 连接时建议把USE_DHCP宏打开但调试阶段先用静态 IP排除 DHCP 超时导致的网络状态异常再切换回动态获取。本文还有配套的精品资源点击获取