第一章：项目启动与需求分析

各位同学好，我是老张。今天咱们正式开始聊售货机嵌入式软件架构搭建这件事。说实话，做了十几年嵌入式开发，我踩过的坑比走过的路还多。但售货机这个项目，是我觉得特别适合拿来当教学案例的——它麻雀虽小，五脏俱全。

1.1 售货机市场背景

先说说市场。你想想看，现在街边、写字楼、医院里，自动售货机几乎无处不在。我2018年帮一家厂商做方案时，国内售货机保有量才30万台出头。到2023年，这个数字已经翻了三倍不止。

为什么会这样？说白了，人力成本在涨，无人零售在火。售货机从最早的「投币-出货」简单模式，进化到了支持扫码支付、人脸识别、远程补货预警的智能终端。我见过最夸张的一台机器，甚至能根据天气调整饮料价格——下雨天热咖啡打折，你信不信？

嗯，这里要注意：市场大不代表好做。售货机行业有个痛点——稳定性要求极高。机器摆在户外，夏天60度高温，冬天零下20度，还得7×24小时不停机。我在项目中遇到过一台机器，因为电源模块选型失误，夏天直接热保护罢工了。所以，选型这一步，马虎不得。

1.2 嵌入式系统选型

选型这事儿，我个人习惯先列需求，再定方案。售货机的主控芯片，一般有这几个选项：

方案类型	代表芯片	优点	缺点
MCU方案	STM32F4/F7	成本低、实时性好、功耗低	资源有限、UI能力弱
MPU方案	全志V3s、i.MX6ULL	性能强、可跑Linux、UI丰富	成本高、开发复杂
双核方案	MCU+MPU组合	兼顾实时性与功能	通信调试麻烦

我个人建议，如果是做量产产品，首选双核方案。为什么？我解释一下：

• MCU负责底层控制：电机驱动、硬币识别、温度采集。这些任务要求毫秒级响应，Linux做不到。
• MPU负责上层应用：触摸屏UI、支付对接、云平台通信。这些需要生态支持，MCU搞不定。

我在2019年的一个项目中，就用了STM32F407 + 全志V3s的组合。当时有人问我：「为啥不直接用一块高性能芯片搞定？」我的回答是：解耦。底层和上层分开，哪边出问题都不影响另一边。有一次MPU系统死机了，MCU照样能完成基本的投币出货流程——这就是双核方案的价值。

1.3 功能需求定义

功能需求这块，我习惯分两类：基础功能和增值功能。基础功能是「没有就不叫售货机」，增值功能是「有了能加分，没有也能卖」。

基础功能

• 商品识别：支持条码扫描或货道编码，能知道哪个货道放了什么商品。
• 支付模块：硬币、纸币、扫码支付（微信/支付宝），至少支持两种。
• 出货控制：电机驱动、弹簧旋转、掉货检测。嗯，掉货检测这个坑我后面会细讲。
• 找零功能：硬币找零，或者电子找零（退到支付账户）。
• 状态显示：LCD屏显示商品价格、库存、支付二维码。

增值功能

• 远程管理：通过4G/WiFi上报销售数据、库存预警。
• 温度控制：制冷/加热模块，保证饮料口感。
• 语音交互：出货提示音、故障报警语音。
• 广告播放：待机时循环播放视频广告。

1.4 非功能需求定义

非功能需求，说白了就是「机器好不好用、稳不稳、安不安全」。很多新手只盯着功能做，结果产品上市后天天被客户骂。我列几个关键点：

可靠性

• MTBF ≥ 5000小时：平均无故障时间。我见过最差的机器，每三天死机一次，运维成本比机器本身还贵。
• 掉电保护：突然断电时，正在出货的电机必须停止，不能卡死。EEPROM保存当前状态，上电后恢复。
• 看门狗：硬件看门狗+软件看门狗双重保障。我曾经遇到过软件看门狗失效的情况，从那以后我再也不敢只用单层看门狗了。

实时性

• 出货响应 ≤ 2秒：用户扫码支付成功后，2秒内必须开始出货。超过这个时间，用户会以为机器坏了。
• 支付超时 30秒：用户扫码后30秒内未支付，自动取消订单，释放货道锁定。

安全性

• 防破解：固件加密，防止被读取后复制。我见过有人用逻辑分析仪抓取MCU的SPI通信，直接破解了出货指令。
• 数据加密：支付信息必须使用TLS加密传输。明文传输？那是给自己挖坑。
• 物理防撬：机箱门磁检测，非法开门立即报警并上传云端。

1.5 本章小结

好了，第一章的内容就这些。咱们回顾一下重点：

• 售货机市场在快速增长，但稳定性是核心痛点。
• 系统选型推荐双核方案（MCU+MPU），兼顾实时性和功能丰富度。
• 功能需求要分基础功能和增值功能，优先保证基础功能可靠。
• 非功能需求（可靠性、实时性、安全性）必须在项目启动阶段定义清楚。

下一章，咱们会聊系统架构设计——怎么把需求变成一张清晰的架构图。到时候我会分享一个我踩过的坑：分层架构没做好，导致后期改一个功能要动三个模块。嗯，那滋味可不好受。

今天就到这儿。有问题随时交流。

---

公众号:蓝海资料掘金营，微信deep3321