2、系统总体架构设计：硬件架构选型、软件分层、通信协议选择
好，咱们进入第二章。这一章是整个系统的骨架，说白了就是决定「用什么芯片、怎么组织代码、怎么跟外界说话」。我做了这么多年嵌入式，见过太多项目在架构阶段拍脑袋，结果后面改得死去活来。所以这一章，咱们把话说透。
2.1 硬件架构选型：MCU、传感器、执行器
先聊MCU。低功耗灌溉控制器，核心诉求就两个：省电和够用。我个人习惯，首选ARM Cortex-M0+内核的MCU，比如STM32L0系列或者NXP的LPC8xx系列。为什么？因为M0+在低功耗模式下电流能跑到微安级别，而且外设够用——ADC、定时器、UART、I2C，一个不少。
我遇到过有人非要用M4去做灌溉控制，结果功耗压不下来，电池撑不过一个季度。你想想看，一个灌溉控制器，大部分时间都在睡觉，偶尔醒来读个传感器、开个阀门，要那么强的算力干嘛？
传感器这块，我推荐土壤湿度传感器用电容式的，别用电阻式的。电阻式的容易腐蚀，我在项目里吃过这个亏——用了半年，探头锈得一塌糊涂，数据全飘了。电容式的虽然贵一点，但寿命长得多。另外，温度传感器用DS18B20就行，便宜又稳定，一根线就能传数据。
执行器嘛，阀门控制用MOS管驱动电磁阀，别用继电器。继电器有机械触点，频繁开关容易坏，而且吸合瞬间电流大，对电池不友好。MOS管开关无触点，功耗低，我这些年做项目基本都这么干。
核心选型清单（我常用的组合）：
- MCU：STM32L051C8T6（48MHz，64KB Flash，8KB RAM）
- 土壤湿度传感器：电容式，I2C输出（如SHT30）
- 温度传感器：DS18B20，单总线
- 阀门驱动：IRLZ44N N-MOS管，逻辑电平驱动
- 电源管理：TPS63060升降压芯片，支持1.8V-5.5V输入
一个小技巧：MCU的GPIO引脚在休眠前一定要配置成模拟输入模式，别悬空。悬空引脚会有漏电流，我测过，一个引脚能多耗0.5μA，十几个引脚加起来就不少了。
2.2 软件分层设计：别让代码变成一锅粥
软件分层，说白了就是「各司其职」。我见过太多人把所有代码塞进main.c，结果改一个传感器驱动，整个系统都要重新编译。嗯，这种代码我称之为「意大利面条式代码」。
我建议分三层：
- 硬件抽象层（HAL）：直接跟寄存器打交道。比如读ADC、写GPIO、配置定时器。这一层尽量用芯片厂商提供的库，别自己造轮子。
- 驱动层（Driver）：封装具体外设的操作。比如「读土壤湿度传感器」这个函数，内部调用HAL的I2C接口，但对外只返回一个湿度值。这样换传感器时，只需要改这一层。
- 应用层（Application）：业务逻辑。比如「当土壤湿度低于30%且时间在早上6点到8点之间，打开阀门10分钟」。这一层不关心底层硬件，只调用驱动层的接口。
我曾经在一个项目里，因为没分层，换了一个型号的土壤传感器，结果改了7个文件。从那以后，我强制团队必须分层，谁乱写谁请喝咖啡。
注意：分层不是越多越好。三层就够了，搞个五六层，调用链太长，调试起来想哭。我见过有人分了七层，结果一个简单的「读传感器」要经过五个函数指针跳转，查bug查到怀疑人生。
代码结构大概这样：
// 硬件抽象层：读ADC
uint16_t HAL_ADC_Read(ADC_HandleTypeDef* hadc) {
HAL_ADC_Start(hadc);
HAL_ADC_PollForConversion(hadc, 100);
return HAL_ADC_GetValue(hadc);
}
// 驱动层：读土壤湿度
uint8_t DRV_SoilMoisture_Read(void) {
uint16_t adc_val = HAL_ADC_Read(&hadc1);
// 将ADC值映射到0-100%
return (uint8_t)(adc_val * 100 / 4095);
}
// 应用层：灌溉决策
void APP_Irrigation_Control(void) {
uint8_t moisture = DRV_SoilMoisture_Read();
if (moisture < 30 && IS_TIME_IN_WINDOW()) {
DRV_Valve_Open();
HAL_Delay(600000); // 10分钟
DRV_Valve_Close();
}
}
2.3 通信协议选择：怎么跟外界说话
灌溉控制器一般需要跟手机App或者云平台通信。选协议时，我主要看两点：功耗和距离。
如果控制器在院子里，离网关不超过100米，我推荐用蓝牙BLE。BLE的功耗极低，广播状态才几毫安，连接后传输数据时也就十几毫安。而且现在手机都支持BLE，调试方便。我在一个智能花盆项目里就用BLE，两节AA电池撑了八个月。
如果控制器分布在农田里，距离几百米甚至几公里，那就得上LoRa。LoRa的优点是距离远、穿透力强，但缺点是速率低，只能传小数据包。不过灌溉控制嘛，一天传几次传感器数据和阀门状态，够用了。
Wi-Fi？我个人不太推荐。Wi-Fi功耗高，而且需要配网，用户体验不好。你想想看，农民伯伯在田里掏出手机配网，信号还不一定好，多折腾。
| 协议 | 功耗 | 距离 | 速率 | 适用场景 |
|---|---|---|---|---|
| BLE | 低（mA级） | 10-100m | 1Mbps | 庭院、阳台灌溉 |
| LoRa | 极低（μA级待机） | 1-10km | 50kbps | 农田、大范围灌溉 |
| Wi-Fi | 高（百mA级） | 50m | 54Mbps | 不推荐（除非有市电） |
避坑指南：我曾经在一个项目里用了LoRa，结果发现天线没匹配好，通信距离只有标称的十分之一。后来老老实实做了阻抗匹配，又加了SMA接口的外置天线，才解决问题。所以，天线设计千万别马虎，该用网络分析仪就用，别凭感觉。
好了，这一章就聊到这儿。硬件选型、软件分层、通信协议，这三样定下来，系统的骨架就有了。下一章咱们聊具体的电路设计和功耗优化，到时候我会分享一些「血泪教训」。