第三章 系统架构设计：硬件架构选型与软件分层
各位工程师朋友，咱们直接进入正题。门禁设备的系统架构设计，说白了就是给设备「搭骨架」。骨架搭得好，后面开发、测试、维护都顺风顺水。骨架搭歪了，后面全是坑。
我个人习惯把架构设计分成三个维度来看：硬件选型、软件分层、通信协议。这三个东西是互相咬合的，不能单独拎出来讲。咱们一个一个拆开说。
3.1 硬件架构选型：MCU vs ARM vs SoC
选硬件平台，我见过太多人一上来就拍脑袋。其实没那么玄乎，核心就三个问题：你要处理多少数据？你要跑多复杂的算法？你的成本预算是多少？
先看一张对比表，心里有个底：
| 维度 | MCU（如STM32） | ARM（如Cortex-A系列） | SoC（如海思、瑞芯微） |
|---|---|---|---|
| 典型主频 | 几十~几百MHz | 几百MHz~1.5GHz | 1GHz+ |
| 内存 | 几十KB~几MB | 几十MB~几百MB | 512MB~几GB |
| 操作系统 | 裸机/RTOS | Linux/Android | Linux/Android |
| 典型应用 | 刷卡门禁、简单密码锁 | 人脸识别门禁（带屏） | 高端人脸机、视频对讲 |
| 成本（批量） | 10~30元 | 50~150元 | 100~400元 |
我的建议是：
- 纯刷卡、密码、指纹（非活体）：MCU 足够。我做过一个项目，用 STM32F103，跑裸机，刷卡响应时间不到 200ms，成本压到 15 块以内。
- 需要人脸识别、带屏幕交互：至少上 ARM Cortex-A 系列。我记得有一次客户非要拿 MCU 跑人脸识别，结果帧率只有 0.5fps，根本没法用。
- 需要视频对讲、多算法并行：直接上 SoC。海思 Hi3516 系列我用了好几年，ISP 处理、NPU 加速都集成好了，省心。
核心原则： 选型不是越高越好，是「够用 + 留 20% 余量」。你想想看，一个刷卡门禁你塞个 SoC 进去，成本翻 10 倍，客户又不傻。
3.2 软件分层架构设计
软件分层，我把它比作「盖楼」。地基不稳，上面装修再漂亮也没用。门禁设备的软件架构，我习惯分四层：
- 硬件抽象层（HAL）：把 GPIO、UART、I2C、SPI 这些外设封装成统一接口。换芯片时，只改这一层。
- 驱动层：专门管读卡器、指纹模块、显示屏、继电器这些外设。每个外设一个驱动文件，互不干扰。
- 业务逻辑层：核心在这里。比如「刷卡后判断权限」「比对指纹」「超时报警」。这一层不关心底层硬件。
- 应用层：UI 交互、网络通信、日志管理。说白了就是用户能直接看到的东西。
为什么要这么分？我举个例子。有一次项目做到一半，客户突然说要换指纹模块。如果驱动层和业务逻辑层混在一起，那得改几百行代码。但分层之后，我只需要换一个驱动文件，业务逻辑层完全不动。嗯，这就是分层的价值。
我的小技巧： 在业务逻辑层和驱动层之间，加一个「设备抽象接口」。比如定义统一的
open()、read()、write()、close() 函数。这样不管后面接什么外设，接口不变。
下面是一个简单的分层代码示例（伪代码）：
// 硬件抽象层 - GPIO 操作
void HAL_GPIO_WritePin(GPIO_TypeDef* port, uint16_t pin, uint8_t state);
// 驱动层 - 继电器控制
void Relay_Open(void) {
HAL_GPIO_WritePin(RELAY_PORT, RELAY_PIN, 1);
}
void Relay_Close(void) {
HAL_GPIO_WritePin(RELAY_PORT, RELAY_PIN, 0);
}
// 业务逻辑层 - 开门决策
void Door_Open_If_Authorized(uint32_t card_id) {
if (Check_Permission(card_id)) {
Relay_Open();
Log_Event("Door opened by card: %d", card_id);
} else {
Log_Event("Access denied for card: %d", card_id);
}
}
// 应用层 - 主循环
void main(void) {
while(1) {
uint32_t card = Read_Card();
if (card != 0) {
Door_Open_If_Authorized(card);
}
}
}
避坑指南： 我曾经在一个项目里，把业务逻辑和驱动写在一个文件里，结果调试时改一个定时器参数，把开门逻辑也带崩了。从那以后，我强制团队分层，谁混着写谁请下午茶。
3.3 通信协议选型：RS485 vs Wiegand vs TCP/IP
通信协议这块，很多新手容易搞混。其实就三种场景：
- 读卡器到控制器：Wiegand 协议是事实标准。26位、34位最常见。优点是简单，缺点是距离短（一般不超过 150 米），而且没有校验。
- 控制器到控制器/到上位机：RS485 是主力。半双工，距离远（1200 米），可以挂多个设备。我习惯用 Modbus 协议封装，稳定可靠。
- 联网型门禁（云端/局域网）：TCP/IP 是标配。现在很多项目直接走 MQTT 或者 HTTP RESTful API。
这里有个常见的坑：Wiegand 协议没有数据校验。我记得有一次在工厂调试，读卡器离控制器 100 米，线缆质量又差，结果读出来的卡号时不时错一位。排查了两天才发现是信号衰减导致位翻转。后来我强制要求：Wiegand 线长超过 50 米，必须加屏蔽线，或者改用 RS485 读卡器。
再来看一张协议对比表：
| 协议 | 传输距离 | 速率 | 节点数 | 典型场景 |
|---|---|---|---|---|
| Wiegand | ≤150米 | 低频 | 1对1 | 读卡器→控制器 |
| RS485 | ≤1200米 | 9.6k~115.2kbps | 最多32个（无中继） | 控制器组网 |
| TCP/IP | 不限（依赖网络） | 10/100Mbps | 理论上无限 | 云端/局域网 |
我的选型建议：
- 如果只是做单体门禁（一个读卡器控制一个门），Wiegand 最省事。
- 如果是多门互锁、楼层控制，RS485 组网是性价比之王。
- 如果需要远程管理、实时监控、云端日志，直接上 TCP/IP。别犹豫。
一个实用的组合方案： 我最近做的项目，读卡器用 Wiegand 接到控制器，控制器之间用 RS485 组网，然后通过一个网关把 RS485 转成 TCP/IP 上云。这样既保证了本地响应速度，又实现了远程管理。成本控制得很好。
好了，硬件选型、软件分层、通信协议，这三个东西是门禁设备架构设计的「铁三角」。你想想看，选对了硬件，分层清晰，协议匹配，后面开发调试至少省一半时间。反过来，任何一个环节出问题，后面都是无底洞。
下一章咱们聊聊具体的硬件电路设计，包括电源、接口保护、EMC 这些实战内容。到时候我会分享一些我在产线上踩过的坑，嗯，都是真金白银换来的教训。