简介一份基于STM32ENC28J60UIP协议栈的嵌入式WEB服务器示例适合物联网入门开发者与嵌入式学习者解决在资源受限单片机上实现HTTP服务、远程时间查看与设备控制的需求。压缩包共252个文件磁盘占用约56.68MB工程包含头文件、C源码、Keil工程文件、网页素材、PDF说明与演示视频等其中uip协议栈移植、ENC28J60驱动、httpd等源码可直接查阅修改。实时时间通过STM32内部RTC获取并可在网页上显示同时支持LED、蜂鸣器远程控制便于理解SPI通信、TCP/IP精简协议栈、HTTP请求解析及GPIO外设控制等关键知识点。资源已有1779人学习适合希望快速搭建小型物联网Web服务、并希望从代码层面掌握底层实现细节的开发者。 STM32ENC28J60uIP这个组合在嵌入式以太网入门里一直是个经典配置。特别是很多做物联网、智能家居或者设备远程监控的工程师想用最少的成本让MCU“上网”又不想直接上Linux或者复杂的总线方案就会翻到这个搭配。这个示例工程我实际跑过几轮里面不只是点灯还带了实时时间显示和远程控制作为毕业设计、产品原型验证或者纯粹练手理解TCP/IP协议栈都非常合适。这篇就把整个方案的选型逻辑、硬件连接、软件移植、页面交互和调试踩坑一次性讲透方便你拿到工程后能快速跑起来而不是对着代码发懵。1. 整体方案与选型思路拆解拿到这个项目第一件事不是急着编译烧录而是先想明白一个问题为什么是STM32ENC28J60uIP这个组合市面上明明还有W5500、DM9000、CH395这些选项甚至直接上ESP8266模块走Wi-Fi不香吗这里得从应用场景和成本说起。STM32作为主控不用多讲生态成熟、资料多、价格透明Cortex-M3/M0内核的芯片在控制领域是绝对主力。而以太网接入这块ENC28J60是Microchip出的一款10Mbps以太网控制器走SPI接口与MCU通信芯片本身集成了MAC和PHY外部只需要一个25MHz晶振、网络变压器和RJ45座子就能工作。相比W5500这类内置硬件TCP/IP协议栈的芯片ENC28J60只是裸的以太网MAC/PHY控制器TCP/IP协议需要MCU自己跑。很多人觉得这是缺点但实际上这恰恰是这个项目最大的学习价值——协议栈怎么工作、TCP连接怎么建立、HTTP请求怎么解析你都能看得一清二楚。再来说uIP协议栈。uIP是Adam Dunkels写的轻量级TCP/IP协议栈专为8位和16位MCU设计整个代码量很小RAM占用控制得非常苛刻。和lwIP相比uIP不支持多线程、BSD Socket接口也极其有限但它胜在简单、透明、好移植。在STM32F103这类20KB RAM的芯片上跑lwIP会比较紧张而uIP只需要几KB的缓冲配合就行。这种取舍在这个项目里非常合理目标是做一个Web服务器同时支持少量并发连接uIP的轮询式处理完全够用代码也容易看懂。选择这个方案还有一层实际考虑板级成本低。SPI接口的以太网模块国产化程度高市面上十几二十块就能买到封装好的最小系统板引脚也就SCK、MISO、MOSI、CS、INT、RST这6根线接线极其简单。相比之下走FSMC接口的DM9000、LAN8720虽然速度快但引脚占用多新手容易接错线调试成本高。所以从这个角度说ENC28J60非常适合作为MCU以太网入门的“第一块网卡”。2. 硬件电路设计与连接要点硬件上要跑通这个项目核心就是STM32与ENC28J60之间的SPI通信链路。接线看似简单但几个细节直接影响稳定性。2.1 SPI接线与引脚规划我用的主控是STM32F103C8T6也就是最常见的“蓝丸”核心板。SPI选用SPI1引脚分配如下STM32引脚功能连接ENC28J60模块PA5SPI1_SCKSCKPA6SPI1_MISOMISOPA7SPI1_MOSIMOSIPA4GPIO输出CSPB0GPIO输入/EXTIINTPB1GPIO输出RST3.3V/GND电源VCC/GND这里有一个很容易踩的坑ENC28J60的内核电压是3.3V但很多模块板载了电平转换可以直接接5V供电。不过为了保险建议VCC接3.3V因为STM32的引脚容忍度虽然在多数引脚上是5V兼容但SPI引脚直接对接时统一3.3V更稳妥能避免模块上的稳压芯片发热或者长期工作不稳定的问题。2.2 复位与中断引脚的配合RST引脚是低电平复位ST例程里通常会在初始化时拉低再拉高执行一次硬复位。INT引脚是中断输出低电平有效。这个引脚很关键它告诉MCU“网卡收到了新数据”或者“发送完成了”MCU可以不用轮询寄存器直接靠外部中断响应从而节省CPU资源。我是把INT接到了PB0并配置为EXTI0下降沿触发这样主循环不被网络轮询频繁打扰逻辑也清晰。注意如果你在调试中发现网卡初始化的寄存器读写总是失败大概率不是代码问题而是CS引脚的片选时序不对。SPI通信时CS必须严格在传输前拉低、传输后释放并且SCK空闲电平要和ENC28J60要求的SPI模式一致模式0或模式3均可例程一般用模式0务必用示波器或者逻辑分析仪看一眼时序。2.3 晶振与网络变压器的选型模块上如果自带25MHz晶振就不需要额外操心。如果自己画板子特别注意晶振负载电容的匹配典型值是18~22pF具体要根据晶振手册的CL值计算。ENC28J60的ETH时钟是25MHz但这颗芯片的PLL是内部处理的外部晶振频率必须准确否则上电后PHY协商就会出现诡异的问题——比如偶尔能link上、时断时续。网络变压器和RJ45部分建议直接买集成好的模块HR911105A这类手工搭分离式变压器太容易出问题特别是绕线方向反了或者中心抽头接地不对会导致完全不通。实测下来集成的HR911105A模块稳定性最好直接插网线到路由器或交换机即可10Mbps速率在Web服务器这种场景完全够用。3. uIP协议栈的移植与配置uIP的移植是这个项目软件部分的核心。虽然uIP源码是现成的但想让它真正稳定跑在STM32上需要理解几个关键环节底层驱动、内存缓冲、时钟节拍、应用层回调。3.1 底层驱动接口uIP不直接操作网卡寄存器它通过两个函数和底层驱动打交道uip_input()和uip_periodic()。前者用于处理网卡收到的数据包后者用于让各TCP连接的超时和重传定期得到处理。// 在中断中收到一个包后调用 if (ENC28J60_PacketReceive()) { uip_len ENC28J60_ReadPacket(uip_buf, UIP_BUFSIZE); if (uip_len 0) { uip_input(); if (uip_len 0) { ENC28J60_SendPacket(uip_buf, uip_len); } } }注意uip_buf这个全局缓冲区uIP所有收发的数据都经过它。默认大小是UIP_BUFSIZE对于10Mbps以太网来说最大帧接近1514字节但如果在RAM紧张的MCU上可以适当调小到600字节左右代价是TCP窗口变小、传输效率下降。实际经验是STM32F103C8T6有20KB RAM完全不虚直接保持默认即可。3.2 定时节拍与轮询uIP内部有很多定时器比如TCP的RTO计算、重传超时等都需要一个毫秒级的时基。你需要提供一个函数周期性调用uip_periodic()通常放在SysTick中断或者一个1ms的定时器标志位里。void SysTick_Handler(void) { // 每250ms调用一次uIP周期性处理 if (sys_tick 250) { sys_tick 0; uip_periodic_process(); } } void uip_periodic_process(void) { for (int i 0; i UIP_CONNS; i) { uip_periodic(i); if (uip_len 0) { ENC28J60_SendPacket(uip_buf, uip_len); } } }这里的UIP_CONNS是uIP最大TCP连接数默认配置是4或者10。数值越大越占RAM我们做Web服务器通常打开一个网页会同时有几条TCP连接页面本身的连接、后续AJAX请求的连接等建议设置为4即可。设置太多不仅浪费内存还会导致排查问题时搞不清到底是哪条连接在交互。3.3 HTTP协议的实现思路uIP本身不解析HTTP它只是把收到的TCP数据交给应用层。Web服务器的数据完全靠你在httpd_appcall这个回调里自己处理。常见做法是把端口80的监听连接及应用层逻辑绑定void httpd_appcall(void) { if (uip_conn-lport HTONS(80)) { if (uip_newdata()) { handle_http_request(); } if (uip_ackdata() uip_len 0) { uip_send(next_page_part, next_page_len); } } }收到请求后需要解析请求行里的方法和URL。这里我强烈建议不要把HTTP解析做得太复杂只需要判断GET请求、提取URL路径和参数即可。比如客户端请求/control?relayon你需要从请求报文里找到问号后面的参数字符串判断relayon就执行GPIO置位relayoff就清零。至于完整的HTTP头部直接跳过不要了那些User-Agent、Accept这些头对嵌入式设备来说毫无意义。3.4 页面数据与动态参数填充实时时间的显示涉及动态数据的生成。最简单的方案是页面HTML里先用一个固定占位符比如span idtime${TIME}/span然后在发送数据前把${TIME}替换成从RTC读出并格式化好的时间字符串。由于uIP的发送是分段的受限于TCP窗口你得把控整个页面的大小一般控制在4KB以内比较舒服。实际操作中我更推荐把时间这个值单独用一个AJAX请求处理。页面加载后JavaScript定时每隔1秒向/gettime这个URL发起请求MCU只返回一个纯文本的时间字符串比如2025-01-15 14:30:22前端脚本直接填入页面。这样的好处是页面主体是静态的可以编译成const数组存到Flash里不用每次都动态生成减轻MCU压力同时页面刷新不闪烁。4. 实时时间获取与继电器控制的核心实现4.1 时间从哪里来NTP与RTC联动这个示例带了“实时时间”功能很多人第一反应是STM32内部RTC模块自己跑时间。但MCU的RTC必须在上电时有一个基准时间否则开机就是2000年1月1日毫无意义。所以我在工程里做了两层方案上电阶段MCU首先通过ENC28J60发起一个NTP请求到公共时间服务器如ntp.aliyun.com或cn.pool.ntp.org从NTP响应包中提取48字节的报文其中第40~43字节是自1900年以来的秒数UTC时间转换成北京时间东八区直接加28800秒后写入RTC备份寄存器或外部RTC芯片。NTP服务器的IP地址一般用固定IP或者域名解析uIP的DNS解析能力有限稳妥的办法是直接用已知的NTP服务器IP。或者你在路由器上做端口转发、内网自己搭一个NTP服务从路由器同步时间也行。实测中由于NTP基于UDPuIP对UDP的支持是有的而且UDP无连接状态处理起来比TCP简单很多协议栈开销也小。如果NTP请求超时备选方案是Web页面提供一个表单让用户手动输入时间组装成类似/settime?time2025-01-15-14-30-22这样的请求MCU解析后直接写入RTC。这个方法看起来“土”但非常稳妥不依赖外网在局域网场景下完全够用。提示如果你用的是STM32F103内部RTC注意它只有一个32位计数器单位是秒靠外部32.768kHz晶振提供时钟源。这里要特别注意晶振的负载电容和走线否则时间跑快了或者慢了真是查一天都发现不了。4.2 控制通道GET请求解析与GPIO操作控制功能的实现是另一个重点。正常情况下控制设备用POST比GET更安全因为URL参数会暴露在浏览器的历史记录和服务器日志里。但在嵌入式MCU这种资源受限环境下解析POST请求体需要额外的缓冲区而且比较复杂所以我们这里按GET方式来但在产品级设计时一定要加访问鉴权不能裸奔。我工程里的控制逻辑是这样的void handle_control_request(char *url) { if (strncmp(url, /control, 8) 0) { if (strstr(url, relay1on)) { GPIO_SetBits(GPIOC, GPIO_Pin_0); // 继电器1吸合 } else if (strstr(url, relay1off)) { GPIO_ResetBits(GPIOC, GPIO_Pin_0); } // 返回一个简单的JSON或者重定向到主页 send_response_ok(); } }这里有一个细节网页端最好用JavaScript的fetch或XMLHttpRequest发异步请求页面不跳转用户体验更好。我页面里的按钮是这样的button onclicksendCmd(relay1on)开启继电器1/button script function sendCmd(cmd) { fetch(/control? cmd, {method:GET}) .then(res res.text()) .then(data document.getElementById(status).innerText data); } /scriptMCU收到控制指令后除了操作GPIO我还建了一个状态标志位在主页面的状态查询接口里返回当前开关状态这样前端每次刷新状态时就能看到设备的真实状态而不是只在点击瞬间更新一下。4.3 静态页面存储与动态数据分离页面HTML文件我建议不直接塞在代码里的一堆字符串中而是把它做成一个独立的C文件用const数组存起来并用xmodem风格序号标识页面内可替换的位置。这样代码清爽后期改页面样式也好维护。常见做法就是用Python脚本把HTML文件转换成C数组头文件每次编译前自动生成。实际项目里我更喜欢另一个操作把HTML页面压成gzip格式存放MCU在HTTP响应头里加一段Content-Encoding: gzip然后直接发送压缩后的页面数据。gzip压缩后的页面通常只有原始大小的三分之一对于动不动就要几十KB的Bootstrap样式页面来说效果显著。不过小心一点MCU端的FLASH容量要足够存放压缩后的页面同时浏览器的解压效率很高对用户体验几乎没有影响。5. 常见问题与排查技巧实录这个项目的代码量不大但每一层都有暗坑。我把自己跑通过程中遇到的高频问题和排查思路整理成表方便你按图索骥。故障现象可能原因排查与解决方法网卡寄存器读写全是0xFFSPI模式不对或CS控制不正常检查SPI初始化是否设置为模式0CS是否在传输前拉低用逻辑分析仪看时序模块能初始化但ping不通MAC地址未设置或IP地址冲突确认本地MAC地址非全0IP设为静态地址和路由器同一网段不要重复ping通但浏览器打不开页面TCP端口绑定错误或HTTP解析卡死查看uIP配置中是否监听80端口串口打印原始请求确认数据是否到达页面打开一次后连接卡死TCP连接未正确关闭连接数耗尽uIP的Web服务器在处理完请求后要主动调用uip_close()或uip_abort()时间显示不对或每次重启回退RTC晶振不起振或备份电池缺失检查32.768kHz晶振焊接情况测量RTC秒中断是否产生后备电池是否供电NTP请求超时路由器禁止UDP出外网域名解析失败先ping通网关再ping NTP服务器IP确认UDP端口123未被封禁还有一个我在多个STM32平台上反复遇到的坑当开启编译器优化等级-O2或更高时uIP协议栈中某些涉及字节序转换的代码可能会被优化出问题表现就是能收到数据但解析出的端口号、长度字段乱了。遇到这种情况一是把uIP相关文件单独设置为-O0编译二是在关键结构体定义上加上__attribute__((packed))强制对齐为1防止编译器插入填充字节。另外如果你用的STM32型号是F103ZE这种大容量版注意VREF、VREF-引脚的电压参考是否接好否则ADC和部分外设会异常。这个看起来和网络无关但我在调试中碰到过一次SPI数据错乱最后发现是电源纹波太大导致的根源是VREF悬空、模拟部分受干扰。Web服务器在运行时Flash存储的页面和动态数据的拼接要小心缓冲越界。我建议发送HTTP头和页面数据时分段调用uip_send()而不是拼一个大buffer。uIP的TCP发送窗口很小通常只有几百字节一次性发送大数据会被截断导致丢包分段发送才能保证浏览器完整接收到。实测中将页面切成不超过400字节的段循环调用发送函数稳定性和兼容性最佳。最后说一个容易被忽略的点局域网内设备增多后交换机或路由器上的ARP缓存是有限的。如果MCU设备长时间不通信ARP表项可能会被老化清除上位机再访问时会先发ARP请求MCU需要及时响应ARP。uIP对ARP的响应默认是自动完成的但前提是底层驱动要正确接收广播帧。所以不要为了省资源把收包中断关掉务必将ENC28J60_PacketReceive()放在低优先级中断里持续监听。我在这个项目上最大的体会就是MCU做Web服务器最难的不是把代码跑通而是理清每个网络事件的时间线——什么时候收包、什么时候回复、什么时候关闭连接。uIP的轮询模型虽然老派但没有操作系统的上下文切换状态机清晰可见非常锻炼内功。你把它移植一遍、跑通一遍再去接触lwIP或者FreeRTOSTCP很多概念都会迎刃而解。这个工程后续还可以扩展的方向也不少。比如把时间源换成GPS或者Wi-Fi模块提供的SNTP数据控制通道加一层简单的Token鉴权把Web页面升级成SPA框架通过JSON接口和MCU交互或者用MQTT替代HTTP实现设备上报。底层这套STM32ENC28J60的骨架不用动应用层往上叠加就行。如果你拿它当毕业设计把其中一个方向做深答辩时讲清楚设计取舍和调试过程效果会非常好。本文还有配套的精品资源点击获取