第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,有问题随时交流。