企业官网建设流程全解析

基于STM32的物联网宠物喂食器：从需求拆解到毕设落地的完整复盘

最近好几个师弟师妹来问我同一个问题：宠物喂食器这个题目到底怎么下手？搜了一圈资料发现要么是商家软文，要么是51单片机加个舵机就完事的简化版，真正能把“物联网”三个字做实、又能顺利通过答辩的内容反而很少。我干脆把自己做这题的完整思路、代码结构、硬件选型和踩坑记录整理出来，给准备拿STM32做毕设的朋友一份能直接对着做的参考。

这篇内容适合三类人：一是物联网工程、电子信息、自动化专业的应届毕业生，正在纠结毕设选题；二是想自己做一台智能喂食器送给家里主子的DIY玩家；三是准备参加电子设计竞赛、想把“智能硬件小项目”做得更完整的学生团队。无论你是哪种，这篇文章的目标只有一个——让你从“听说过STM32”到“能独立把一台宠物喂食器做出来并跑通物联网通信”。

先交代一下我当时技术选型的大体框架再展开细讲：主控用STM32F103C8T6，称重模块用HX711加电阻应变片压力传感器，出粮机构用步进电机加螺旋推进器，Wi-Fi模块用ESP8266-01S，上位机用微信小程序通过MQTT协议控制，云平台用的是阿里云物联网平台。这套方案下来，你要花钱的地方大约在150元以内，BOM清单我后面会给出。

1. 整体设计与思路拆解

1.1 为什么主控选STM32F103C8T6而不是51或者Arduino

很多人在选题初期最先纠结的就是主控芯片。今年搜索词里“51单片机电磁炉程序大全”“c51单片机串口升级架构”这类词热度一直很高，说明还是有不少人在51和STM32之间犹豫。我的观点非常直接：毕设选题选STM32，性价比远高于51。

原因有三。

第一，从工作量角度说，51单片机做一个“电机定时转几圈”的喂食器确实也能跑，但那更像大二课程设计，撑不起一篇合格的毕业论文。STM32F103C8T6基于Cortex-M3内核，主频72MHz，RAM有20KB，Flash有64KB，外设接口丰富，你可以名正言顺地把“FreeRTOS移植”“多任务调度”“ESP8266驱动”“MQTT协议栈对接”这些内容写进论文里。开题报告、中期检查、正文撰写、系统测试这些环节，每个都有着力的点。

第二，从电路复杂度和调试难度来看，STM32F103C8T6是LQFP48封装，引脚间距0.5mm，手工焊接虽然有难度，但如果你用转接板或者直接在核心板上开发，跳线连接就非常方便了。国内市面上十几块钱就能买到一块完整的核心板，板载晶振、复位电路、USB转串口芯片，插上数据线就能用Keil下载程序，省去了自己画最小系统板的功夫。

第三，从答辩和后续扩展的角度看，用STM32意味着你可以很自然地把“多传感器融合”“嵌入式实时操作系统”“低功耗管理”“云平台对接”这些术语串起来，而这些恰恰是评审老师关注的重点方向。你总不希望答辩时被问“你为什么不用STM32”然后只能回答“因为不太会”吧。

1.2 功能模块拆解：一台喂食器到底需要什么

我不能直接说“照着我的方案做就一定能拿优”，但一个功能完整、逻辑自洽的宠物喂食器，至少应该覆盖以下五个维度：

• 定时定量出粮：这是喂食器的核心功能。你需要能配置每天喂几次、每次出多少克，系统到点后自动控制执行机构完成出粮。
• 余粮检测与缺粮报警：最好能实时知道储粮桶里还剩多少粮，低于阈值时通过手机通知主人。
• 远程控制：主人不在家时，可以通过手机App或小程序手动触发一次出粮。
• 状态可视化：设备要能上报当前余粮、上次喂食时间、设备在线状态等信息，让用户随时能看。
• 异常提示与基础数据记录：比如电机堵转、传感器离线等异常情况需要反馈到用户端，喂食历史数据最好也能保留一段时间方便查看。

这五个功能全部做完，工作量已经比较饱满了。如果你的毕设要求更高，还可以往上加摄像头拍照、语音播报、环境温湿度监测等模块，但我建议先保证主体功能稳定，再做锦上添花的事。

硬件架构上我采用的是“主控+传感器+执行机构+通信模块”的经典四层结构。主控层负责逻辑调度，传感器层负责采集数据，执行机构层负责物理动作，通信模块层负责跟云端交互。这四层之间通过GPIO、UART、I2C等接口连接，每一层职责单一，哪一环出了问题可以快速定位。

1.3 软件架构：为什么用FreeRTOS而不是裸机编程

很多教程示例代码都是裸机轮询的方式，就是一个while(1)循环里挨个处理按键、显示、传感器等任务。这种写法在小项目里没问题，但放到宠物喂食器这种“既要实时响应电机控制，又要处理网络数据，还要定时读称重数据”的场景下，很容易出现任务之间互相拖延的情况。

我当时对是否上FreeRTOS犹豫过，后来做了一版裸机代码实测：ESP8266在使用TCP透传模式时，因为要处理串口中断接收、数据帧解析、超时重传等逻辑，会导致主循环里定时器的读取延迟几十毫秒。对步进电机控制来说，几十毫秒的延迟不至于出错，但如果你后面要接多个传感器或者做更复杂的逻辑，这种延迟会被不断放大。

上FreeRTOS之后，我把系统分成几个独立任务：

• 出粮控制任务：负责初始化步进电机GPIO和定时器PWM，等待队列消息，有出粮指令就执行，执行完更新状态标志。
• 称重采集任务：定时读取HX711数据，做滤波处理，把余粮值写入共享变量。
• 网络通信任务：处理ESP8266收发的数据，维护MQTT心跳，接收来自云端的控制指令。
• LED/提示灯任务：纯辅助性质，用于本地状态显示。

任务之间通过FreeRTOS的队列和信号量通信，互相不阻塞。这样设计之后，即使网络通信任务在处理一个超时重传，出粮控制任务依然可以准时执行。我测试过在ESP8266断网重连的场景下，喂食器的定时出粮功能完全不受影响，这就是实时操作系统的价值。

2. 核心硬件选型与电路设计要点

2.1 出粮机构：步进电机和舵机到底选哪个

这是很多新手最纠结的点。淘宝上卖的宠物喂食器大多用舵机带动一个拨片或者转盘，好处是便宜、控制逻辑简单，坏处是扭力有限、出粮量控制不精确。如果你用的是颗粒直径不均匀的猫粮狗粮，舵机拨片很容易卡粮，而且一颗粮卡住就可能导致后面的粮全部堵在出粮口。

我最终选择的是28BYJ-48步进电机加ULN2003驱动板。这个组合在淘宝上大概十块钱左右，优点是扭矩比舵机大、控制精确、可以通过控制步数来精确控制出粮量，缺点是需要额外的驱动电路和脉冲控制逻辑。不过在STM32上产生PWM脉冲是小菜一碟，用定时器输出比较模式和GPIO翻转都行，示例代码网上非常多。

出粮机构的具体设计，我用的是“步进电机直连螺旋推进器”方案。储粮桶底部开一个圆孔，螺旋推进器插入圆孔中，电机转动时螺旋叶片把粮食从桶内推到出粮口。这种结构相当于一个简易的螺旋输送机，对颗粒状粮食的适应性比拨片方案好很多，也不容易卡粮。如果实在买不到合适的螺旋推进器，用一个内径稍大的弹簧也可以临时替代，效果还不错。

出粮量标定是一个需要实测的过程。理论上电机转N圈对应出粮M克，但粮的颗粒大小、湿度、储粮桶内粮食余量都会影响实际出粮量。我做了多次标定的结果，同一批次猫粮，每转出粮量误差大约在5%到10%之间。这个精度对宠物喂食场景完全够用——你家猫不会因为一顿少了2克粮就找你算账，但你需要在论文测试部分把这个误差数据如实记录下来。

2.2 称重方案：HX711加电阻应变片传感器

储粮桶里的余粮检测，如果你不加这个模块，系统就是个“会定时倒粮的盒子”，离“智能”还差得远。加上余粮监测之后，你才能实现缺粮提醒、按剩余量动态调整出粮次数这些更有价值的功能。

称重方案我选了HX711加电阻应变片式压力传感器。HX711是一颗24位高精度A/D转换芯片，专门用于电子秤方案，两路差分输入，内置稳压电源，通信接口是简单的两线制（DOUT和SCK），直接接STM32的任意两个GPIO口就可以读取数据。芯片成本大概两三块钱，配套的压力传感器也就两三块钱，整套称重方案成本在五块钱以内。

电路连接上有一点需要特别注意：HX711的供电最好用独立的模拟电源，或者至少要用RC滤波电路对电源进行去耦。因为步进电机启动瞬间电流波动很大，如果和HX711共用一个电源，称重数据会剧烈跳动。我一开始没注意这个问题，电机一转起来，称重数据从800克直接跳到1200克，查了两天才发现是电源干扰。后来在HX711的AVDD引脚加了一个10uF电容和一个0.1uF电容并联去耦，电机转动时称重数据波动从几十克降到了两三克，效果立竿见影。

软件上，HX711的原始数据并不能直接当重量用。你需要先进行标定：放一个已知重量的物体，读取原始值，计算比例系数。具体公式和标定流程我在第三节实操部分详细展开。

2.3 通信模块：ESP8266-01S连接阿里云物联网平台

ESP8266-01S在物联网毕设里是老熟人了。它本身是一颗完整的Wi-Fi SoC，可以通过AT指令控制，也可以刷NodeMCU固件用Lua脚本开发，甚至可以直接用Arduino IDE开发。在STM32为主控的架构里，最省事的方式就是让ESP8266跑AT固件，STM32通过串口向它发送AT指令完成连接Wi-Fi、建立TCP连接、订阅MQTT主题等操作。

选择ESP8266-01S而不是ESP32或者ESP8266-12F，主要原因是01S模块体积小、引脚少、接入简单。四个引脚里我们只用TXD、RXD、VCC、GND，剩下的EN引脚拉高、GPIO0悬空即可，非常适合快速原型验证。

云平台选型方面，我试过两个方案。第一版用的是自己搭的TCP服务器加MQTT Broker，当时想着这样可以展示更多的网络功底，但实际调试起来很痛苦——你得自己维护设备认证、消息持久化、离线消息补发等等一堆问题，毕设时间根本耗不起。后来切换到阿里云物联网平台，设备接入、主题定义、消息流转这些全都图形化配置，省了大量时间。而且阿里云物联网平台的公共实例免费额度对于毕设场景完全够用，也不用担心被收费。

MQTT协议理解起来其实不复杂，你可以把它想象成一个公告板系统。设备端和手机端都是“订阅者”，它们可以订阅某个主题，也可以向某个主题发布消息。阿里云物联网平台充当公告板本身，负责把发布者的消息转发给所有订阅者。宠物喂食器的场景中，设备订阅的主题用来接收手机下发的控制指令，设备发布的主题用来上报状态数据。每一条消息都有主题和内容两部分，内容格式你自行定义，自由度和灵活性都很大。

2.4 BOM清单和整体连线要点

连线方面，步进电机驱动板的IN1到IN4分别接STM32的PB12到PB15，HX711的DOUT和SCK接PB6和PB7，ESP8266的TXD和RXD接PA3和PA2（即USART2的RX和TX）。VCC和GND注意3.3V和5V别接错，ESP8266-01S的VCC需要接3.3V，接5V会烧模块。这可能是新手最容易犯的错误，我亲眼见过好几个同学烧过模块。

3. 软件实现与AI助手辅助开发实录

3.1 STM32端工程搭建

我用的开发环境是Keil MDK5加STM32CubeMX生成的初始化代码。三个文件夹分别是Core、Drivers和Middlewares，Drivers里放HAL库和CMSIS，Middlewares里放FreeRTOS。这些通过CubeMX图形化配置就能自动生成，没必要手写启动文件和时钟配置。

CubeMX里的关键配置项我先列出来：

• 时钟源选择外部晶振（HSE），主频设为72MHz。
• USART1设为异步模式，波特率115200，用于调试日志输出。
• USART2设为异步模式，波特率115200，用于和ESP8266通信。
• TIM3设为PWM生成模式，输出通道CH1和CH2，频率为3.2kHz，用于步进电机脉冲控制。这里选3.2kHz是因为28BYJ-48步进电机的最高空载频率大约在3.5kHz左右，留一些余量防止丢步。
• GPIO配置：PB12~PB15设为推挽输出，控制ULN2003的四个输入；PB6、PB7设为输入/输出模式，用于HX711通信。
• FreeRTOS配置：通过CMSIS-V1接口启用，堆大小设为8KB，默认创建两个任务。

生成代码之后，剩下的工作就是往模板里填充业务逻辑。

3.2 步进电机驱动程序

28BYJ-48是四相八拍步进电机，驱动方式有两种：一种是直接用GPIO依次给四相通电，每步换一次相序；另一种是用ULN2003驱动板上面自带的逻辑，通过脉冲加方向信号控制。但淘宝上最常见的ULN2003驱动板上其实并没有做脉冲分配，它就是简单的达林顿管阵列，所以STM32需要自己产生四相时序。

我用的方式是直接GPIO翻转，相序表如下：

const uint8_t motorSteps[8][4] = { {1, 0, 0, 0}, {1, 1, 0, 0}, {0, 1, 0, 0}, {0, 1, 1, 0}, {0, 0, 1, 0}, {0, 0, 1, 1}, {0, 0, 0, 1}, {1, 0, 0, 1} };

每步对应的相序就是让四个引脚按照这个表依次输出高低电平。28BYJ-48内部减速比是1:64，也就是电机轴转一圈需要64乘8等于512个步进周期。我计算过实际测试值，出粮口每转一圈大约出粮3克，如果你要出10克粮，就控制电机转3.33圈，也就是约1706步。这个数字我标定了好几轮才稳定下来，不同粮食颗粒大小差异很大，你在做的时候一定要根据自己使用的粮重新标定。

步进电机的转速控制也很关键。如果你直接让定时器以最高频率驱动电机，电机会因为惯性导致丢步，发出的脉冲数和实际转动步数不一致，出粮量就不准。我采取的是加速度控制：启动时先给一个比较低的频率，比如1000Hz，然后逐步加速到2500Hz，接近目标步数时再逐渐减速。这样电机转动非常稳定，最后几步也不会因为惯性冲过头。如果你嫌麻烦，也可以直接用固定频率1500Hz跑，误差在可以接受的范围内。

3.3 HX711称重读取与滤波

HX711的通信协议是典型的时序控制型协议。每次读取时，你首先要把DOUT引脚拉高，然后把SCK引脚输出24个上升沿脉冲，每来一个脉冲，DOUT引脚上就会移出一位数据。24位数据格式是二进制补码，需要合成为一个int32类型变量。

简单的读取代码框架：

uint32_t HX711_Read(void) { uint32_t Count = 0; uint8_t i; HAL_GPIO_WritePin(HX711_SCK_GPIO_Port, HX711_SCK_Pin, GPIO_PIN_RESET); while (HAL_GPIO_ReadPin(HX711_DOUT_GPIO_Port, HX711_DOUT_Pin) == GPIO_PIN_SET); for (i = 0; i < 24; i++) { HAL_GPIO_WritePin(HX711_SCK_GPIO_Port, HX711_SCK_Pin, GPIO_PIN_SET); Count = Count << 1; HAL_GPIO_WritePin(HX711_SCK_GPIO_Port, HX711_SCK_Pin, GPIO_PIN_RESET); if (HAL_GPIO_ReadPin(HX711_DOUT_GPIO_Port, HX711_DOUT_Pin) == GPIO_PIN_SET) Count++; } HAL_GPIO_WritePin(HX711_SCK_GPIO_Port, HX711_SCK_Pin, GPIO_PIN_SET); Count ^= 0x800000; HAL_GPIO_WritePin(HX711_SCK_GPIO_Port, HX711_SCK_Pin, GPIO_PIN_RESET); return Count; }

读取到原始值之后，要换算成重量。换算公式是：

重量（克） = （当前读数 - 空载读数） / （标定重量对应读数差） × 标定重量

例如，空载时读数稳定在820000，放一个500克砝码后读数稳定在976000，那么比例系数为（976000 - 820000）/ 500 = 312，即每克对应312个原始值。你在实际标定时取5个不同重量点做线性拟合，效果会更好。

HX711的原始数据其实是有噪声的，尤其在你放了储粮桶、粮食颗粒在移动之后，最后一位甚至两位都会抖动。我在软件里做了简单的中位值平均滤波：连续读取5次，去掉最大值和最小值，中间3个取平均。这样处理之后的数据稳定度在正负1克以内，对余粮监测来说足够用了。

3.4 ESP8266的MQTT对接和STM32端的AT指令控制

ESP8266-01S模块默认固件是AT固件，通过串口接收指令。我们在STM32端写一个串口收发缓冲区的环形队列，把从ESP8266收到的所有数据暂存起来，然后有一个状态机去解析缓冲区里是否出现了我们关心的关键词。

流程分四步：

第一步，配置ESP8266连接Wi-Fi。你需要向它发送“AT+CWMODE=1”，然后“AT+CWJAP=你的WiFi名称,WIFi密码”。这里有一个坑：如果Wi-Fi名称或者密码里有特殊字符，AT指令的转义处理会非常麻烦。建议你直接用一个纯字母数字的测试热点，比如“TestAP”和“12345678”，等代码跑通了再换真实网络。

第二步，连接MQTT Broker。阿里云物联网平台的接入地址格式是“productKey.iot-as-mqtt.cn-shanghai.aliyuncs.com”。你需要向ESP8266发送“AT+CIPSTART=TCP设备证书,1883”，然后在TCP连接建立之后，按照MQTT协议格式发送CONNECT报文。

第三步，订阅主题。阿里云物联网平台的三段式主题格式是“/productKey/deviceName/user/get”，你需要把“user/get”作为订阅主题。AT模式下要向ESP8266发送“AT+CIPSEND”命令，然后跟着MQTT SUBSCRIBE报文。

第四步，发布消息。当设备需要上报数据时，按照MQTT PUBLISH报文格式组织数据，通过AT+CIPSEND发送。

用AT指令直接拼MQTT报文确实比较繁琐，因为你要自己计算报文长度字段和校验字段，稍不注意就出错。更省力的方案是在STM32端移植一个轻量级MQTT库，比如paho-embedded-c，这样可以直接在STM32侧处理MQTT报文格式。我最终采用的是自己写报文封装函数，因为毕设时间紧张，而且移植paho库需要额外适配网络接口层。

实际上对你来说，最简单的方案可能是直接使用AT指令版MQTT透传，也就是先用AT+CIPSTART建立TCP连接，然后直接把MQTT协议数据通过串口发给ESP8266，ESP8266只负责透传字节流，MQTT报文由STM32自己生成。这样做虽然稍微麻烦一点，但调试起来非常直观，也方便你理解MQTT协议的底层细节。

3.5 微信小程序端实现

手机端我选择了微信小程序，因为它不需要用户额外安装App，扫码就能用，对答辩演示也比较方便。小程序的MQTT实现可以用mqtt.js这个库，微信开发者工具里能直接安装。

小程序的功能我分了三个页面：

• 首页：显示设备在线状态、储粮桶余粮百分比、上次喂食时间，有一个“立即喂食”按钮。
• 设置页：配置每日喂食计划和每次出粮克数。
• 记录页：展示最近的喂食历史，包含时间、出粮克数、触发方式（手动还是定时）。

小程序和云端通信走的是阿里云物联网平台提供的“设备属性上报+服务调用”接口。设备上报属性时，平台会保存最新的属性值；小程序通过云平台的HTTP API读取属性，或者通过AMQP服务端订阅接收消息推送。设置页里配置喂食计划时，小程序先通过HTTP API把配置下发到云端，云端再把配置通过MQTT下发给设备。整体链路是“小程序→阿里云→ESP8266→STM32”这样一条完整闭环。

编译小程序端需要注意几个点：微信开发者工具需要开启“不校验合法域名”选项，因为连的MQTT地址不在微信的合法域名白名单里；mqtt.js库的版本要用0.4.X版本，新版本有些API在微信环境下不支持；小程序切到后台超过一定时间会销毁WebSocket连接，所以页面onShow时需要重新建立MQTT连接。

4. 常见问题与调试技巧实录

4.1 ESP8266连接不稳定、掉线频繁

这个问题我大概花了两天时间排查。一开始以为是固件问题，刷了好多版本的AT固件都没解决。后来发现是供电不足——ESP8266在发射瞬间电流峰值可以达到300毫安以上，而3.3V稳压芯片AMS1117的输出能力虽然标称1A，但如果从核心板的USB口取电，电流很容易被其他外设分掉。

解决办法有两个：一是单独给ESP8266供电，用一个单独的3.3V稳压芯片，输入直接从5V充电器取电；二是在ESP8266的VCC和GND之间加一个470uF的电解电容做储能缓冲。我两个方法都用了，掉线问题基本消失。你要记住：Wi-Fi模块对电源纹波和瞬态响应非常敏感，这几乎是所有物联网项目中第一个要排查的硬件问题。

4.2 HX711数据漂移严重

前面提到过电机启动瞬间电源干扰会导致称重数据漂移。这里还有个容易被忽略的点：HX711的分辨率非常高，24位ADC跟踪的是微伏级别信号，所以不仅仅是电机，任何附近的大电流切换都可能造成干扰。解决办法除了电源去耦，还可以把信号线用双绞线或者是屏蔽线连接，尽量缩短压力传感器和HX711模块之间的距离。

另一个常见问题是长时间运行后的温度漂移。压力传感器是应变片式的，温度变化会引起电阻变化，导致零点漂移。网站上的很多教程忽略了这个现象，但实际测试中，从早上8点开机到下午4点，我空载读数从820000漂到了817000，相当于零点漂了约10克。对余粮监测来说，10克误差勉强能接受，但如果你的猫粮颗粒比较大，一颗就3克，那么零点漂移可能造成误判。所以我在固件里加了自动归零：每次电机完成出粮且系统空闲5秒后，软件采集一次当前读数作为新的零点基准，这样就能抑制大部分温度漂移。

4.3 MQTT收发不同步、指令丢失

这个问题出现在使用AT指令模式时。因为AT指令是串口透传的，当ESP8266收到云端数据后，如果正好赶上STM32向它发送AT+CIPSEND指令修改TCP连接模式，两个数据流就可能交叉。我最初的写法是直接发送指令后延时等待响应，但这样效率很低，而且容易丢数据。

后来我改成“指令-响应-超时检测”的同步机制：向ESP8266发送指令后，立即进入阻塞等待，设置500毫秒超时，如果超时未收到预期响应，就自动重发；如果收到的是云端消息而不是AT响应，就先缓存云端消息，继续等待AT响应。这个机制用FreeRTOS的消息队列实现很容易，每个任务收发各自的消息，互不干扰。

4.4 步进电机堵转和卡粮怎么处理

电机堵转是喂食器必然遇到的问题，诸如粮食颗粒卡在螺旋推进器里、储粮桶出粮口有异物等都可能堵。如果你不做任何保护，电机堵转时电流会急剧上升，ULN2003芯片会过热，时间长了甚至会烧掉驱动板。

保护逻辑其实很简单：步进电机是开环控制，你发出去的脉冲数是知道的，如果电机实际转动步数少于设定步数，你没法直接察觉。但你可以在电机驱动输出引脚上加电流采样电阻，通过ADC检测电流是否超过阈值；或者更简单一点，在SPI通信引脚上连接一个霍尔传感器，检测电机轴是否旋转。但我实测下来最实用的方案还是“时间保护”：正常转完设定步数所需时间是确定的，如果程序执行时间超过预期，就认为发生了堵转，立即停止发送脉冲，同时上报云端“出粮异常”事件。

4.5 一个小技巧：设备端日志输出要分级

调试STM32固件的时候，串口日志是最重要的手段。如果整个程序只有一个printf好难用，我建议你做一个简易日志模块，分三级输出：调试级、信息级、错误级。用宏开关控制，在开发阶段打开调试级输出，所有关键变量的值都打出来；在联调阶段只打印信息级和错误级，避免刷屏；在最终版本可以关掉大部分日志，节省串口资源和Flash空间。

具体做法就是定义三个宏：LOG_DEBUG、LOG_INFO、LOG_ERROR，内部调用printf。通过一个全局变量控制最低输出级别。这样做的好处是，你可以在现场调试时动态改变日志级别，不用重新编译下载。

5. 系统测试与数据记录

系统开发完成后，我做了两轮测试。第一轮是单元测试，主要验证每个模块独立功能是否正常；第二轮是集成测试，把全部模块装进亚克力外壳里跑72小时持续运行测试。

单元测试的数据我记录了几个关键项目：

集成测试中我发现了一个比较意外的问题：储粮桶装满余粮和只剩最后的粮时，出粮量会有些差异。原因是螺旋推进器在粮少的时候进料不充分，会有空转段。解决方案是在固件里对出粮步数做一个动态补偿：称重余粮值低时，自动增加总步数的5%。这是一个比较粗糙的补偿方式，但对实际效果改善很明显。

报警功能的测试也做了一个场景模拟：我在储粮桶里还剩约60克时设置单次喂食20克，系统连续出了三次粮之后，余粮只有约0克，低于设定的15克报警阈值，云端成功推送“缺粮提醒”到小程序，测试通过。这个测试既验证了报警逻辑，也验证了多次连续出粮后的余粮计算准确性。

我还特意记录了一次设备的干净的断电重启过程：重启后系统自动连接Wi-Fi，连接失败就持续重试，直到成功连接到云端后在云端更新“设备在线”状态。整个重连过程大约20秒，符合设计预期。

6. 论文撰写几点建议

毕业设计和单纯的DIY项目不一样，你还需要交付一篇合格的毕业论文。结合我自己和指导老师交流的经验，给出几个针对性的建议。

论文目录建议这样组织：第一章绪论写背景、国内外研究现状、选题意义、主要工作；第二章系统总体设计，画出系统总体架构图、功能模块图，说明需求分析过程；第三章硬件设计，分模块写主控电路、驱动电路、传感器接口电路、电源电路设计；第四章软件设计，分别写STM32固件设计、FreeRTOS任务规划、MQTT通信设计、小程序设计；第五章系统测试，展示测试环境、测试用例表、测试结果截图和分析；第六章总结与展望。如果你最终定稿时字数不够，就在硬件设计和软件设计的细节处多补充技术原理和设计理由，这比堆砌项目背景更有效。

关于画图，我建议所有框图和流程图都用Visio或者drawio画，不要用Word自带画图工具，因为画出来的线条不平滑、格式不统一会被答辩老师扣印象分。系统总体架构图要体现“设备端、云平台、客户端”三层结构，把MQTT协议、HTTP协议标注在链路中间，这张图基本就是论文第六章系统设计的核心。

还有一个容易被忽略的点：论文里的电路原理图不能只是抄模块手册的典型电路，最好能根据你的实际选型说明每个元件的参数计算过程。比如ESP8266的使能引脚为什么需要上拉10K电阻，HX711为什么需要加电源滤波电容，这些细节稍作展开就是几百字的干货内容，也能展示你对电路的理解。

7. 写在最后的一点点经验

做这个项目的过程中，我踩过的坑比你看到的这篇文字可能要多一倍。有一次半夜调试步进电机，电机一直嘎嘎响但就是不转，检查了半天发现是ULN2003的IN1到IN4顺序接反了；还有一次ESP8266怎么都连不上云端，最后发现是AP密码大小写输错了。这些错误都很低级，但正是它们让我把整个系统的每一个环节都理解得非常透彻。

我个人在实际操作中最大的体会是：毕设项目的价值不在于你做得多么花哨，而在于你能否将每一个模块的原理讲清楚、每一个参数为什么这样选能说出来。你只要把喂食器做到“能喂、能看、能提醒、能扩展”这个程度，就已经超出大多数同学的作品了。如果时间允许，后续可以往这几个方向扩展：加一个摄像头模块做宠物状态识别，加一个温湿度传感器检测猫粮储存环境，或者把低功耗模式做出来让设备可以用电池供电更久。这些扩展方向随便挑一个写进论文的展望部分，都是加分项。

最后再分享一个小技巧：设计文章里的实物图、系统运行截图、微信小程序截图最好都整理成一个目录，统一命名，写论文时需要哪张直接复制，比临时翻手机相册省心得多。所有测试数据最好用电子表格记住原始记录并保留截图，答辩时如果被问到“数据来源”，你能现场打开原始数据记录，这比任何口述都更有说服力。