第1章:系统需求分析——智能窗帘电机的“灵魂三问”
做嵌入式开发这么多年,我养成了一个习惯:拿到一个项目,先别急着画板子、写代码。坐下来,把需求理清楚。你想想看,如果连要做什么都没搞明白,后面再努力也是白搭。
智能窗帘电机,说白了就是一个能听话、会省电、还不吵人的小马达。但要把这三个要求同时做好,还真得花点心思。今天我们就来聊聊它的需求分析。
1.1 功能需求:开、关、停、百分比
功能需求是最基础的。用户想要什么?很简单:
- 开:窗帘完全打开
- 关:窗帘完全关闭
- 停:在任何位置停下来
- 百分比:开到30%、50%、80%……精确控制
嗯,这里要注意。百分比控制看起来简单,但实际做起来有个坑。我在项目中遇到过,用户说“开到50%”,结果电机转过了头,又倒回来一点。那个抖动,用户直接投诉了。
为什么会这样?因为电机有惯性。你让它停,它不会立刻停。所以我们需要一个位置闭环控制。说白了,就是实时检测窗帘的位置,到了目标值就提前减速。
核心要点:百分比控制不是简单的“转多少圈”,而是“怎么平稳地转到那个位置”。
功能需求的用例图,我习惯这样画:
用例:智能窗帘电机
- 用户:开、关、停、设置百分比
- 系统:响应指令、反馈状态、异常报警
你可能会问,就这么简单?其实不然。每个用例背后都有细节。比如“停”,是在任何位置停,还是只能在预设位置停?我建议做成“任意位置可停”,用户体验更好。
3.2 非功能需求:低功耗、低噪音、安全
功能需求是“做什么”,非功能需求是“做得怎么样”。这三个指标,直接决定了产品能不能卖出去。
低功耗
智能窗帘电机通常是电池供电的。你想想看,如果三天两头要充电,用户肯定骂娘。我做过一个项目,客户要求待机电流小于10μA,工作电流小于200mA。当时我们用了STM32L0系列,配合BLE 5.0,才勉强达标。
我的经验:低功耗设计,关键在“睡得好”。让MCU大部分时间处于深度睡眠,只在需要时醒来。我曾经用RTC定时唤醒,每100ms检查一次指令,功耗降了30%。
低噪音
这个我深有体会。有一次客户反馈,晚上窗帘电机的声音像“老鼠叫”。我们连夜分析,发现是齿轮箱的润滑问题。后来改用静音齿轮,噪音从45dB降到了28dB。
低噪音设计,说白了就是三点:
- 电机本身要选低噪音型号
- 齿轮箱要精密配合
- 控制算法要平滑,避免急停急启
安全
安全是底线。智能窗帘电机如果出问题,可能会夹到手,甚至掉下来砸到人。我建议至少做这几项:
- 过流保护:电机堵转时自动断电
- 限位保护:到顶到底自动停止
- 防夹手:遇到阻力立即反转
- 低电量报警:提前通知用户充电
警告:安全功能不能只靠软件。我见过一个项目,软件防夹手逻辑写错了,结果夹到东西不停。后来我们加了硬件限位开关,双重保险。
1.3 状态机:让电机“知道自己在哪”
状态机是嵌入式系统的灵魂。智能窗帘电机,我习惯用5个状态来建模:
| 状态 | 说明 | 触发条件 |
|---|---|---|
| IDLE | 空闲,等待指令 | 上电、停止指令 |
| OPENING | 正在打开 | 开指令、百分比指令 |
| CLOSING | 正在关闭 | 关指令、百分比指令 |
| STOPPED | 中途停止 | 停指令、遇阻 |
| ERROR | 故障状态 | 过流、堵转、通信异常 |
状态机的好处是什么?你想想看,如果没有状态机,你写代码的时候就会到处是if-else,逻辑乱成一团。有了状态机,每个状态做什么、怎么切换,一目了然。
我曾经在一个项目里,因为状态机没设计好,导致电机在“打开”和“关闭”之间来回切换,像抽风一样。后来重新画了状态图,问题就解决了。
避坑指南:状态机设计时,一定要考虑“非法状态转换”。比如,在ERROR状态下,不能直接进入OPENING。必须先复位,进入IDLE,再执行指令。
状态机的代码实现,我习惯用switch-case结构:
typedef enum {
IDLE,
OPENING,
CLOSING,
STOPPED,
ERROR
} MotorState;
MotorState currentState = IDLE;
void motor_task(void) {
switch(currentState) {
case IDLE:
// 等待指令
break;
case OPENING:
// 执行打开动作
break;
case CLOSING:
// 执行关闭动作
break;
case STOPPED:
// 保持位置
break;
case ERROR:
// 故障处理
break;
}
}
嗯,这里要注意。状态机不是写完了就完事了。一定要做状态转换测试。我习惯画一个状态转换表,把每个状态到每个状态的合法性都列出来,然后逐个测试。
小结
这一章我们聊了智能窗帘电机的需求分析。功能需求是基础,非功能需求是竞争力,状态机是骨架。我个人觉得,需求分析阶段多花点时间,后面写代码、调试的时候就能少走弯路。
下一章,我们会聊聊硬件架构设计。到时候我会分享一些选型经验和电路设计技巧。记得关注公众号:蓝海资料掘金营,微信deep3321,有问题随时交流。