第1章项目概述与需求分析

一、项目概述与需求分析：药盒语音提示的应用场景、功能需求与非功能需求分析、系统架构概览

各位同学，咱们今天正式开始《嵌入式药盒语音提示模块开发》的第一课。

说实话，做嵌入式这么多年，我见过太多项目死在需求分析阶段。有人觉得这步太虚，上来就画板子写代码，结果做到一半发现方向错了。嗯，药盒语音提示这个项目，看似简单，但坑不少。咱们先把地基打牢。

你想想看，一个药盒为什么要会说话？

我最早接触这个需求，是帮一位老同事做的。他父亲有高血压和糖尿病，每天要吃四五种药，时间点还不一样。老人家记性不好，经常漏服或者重复吃。后来他父亲因为一次漏服降压药，差点出事。

所以，药盒语音提示的核心场景，说白了就是三类人：

我记得有一次去养老院做调研，一位阿姨跟我说：「小伙子，我那个药盒要是能喊我一声『该吃药了』，比闹钟管用多了。」这句话我一直记着。

核心场景总结：

功能需求这块，我习惯先列一个「必须做」的清单，再考虑「锦上添花」的。咱们这个项目，核心功能就四个：

另外，还有一些扩展功能，咱们可以放在进阶版本里：

我的经验：功能需求一定要和用户确认。我曾经做过一个项目，加了十几个花哨功能，结果用户只用了最基本的定时提醒。浪费了开发时间，还增加了功耗。

非功能需求，说白了就是「好不好用」的问题。很多工程师只关注功能实现，忽略了这些，结果产品做出来没人用。

非功能需求	说明	我的建议
低功耗	药盒通常用电池供电，不能天天充电。待机电流要控制在微安级。	选MCU时，一定要看它的深度睡眠模式电流。我习惯用STM32L0系列，待机电流不到1μA。
语音清晰度	老人听力可能下降，语音要足够响亮、清晰。不能有杂音。	功放芯片选MAX98357A，输出功率3W，驱动一个小喇叭绰绰有余。
可靠性	不能死机，不能漏提醒。这是医疗相关产品，出问题可能出大事。	加看门狗定时器（WDT），我一般设8秒。如果程序卡死，自动复位。
易用性	按键要大，操作要简单。最好只有一个按钮。	短按确认吃药，长按3秒进入设置模式。这个交互逻辑我测试过很多次。

避坑指南：我曾经在一个项目里忽略了语音音量调节。结果产品做出来，老人嫌声音太大，年轻人又嫌声音太小。后来不得不加了一个电位器做音量调节。所以，音量可调这个功能，从一开始就要考虑进去。

好，咱们来看看整个系统长什么样。我习惯先画一个框图，再分模块去实现。

整个药盒语音提示模块，分为三层：

我选型的时候，一般会这样搭配：

软件架构上，我习惯用「前后台系统」：

为什么不用RTOS？因为功能简单，RTOS反而增加了复杂度和功耗。我做过对比，裸机跑这套逻辑，待机电流能控制在5μA以内，用RTOS至少翻倍。

系统工作流程（简化版）：

系统上电 → 初始化硬件 → 读取Flash中的时间表 → 进入低功耗模式
    ↓
RTC中断唤醒 → 比较当前时间与时间表 → 匹配？→ 播放语音 → 等待按键确认
    ↓ 不匹配
继续低功耗

嗯，这里要注意：语音播放的时候，MCU不能进入低功耗模式。所以播放完要尽快回到睡眠状态。我一般把语音播放放在一个独立的任务里，播放完成后立即让MCU休眠。

这一章咱们把项目的「骨架」搭起来了。你知道了药盒语音提示是给谁用的，需要实现什么功能，以及整个系统怎么分层。

下一章，咱们会深入硬件选型，把每个芯片的datasheet啃一遍。我会告诉你哪些参数是坑，哪些是亮点。

记住一句话：需求分析做得越细，后面开发越顺。别急着动手，先把需求想清楚。

好，今天就到这里。有问题随时在群里问我。