基于STM32与4G Cat.1的智能药盒：硬件选型、低功耗与物联网通信实战

简介：本资源是一套面向嵌入式开发初学者与毕业设计学生的STM32智能医疗终端完整实现方案，聚焦慢性病患者用药依从性与基础生理参数远程监护痛点，适用于家庭护理、独居老人照护及康复管理等实际场景。压缩包共224个文件，98.89MB，涵盖55个C语言源码（.c）与头文件（.h），支撑STM32F10x系列核心驱动、定时器控制、ADC心率采样及I2C通信；38个XML配置与25个Kotlin/Java文件表明配套有Android端远程监控App；另有Keil工程文件（.uvprojx）、调试配置（.dbgconf）、Gradle构建脚本及实操演示mp4视频，形成“硬件固件+移动端+调试验证”闭环。目前已有61人学习下载，提供可直接编译运行的全套代码、模块化硬件接口说明、PPG心率算法逻辑注释及4G数据上传协议实现细节，助力读者快速掌握低功耗传感采集、多任务调度与蜂窝物联网集成关键技术。

1. 项目缘起与核心价值：为什么我们需要一个“会说话”的智能药盒？

几年前，我参与了一个社区养老的调研项目，亲眼目睹了许多独居老人或慢性病患者在按时服药这件事上遇到的困境。记忆衰退导致漏服、错服，突发不适时身边无人知晓，子女在外地干着急却无法及时掌握情况。市面上的一些“智能药盒”，功能往往比较单一，要么只是个带闹钟的盒子，要么需要依赖复杂的Wi-Fi配置，对老年人极不友好。那时我就在想，能不能做一个更“傻瓜”、更“主动”、更“可靠”的设备？它不仅要提醒吃药，还得能“感知”到用户的身体状态，并且在任何情况下都能把关键信息传递出去。

这就是“基于STM32单片机智能药盒”项目的初衷。它不是一个简单的课程设计，而是一个试图解决真实痛点的综合性工程实践。这个项目的核心价值在于，它将本地化的定时提醒、生理指标监测（心率）和远程无线通信（4G）这三个看似独立的功能，通过一个低功耗、高可靠性的微控制器（STM32）整合在了一起，形成了一个闭环的健康管理节点。

想象一下这个场景：一位高血压患者需要每天早晚各服一次药。传统的做法是设两个手机闹钟，但闹钟响了，人可能不在手机旁，或者随手关掉后就忘了。而我们的智能药盒，会在预设时间通过灯光、声音甚至震动（如果集成马达）进行强提醒。如果用户打开药盒取药，设备会记录一次“已服药”事件。更重要的是，设备集成了心率传感器，用户可以在感到不适时或定期进行心率测量。所有这些信息——下一次服药时间、本次是否按时服药、实时心率数据、设备电量等——都会通过内置的4G模块，自动、静默地上传到云端服务器或直接发送到家属的手机上。家属无需任何操作，就能在千里之外了解老人的服药依从性和基本健康状况，一旦发现心率异常或连续漏服，可以立即电话提醒或上门查看。

这个项目的技术栈非常典型，涵盖了嵌入式开发的多个核心领域：STM32的裸机或RTOS编程、传感器数据采集与处理（心率）、定时器与RTC（实时时钟）的精准应用、4G模块的AT指令控制与TCP/IP通信、低功耗设计以及简单的人机交互（按键、显示屏）。对于电子、物联网、生物医学工程等相关专业的同学来说，这是一个绝佳的毕业设计或综合实训课题，因为它要求你从硬件选型、电路设计，一直做到嵌入式软件和简单的云端交互，知识覆盖面广，实战性强。

接下来，我将以这个“4G模块版本”的智能药盒为例，抛开那些笼统的概念，深入到具体的设计思路、硬件选型考量、软件架构的关键细节，以及开发过程中必然会踩到的“坑”。我会尽量还原一个真实的开发决策过程，而不仅仅是罗列代码和原理图。

2. 硬件架构深度拆解：每一颗芯片的选型逻辑

一个稳定的硬件平台是所有功能的基础。这里的选型不是简单的“用STM32F1”，而是需要根据项目需求进行权衡。让我们逐一分析核心模块的选型原因。

2.1 主控MCU：为什么是STM32，以及具体型号的抉择

选择STM32几乎是必然的。其丰富的产品线、完善的生态（HAL库、标准库）、强大的社区支持和性价比，在工业控制和消费电子领域优势明显。对于智能药盒，我们需要关注以下几个关键点：

1. 足够的IO口和通信接口：需要驱动显示屏（SPI/I2C）、连接心率传感器（I2C/ADC）、控制4G模块（至少两个串口，一个用于AT指令，一个用于数据传输）、管理按键和指示灯。STM32F1系列的普通型号（如F103C8T6）基本够用。
2. 实时时钟（RTC）：这是定时提醒功能的基石。STM32内部集成了RTC外设，虽然精度一般（依赖外部32.768kHz晶振），但对于每日提醒级别的应用完全足够。我们需要RTC在系统深度睡眠时依然运行，以极低功耗维持计时。
3. 低功耗特性：药盒大部分时间处于待机状态。STM32的睡眠（Sleep）、停止（Stop）和待机（Standby）模式是实现长续航的关键。我们需要在RTC闹钟中断到来时，能从低功耗模式快速唤醒。F1系列的低功耗模式相对基础，但对于本项目已绰绰有余。如果对功耗有极致要求，可以考虑STM32L系列的低功耗MCU。
4. 成本与封装：作为可能量产的原型，成本必须考虑。F103C8T6（蓝桥杯常用芯片）价格低廉，资源丰富，是入门首选。封装选择LQFP48或LQFP64，便于手工焊接和调试。

我的选择与理由：在这个项目中，我选择了STM32F103C8T6（俗称“蓝桥杯芯片”或“最小系统板核心”）。原因如下：首先，它完全满足上述所有外设需求（3个串口、2个SPI、2个I2C、RTC）。其次，其Flash（64KB）和RAM（20KB）空间，在精心优化代码后，足以容纳整个业务逻辑、通信协议栈和少量数据缓存。最后，它的生态极其庞大，任何问题几乎都能在网上找到答案，极大降低了开发风险。对于更复杂的、可能需要运行轻量级RTOS（如FreeRTOS）以管理多任务（如同时处理显示刷新和网络心跳）的版本，可以考虑资源更丰富的F103RET6或F407系列。

2.2 4G通信模块：Cat.1如何成为物联网项目的“性价比之王”

这是本项目从“本地设备”升级为“物联网设备”的核心。选择4G模块而非Wi-Fi或蓝牙，根本原因在于部署的便捷性与网络的可靠性。药盒可能被放在客厅、卧室，不一定有稳定的Wi-Fi覆盖，配置Wi-Fi对老年人来说也是一道门槛。4G则像手机一样，插上SIM卡就有网，无需配置，信号覆盖广。

在4G模块中，又有Cat.4、Cat.1、NB-IoT等类别。Cat.1模块在本项目中脱颖而出：

• 速率适中：下行10Mbps，上行5Mbps，远超本项目传输心率、状态等小数据包的需求，但比Cat.4成本低。
• 低功耗：相比Cat.4，Cat.1的功耗更低，支持PSM（省电模式）和eDRX（扩展不连续接收），非常适合长时间待机、偶尔上报数据的设备。
• 网络兼容性好：直接兼容现有4G网络，无需运营商单独部署基站，移动性也好于NB-IoT。
• 成本与复杂度平衡：价格比NB-IoT模块略高，但带来了更高的通信可靠性和速率，开发难度与传统的2G模块（已逐步退网）相似，通过AT指令集控制。

具体型号推荐：移远EC200S、合宙Air724UG、中移物联ML302等都是市面上非常成熟的Cat.1模块。它们通常采用LCC封装，板上集成SIM卡座，提供UART串口与MCU通信，支持TCP/IP协议栈。在硬件设计上，需要特别注意模块的供电（通常需要3.8V~4.2V，且瞬时电流可能超过2A，必须使用独立LDO或DC-DC并搭配大电容）和天线接口（预留IPEX座子，使用外置胶棒天线以获取更好信号）。

注意：4G模块的启动和注册网络需要一定时间（可能十几秒），在软件设计中，不能简单地在需要发送数据时才上电初始化模块。通常策略是系统启动后即初始化4G模块并使其保持在联网状态，通过心跳包维持连接，设备进入低功耗模式时，模块也可以进入其自身的PSM模式。

2.3 心率监测传感器：从光电信号到可靠数据的挑战

心率监测是本项目的“增值”功能，旨在提供一种简单的健康自查手段。我们通常采用光电容积脉搏波（PPG）原理的传感器，例如MAX30102或心率模块（集成算法）。

• MAX30102：这是一颗高度集成的传感器芯片，包含红光和红外LED、光电探测器、环境光消除电路等。它的优点是成本低、集成度高，但难点在于算法。它输出的是原始的PPG波形数据，需要MCU进行采样，并通过一系列数字信号处理（滤波、寻峰、计算间隔）来得到心率值。这对于STM32F1的算力是一个挑战，通常需要移植或编写优化的算法。
• 集成算法的心率模块：市面上有很多将PPG传感器和心率计算芯片（如原相的算法）封装在一起模块，例如一些常见的“心率血氧模块”。它们通过I2C或串口直接输出计算好的心率数值。这极大地降低了MCU的负担和开发难度，虽然成本稍高，但稳定性好，出结果快。

我的实战选择：在毕业设计或快速原型开发中，我强烈推荐使用集成算法的心率模块。原因很简单：可靠性优先。自己编写或移植心率算法，会陷入无尽的信号调理和调试中，而项目重点应该是整个系统的联调。使用成品模块，MCU只需通过I2C读取寄存器中的心率值即可，可以将精力集中在如何设计友好的测量交互（如：用户按下“测量键”，屏幕显示“请保持手指静止”，倒计时10秒后显示心率结果并自动上传）上。

2.4 其他关键外围电路设计要点

• 电源管理：整个系统的功耗跨度极大。4G模块发射时可能需要2A电流，而STM32睡眠时仅需微安级。必须采用多路电源设计。例如，主电源用5V/2A的适配器或电池，通过一个DC-DC降压到4V给4G模块，再通过一个LDO降压到3.3V给STM32、传感器和显示屏。在4G模块不工作时，可以MCU通过MOS管切断其供电以实现深度省电。
• 实时时钟（RTC）备份电源：为了保证系统断电后（比如更换电池）时间不丢失，必须为STM32的RTC提供备份电源。通常的做法是焊接一个CR1220或CR2032纽扣电池到VBAT引脚。这是很多初学者容易忽略，导致产品“失忆”的关键一点。
• 人机交互：一个OLED显示屏（SSD1306驱动，I2C接口）是显示时间、药盒状态、心率结果的最佳选择，它功耗低、显示清晰。按键不宜多，3-4个足矣（设置、确认、上、下），按键电路建议采用外部上拉电阻，并软件实现消抖和长按检测。
• 药盒状态检测：如何知道用户打开了药盒？最简单可靠的方法是使用干簧管或霍尔传感器。在药盒盖子上安装磁铁，盒体上安装传感器。盖子闭合时传感器输出一种电平，打开时输出另一种电平。这种方法非接触、寿命长、成本低。

3. 软件系统架构：从裸机轮询到状态机驱动

面对定时、监测、通信、交互等多个任务，如何组织代码是关键。对于资源有限的STM32F1，我不建议一开始就上RTOS（虽然FreeRTOS可以运行），一个清晰的状态机（State Machine）设计往往更直观、可控。

3.1 核心状态机设计

整个设备可以抽象为几个核心状态：

1. 休眠状态（SLEEP）：设备主体功耗最低的状态。只有RTC在工作，等待下一个服药闹钟或用户按键唤醒。4G模块处于PSM模式。
2. 提醒状态（ALERT）：RTC闹钟触发，设备唤醒。屏幕亮起，蜂鸣器响起，指示灯闪烁。此时系统等待用户操作（开盖取药或按键确认）。
3. 交互状态（INTERACT）：用户按下按键，进入设置菜单或启动心率测量。此时系统需要处理按键扫描和显示更新。
4. 通信状态（COMM）：需要上报数据（定时上报、心跳、事件上报如服药或心率）。此时需唤醒或确保4G模块在线，组包并通过TCP发送数据，等待应答。
5. 测量状态（MEASURE）：启动心率传感器，进行一段时间的采样（如10秒），期间屏幕给出提示，采样结束后计算并显示心率，随后自动转入通信状态准备上报。

这些状态之间的转换由事件驱动：定时器事件、外部中断（按键/开盖）、通信完成事件等。在main函数的超级循环中，我们只需要根据当前状态标志位，执行相应的处理函数即可。

// 伪代码示例 int main(void) { Hardware_Init(); // 初始化时钟、GPIO、串口、RTC等 StateMachine_Init(); // 状态机初始化，进入SLEEP状态 while(1) { switch(GetCurrentState()) { case STATE_SLEEP: // 进入低功耗模式，等待中断唤醒 Enter_Stop_Mode(); break; case STATE_ALERT: Handle_Alert(); // 控制声光提醒 Check_User_Feedback(); // 检测是否开盖或按键 break; case STATE_COMM: Handle_Communication(); // 处理4G通信流程 break; // ... 其他状态 } // 处理一些后台任务，如按键扫描（如果未用中断） Key_Scan_Background(); } }

3.2 定时与RTC的精准管理

定时提醒是核心功能，其可靠性取决于RTC。

1. RTC初始化：上电后，首先检查RTC备份寄存器是否已有初始化标志。若无，则重新配置RTC时钟源（通常用外部低速晶振LSE），设置日期和时间。若有，则直接读取，保证断电后时间延续。
2. 闹钟设置：STM32的RTC闹钟可以设置到“秒”级别。我们需要在软件中维护一个服药时间表（例如，每天08:00和20:00）。在每次闹钟触发后，计算下一个最近的服药时间，并重新配置RTC闹钟寄存器。注意，RTC闹钟中断只能设置一个，所以需要动态重设。
3. 误差处理：外部32.768kHz晶振精度有限，日误差可能在几秒到几十秒。对于服药提醒，分钟级别的精度足够。如果要求极高，可以考虑通过4G网络定期从NTP服务器获取时间进行校准。

3.3 4G通信协议与数据流设计

与云端通信，需要一个简单、可靠的协议。不建议直接发送“原始数据”，应设计一个轻量级的应用层协议。

数据包设计示例（JSON格式，易于云端解析）：

{ "device_id": "MEDBOX_001", "timestamp": 1712345678, "type": "event", // 类型：event事件, heartbeat心跳, alert提醒 "event": "medicine_taken", // 事件：medicine_taken已服药, heart_rate_measured心率测量, cover_opened开盖 "data": { "heart_rate": 75, "next_alarm": "20:00", "battery": 85 } }

通信状态机（AT指令流程）： 4G通信过程是典型的“AT指令对话”，必须用状态机来管理，避免在while循环中死等应答。

1. 状态0：上电/复位。发送AT指令检查模块是否就绪。
2. 状态1：注册网络。发送AT+CREG?查询网络注册状态，循环等待直到注册成功。
3. 状态2：激活PDP上下文。发送AT+QIACT=1激活网络连接。
4. 状态3：建立TCP连接。发送AT+QIOPEN指令连接到指定的服务器IP和端口。
5. 状态4：发送数据。连接成功后，使用AT+QISEND发送封装好的JSON数据。
6. 状态5：等待响应/关闭连接。发送后等待服务器回复，根据业务决定是保持连接（用于心跳）还是立即关闭（AT+QICLOSE）以省电。

每一个状态切换都依赖于对模块返回字符串的解析。例如，在状态1，必须解析+CREG: 0,1或,5（表示注册成功）才能跳转到状态2。这里必须做好超时重试和错误处理机制。比如，连续3次激活PDP失败，可能意味着SIM卡欠费或信号极差，此时应记录错误并进入休眠，等待下一次定时唤醒再尝试。

4. 开发实战：那些代码里不会写的“坑”与解决方案

理论设计总是美好的，但实际开发中会遇到各种意想不到的问题。下面分享几个我在此类项目中踩过的典型“坑”。

4.1 电源噪声导致4G模块频繁掉线

现象：设备工作时，4G模块时不时注册失败、TCP连接断开，尤其是在蜂鸣器响起或电机（如果有的化）启动的瞬间。排查：用示波器观察给4G模块供电的4V电源线。发现在大电流负载（如蜂鸣器）动作时，该电源线上出现了大幅度的电压跌落（从4V跌落到3.5V以下）和毛刺。4G模块对电源纹波非常敏感，电压跌落会导致其内部复位或工作异常。解决方案：

1. 物理隔离：为4G模块使用独立的LDO或DC-DC电源芯片，与MCU、马达等电路的电源输入分开。
2. 加强滤波：在4G模块的电源引脚最近处，并联一个大容量（如100μF）的钽电容或电解电容，再并联一个0.1μF的陶瓷电容，用于滤除低频和高频噪声。
3. 优化布局布线：电源走线尽量粗、短，避免形成环路。

4.2 RTC时间跑偏或后备电池失效

现象：设备断电再上电后，时间复位到初始值；或者设备运行一段时间后，时间明显变快或变慢。排查与解决：

1. 后备电池未接或接反：检查VBAT引脚是否正确接入纽扣电池。STM32的VBAT引脚需要接到电池正极，电池负极接地。用万用表测量VBAT引脚电压。
2. LSE晶振不起振：这是最常见的原因。32.768kHz晶振及其负载电容（通常两个6-12pF）对PCB布局和器件参数非常敏感。
   • 对策1：选择质量好的晶振，并严格按照数据手册推荐的负载电容值。
   • 对策2：在PCB布局上，晶振要紧靠芯片引脚，走线短且对称，下方铺地隔离。
   • 对策3：在软件初始化时，增加对RTC时钟源状态的检查。如果检测到LSE启动失败，可以尝试切换到LSI（内部低速时钟）作为应急，虽然精度差，但功能可用，并通过4G网络上报错误日志。
3. 软件配置错误：在初始化RTC时，必须先解锁备份域（PWR_BackupAccessCmd(ENABLE);和RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);），否则无法配置RTC和备份寄存器。

4.3 串口通信中的数据粘包与解析混乱

现象：在解析4G模块返回的AT指令响应时，有时一条完整的响应会被拆分成两次接收，有时多条响应会粘在一起，导致状态机解析失败。解决方案：这是串口异步通信的经典问题。绝不能使用简单的while等待某个字符。

1. 使用空闲中断（Idle Interrupt）：这是STM32串口的高级功能。使能串口空闲中断后，当接收总线上一段时间没有新数据，就会产生中断。在中断服务函数中，可以认为一帧数据接收完毕。这是处理不定长数据最有效的方式。

   // 伪代码示例 (HAL库) __HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE); // 使能空闲中断 HAL_UART_Receive_DMA(&huart1, rx_buffer, BUFFER_SIZE); // 开启DMA接收 // 在空闲中断服务函数中 void USART1_IRQHandler(void) { if(__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(&huart1); // 计算DMA已接收数据长度 received_len = BUFFER_SIZE - __HAL_DMA_GET_COUNTER(&hdma_usart1_rx); // 处理 rx_buffer 中长度为 received_len 的数据 Process_AT_Response(rx_buffer, received_len); // 重新启动DMA接收 HAL_UART_Receive_DMA(&huart1, rx_buffer, BUFFER_SIZE); } }

2. 环形缓冲区（Ring Buffer）：在串口接收中断中，将数据存入一个环形缓冲区。主循环中的状态机解析函数从这个缓冲区里按字节读取并解析。这需要自己实现一个简单的协议，比如判断回车换行符(\r\n)作为一帧的结束。

4.4 低功耗设计与唤醒源的权衡

现象：设备待机电流依然很大，电池续航远低于预期。排查：使用万用表电流档串联在电池回路，逐步排查。

1. 外设未断电：在进入Stop模式前，确保所有未使用的外设时钟和GPIO都已关闭。将不用的GPIO设置为模拟输入模式以降低功耗。确保4G模块已通过MOS管彻底断电或进入了深度睡眠模式。
2. 唤醒源配置不当：Stop模式可以通过外部中断、RTC闹钟等唤醒。如果使能了不必要的唤醒源（如某个未使用的引脚中断），可能会因为干扰导致误唤醒。仔细检查NVIC和EXTI的配置。
3. 调试接口影响：编程调试时，如果SWD（JTAG）接口连接着仿真器，可能会阻止芯片进入最低功耗的Stop模式。测试低功耗时，应拔掉仿真器，通过独立电源供电并测量电流。

5. 从原型到产品：可靠性提升与扩展思考

完成基本功能联调只是第一步，要让这个药盒真正可用，还需要考虑更多。

5.1 数据可靠性与断点续传

4G网络并非永远稳定。在发送数据时，可能会遇到发送失败。

• 本地缓存：在STM32的Flash中开辟一小块区域（注意均衡擦写）作为数据缓存队列。每次需要上报的数据，先存入这个队列，再尝试发送。只有收到服务器明确的成功应答后，才将该条数据从队列中删除。
• 重试机制：发送失败后，不能无限重试。应设计一个退避算法，例如：1分钟后重试，再失败则5分钟后重试，逐渐拉长间隔，避免在无网络情况下快速耗电。
• 重要事件优先：对于“心率异常”这类告警事件，应赋予最高发送优先级，即使需要打断当前的数据包也要立即发送。

5.2 用户交互的容错设计

面对老年用户，交互必须简单、 robust。

• 长按与短按：利用一个按键实现多种功能。例如，短按查看时间/心率，长按3秒进入时间设置。软件消抖和状态判断必须准确。
• 防误触：在提醒状态下，如果只是无意碰到按键，不应取消提醒或进入复杂菜单。可以设计为需要长按确认键才能关闭提醒。
• 视觉与听觉反馈：任何操作都应有明确的反馈。按键有“滴”声，状态切换时屏幕图标有变化。心率测量时，显示一个动态的脉搏动画，让用户知道设备正在工作。

5.3 可能的扩展方向

这个项目框架有很强的可扩展性：

• 多药格管理：将药盒内部设计成多个格子，每个格子对应不同的药片和服药时间。通过多个传感器检测每个格子的开启状态，实现更精细的服药管理。
• 集成更多传感器：加入温度传感器监测药盒存放环境；加入加速度传感器，实现“跌倒检测”功能，并在检测到跌倒时自动通过4G模块发送求助信息。
• 语音交互：集成一个简单的语音合成芯片，在提醒时直接语音播报“该吃降压药了”，对视力不好的用户更友好。
• 太阳能充电：如果采用电池供电，可以在外壳上集成一小块太阳能板，配合充电管理电路，实现近乎永续的续航。

开发这样一个智能药盒项目，最大的收获不是调通了某个模块，而是学会了如何以系统工程的角度去思考问题：从需求定义到硬件选型，从状态机设计到通信协议，从功能实现到可靠性打磨。每一个环节的疏漏都可能导致最终产品的失败。它强迫你在资源（MCU的RAM/Flash、电池电量、成本）和功能之间做出权衡，在理想设计和现实约束中找到平衡点。当你最终看到设备在预设时间准时亮起，心率数据稳定地出现在手机App上时，那种解决真实问题的成就感，是任何虚拟实验都无法比拟的。希望这份详细的拆解，能为你实现自己的“智能药盒”或类似物联网设备，铺平最初的道路。

本文还有配套的精品资源，点击获取