2. 分层架构设计：嵌入式POS机软件分层模型，HAL在其中的位置与边界，接口与实现分离原则

好，咱们接着聊。上一章我讲了HAL到底是个什么东西，这一章咱们把镜头拉远一点，看看整个嵌入式POS机的软件长什么样。说白了，就是一张分层图。

你想想看，一个POS机要干多少事？要读卡、要打印、要联网、要显示、要按键输入……如果所有代码都揉在一起，那改一个地方就可能崩掉一片。我早年在一家小公司就吃过这个亏——改了个串口驱动，结果打印模块也跟着罢工，查了两天才发现是全局变量冲突。从那以后，我对分层这件事就特别较真。

2.1 嵌入式POS机的经典四层模型

我个人习惯把POS机软件分成四层，从上往下看：

  1. 应用层（Application Layer）—— 收银逻辑、交易流程、UI界面
  2. 服务层（Service Layer）—— 文件系统、协议栈、交易中间件
  3. 硬件抽象层（HAL）—— 我们今天的主角
  4. 硬件驱动层（Driver Layer）—— 直接操作寄存器、中断、DMA

嗯，这里要注意：有些架构会把驱动层和HAL合并，但我坚持分开。为什么？因为驱动层是芯片厂商给的，HAL是你自己写的。混在一起的话，换个主控芯片你就得重写整个底层，那还叫抽象吗？

核心观点：HAL是服务层和驱动层之间的“绝缘层”。它不关心业务逻辑，也不关心寄存器怎么配。它只做一件事——提供一组稳定的、与硬件无关的接口。

2.2 HAL的位置与边界

咱们用一张表来理清楚HAL的边界到底在哪：

层级 职责 是否依赖HAL 是否依赖具体硬件
应用层 交易流程、UI交互 否（通过服务层间接调用） 否
服务层 协议解析、文件管理 是 否
HAL 提供统一接口，隐藏硬件差异 — 否（接口层面）
驱动层 操作寄存器、处理中断 否（被HAL调用） 是

你看，服务层只认HAL的接口，它不知道底层用的是STM32还是NXP。驱动层只负责干活，它不知道上层要的是“打印一行字”还是“读取磁道数据”。这就是边界清晰的好处。

我曾经接手过一个项目，前任工程师把LCD的初始化代码直接写在了交易流程里。结果换了个屏幕型号，整个交易流程都得重新测试。你说冤不冤？

2.3 接口与实现分离原则

这个原则说起来就四个字：声明在头文件，实现在C文件。但做起来，很多人会走样。

我举个例子。假设你要抽象一个“打印机”设备：

// printer_hal.h —— 这是接口，上层只能看到这个
#ifndef __PRINTER_HAL_H__
#define __PRINTER_HAL_H__

typedef struct {
    int (*init)(void);
    int (*print_line)(const char *text);
    int (*feed_paper)(int lines);
    int (*get_status)(void);
} PrinterOps_t;

int Printer_Register(PrinterOps_t *ops);
int Printer_PrintLine(const char *text);

#endif

// printer_hal.c —— 这是实现，可以换不同的底层
#include "printer_hal.h"

static PrinterOps_t *g_printer = NULL;

int Printer_Register(PrinterOps_t *ops) {
    if (ops == NULL) return -1;
    g_printer = ops;
    return g_printer->init();
}

int Printer_PrintLine(const char *text) {
    if (g_printer == NULL) return -1;
    return g_printer->print_line(text);
}

看到没？服务层调用 Printer_PrintLine() 时，它根本不知道底层是串口打印机、蓝牙打印机还是热敏打印机。这就是接口与实现分离。

我的一个小技巧：在HAL的头文件里，永远不要出现任何硬件相关的宏定义。比如 #define GPIO_PIN_5 这种，绝对不要出现在HAL层。它应该待在驱动层的头文件里。

2.4 避坑指南：接口设计的三个常见错误

这些年我review过不少HAL代码，发现三个高频问题：

  • 接口太细—— 比如把 SetPinHigh() 和 SetPinLow() 都暴露给上层。其实上层只需要一个 SetPin(int level) 就够了。接口越细，耦合越紧。
  • 接口太粗—— 比如一个 DoTransaction() 函数包揽了读卡、扣款、打印。这等于把业务逻辑塞进了HAL，完全违背了分层初衷。
  • 返回值不统一—— 有的函数返回0表示成功，有的返回1表示成功。我建议统一用 0 = 成功，负数 = 错误码。这个习惯我从做Linux驱动时就养成了。

特别提醒：千万不要在HAL层做“延迟等待”或“超时重试”。这些是服务层该管的事。HAL只负责“发命令、拿结果”，至于结果不对要不要重试，那是上层决策。我曾经见过一个HAL的串口发送函数里自己加了3次重试，结果上层也加了重试，最后变成了9次重试，把整个系统搞慢了。

2.5 小结一下

分层架构设计，说白了就是划清界限。HAL站在服务层和驱动层之间，像是一个翻译官——对上说普通话，对下说方言。只要接口定义得稳，底层换芯片、上层改业务，都不会互相影响。

下一章我会讲HAL的具体接口设计规范，包括命名、参数、错误码这些细节。到时候我会拿一个真实的POS机项目来拆解，咱们看看一个成熟的HAL到底长什么样。

← 上一章 📖 返回目录 下一章 →