简介：一份基于STM32+ENC28J60+UIP协议栈的嵌入式WEB服务器示例，适合物联网入门开发者与嵌入式学习者，解决在资源受限单片机上实现HTTP服务、远程时间查看与设备控制的需求。压缩包共252个文件，磁盘占用约56.68MB，工程包含头文件、C源码、Keil工程文件、网页素材、PDF说明与演示视频等，其中uip协议栈移植、ENC28J60驱动、httpd等源码可直接查阅修改。实时时间通过STM32内部RTC获取，并可在网页上显示，同时支持LED、蜂鸣器远程控制，便于理解SPI通信、TCP/IP精简协议栈、HTTP请求解析及GPIO外设控制等关键知识点。资源已有1779人学习，适合希望快速搭建小型物联网Web服务、并希望从代码层面掌握底层实现细节的开发者。 STM32+ENC28J60+uIP这个组合，在嵌入式以太网入门里一直是个经典配置。特别是很多做物联网、智能家居或者设备远程监控的工程师，想用最少的成本让MCU“上网”，又不想直接上Linux或者复杂的总线方案，就会翻到这个搭配。这个示例工程我实际跑过几轮，里面不只是点灯，还带了实时时间显示和远程控制，作为毕业设计、产品原型验证，或者纯粹练手理解TCP/IP协议栈，都非常合适。这篇就把整个方案的选型逻辑、硬件连接、软件移植、页面交互和调试踩坑一次性讲透，方便你拿到工程后能快速跑起来，而不是对着代码发懵。
1. 整体方案与选型思路拆解
拿到这个项目，第一件事不是急着编译烧录，而是先想明白一个问题：为什么是STM32+ENC28J60+uIP这个组合？市面上明明还有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模块 |
|---|---|---|
| PA5 | SPI1_SCK | SCK |
| PA6 | SPI1_MISO | MISO |
| PA7 | SPI1_MOSI | MOSI |
| PA4 | GPIO输出 | CS |
| PB0 | GPIO输入/EXTI | INT |
| PB1 | GPIO输出 | RST |
| 3.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?relay=on，你需要从请求报文里找到问号后面的参数字符串，判断relay=on就执行GPIO置位，relay=off就清零。至于完整的HTTP头部，直接跳过不要了，那些User-Agent、Accept这些头对嵌入式设备来说毫无意义。
3.4 页面数据与动态参数填充
实时时间的显示涉及动态数据的生成。最简单的方案是：页面HTML里先用一个固定占位符，比如<span id="time">${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基于UDP，uIP对UDP的支持是有的，而且UDP无连接状态，处理起来比TCP简单很多，协议栈开销也小。
如果NTP请求超时，备选方案是Web页面提供一个表单让用户手动输入时间，组装成类似/settime?time=2025-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, "relay1=on")) { GPIO_SetBits(GPIOC, GPIO_Pin_0); // 继电器1吸合 } else if (strstr(url, "relay1=off")) { GPIO_ResetBits(GPIOC, GPIO_Pin_0); } // 返回一个简单的JSON或者重定向到主页 send_response_ok(); } }这里有一个细节：网页端最好用JavaScript的fetch或XMLHttpRequest发异步请求，页面不跳转，用户体验更好。我页面里的按钮是这样的：
<button onclick="sendCmd('relay1=on')">开启继电器1</button> <script> function sendCmd(cmd) { fetch('/control?' + cmd, {method:'GET'}) .then(res => res.text()) .then(data => document.getElementById('status').innerText = data); } </script>MCU收到控制指令后，除了操作GPIO，我还建了一个状态标志位，在主页面的状态查询接口里返回当前开关状态，这样前端每次刷新状态时就能看到设备的真实状态，而不是只在点击瞬间更新一下。
4.3 静态页面存储与动态数据分离
页面HTML文件我建议不直接塞在代码里的一堆字符串中，而是把它做成一个独立的C文件，用const数组存起来，并用xmodem风格序号标识页面内可替换的位置。这样代码清爽，后期改页面样式也好维护。常见做法就是用Python脚本把HTML文件转换成C数组头文件，每次编译前自动生成。
实际项目里我更喜欢另一个操作：把HTML页面压成gzip格式存放，MCU在HTTP响应头里加一段Content-Encoding: gzip，然后直接发送压缩后的页面数据。gzip压缩后的页面通常只有原始大小的三分之一，对于动不动就要几十KB的Bootstrap样式页面来说效果显著。不过小心一点，MCU端的FLASH容量要足够存放压缩后的页面，同时浏览器的解压效率很高，对用户体验几乎没有影响。
5. 常见问题与排查技巧实录
这个项目的代码量不大，但每一层都有暗坑。我把自己跑通过程中遇到的高频问题和排查思路整理成表，方便你按图索骥。
| 故障现象 | 可能原因 | 排查与解决方法 |
|---|---|---|
| 网卡寄存器读写全是0xFF | SPI模式不对或CS控制不正常 | 检查SPI初始化是否设置为模式0，CS是否在传输前拉低，用逻辑分析仪看时序 |
| 模块能初始化但ping不通 | MAC地址未设置或IP地址冲突 | 确认本地MAC地址非全0，IP设为静态地址，和路由器同一网段，不要重复 |
| 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或者FreeRTOS+TCP，很多概念都会迎刃而解。
这个工程后续还可以扩展的方向也不少。比如把时间源换成GPS或者Wi-Fi模块提供的SNTP数据；控制通道加一层简单的Token鉴权；把Web页面升级成SPA框架，通过JSON接口和MCU交互；或者用MQTT替代HTTP实现设备上报。底层这套STM32+ENC28J60的骨架不用动，应用层往上叠加就行。如果你拿它当毕业设计，把其中一个方向做深，答辩时讲清楚设计取舍和调试过程，效果会非常好。
本文还有配套的精品资源，点击获取
