【AIMC 项目】FEB域扩展总线系统介绍

FEB（Field Expansion Bus，域扩展总线） 是一套自研的轻量级嵌入式 IO 扩展与实时同步系统， 由 FEBS 从机（前端扩展板）与 FEBM 主机管理器（Linux 守护进程）两部分组成。 本文面向公开渠道发布，系统性地介绍 FEB 的设计动机、总体架构与主从两端的设计细节。

文档版本：V1.1 适用范围：FEB 总线协议 V1/V2、febmd 1.x、FEBS 固件 1.x

1. 概述

1.1 开发目的

在移动机器人、无人平台与各类智能装备的开发中，主控计算机（通常是运行 Linux 的 SoC 平台，如 RK3588）除了运行核心算法（感知、定位、规划、控制）之外，还需要与 大量”周边”硬件打交道：

• 执行器：继电器、风扇、电源使能、指示灯、电磁阀……
• 传感器：系统温度、母线电压/电流、电池容量、三轴加速度计/陀螺仪、按键与 开关量输入……

如果把这些 IO 全部直接接到主控 SoC 上，会遇到一系列工程问题：

FEB 的核心思路是：把 IO 扩展与采集整体下沉到一块专用从机板（FEBS）， 主控与从机之间只用一条 UART 连线，即可完成全部端口状态的 1kHz 实时同步； 主机侧由一个统一的守护进程（febmd）独占串口并提供并发安全的服务化接口， 业务进程通过本地 IPC 或 HTTP 远程访问，无需关心任何硬件细节。

设计目标与达成指标：

1.2 FEB 主从架构概述

FEB 采用典型的”主从 + 服务化”两级架构：

• 从机（FEBS）：运行在专用的前端扩展板（如 ESP32-S3）上，直接驱动和采集 物理端口，通过 UART 与主机通信，只做一件事——忠实地、周期地交换端口状态；
• 主机（FEBM）：运行在 Linux 主控上，以守护进程 febmd 形式存在，独占串口， 维护与从机镜像的端口状态表，并向所有业务进程提供 IPC / HTTP / 多语言客户端库 三种访问方式。

系统总体架构如图 1 所示：

图 1　FEB 系统总体架构

各组件职责：

端口模型：FEB 把从机上的所有 IO 抽象为 6 类端口，统一编址、统一同步：

同步数据流——一个 1ms 周期内的完整闭环如图 2 所示：

图 2　一个同步周期内的端口数据流（1kHz 闭环）

2. FEB 从机设计细节

2.1 硬件与固件概述

FEBS 从机基于 ESP32-S3 等嵌入式 MCU 平台构建，固件以独立软件模块（SysFebs）形式 集成在从机应用工程中。从机在系统中承担三个角色：

1. 端口物理层：直接驱动继电器/风扇/使能引脚（BO/IO/FO），采集开关量输入（BI） 与模拟量/数字传感器（II/FI，经 ADC、I2C、SPI 等）；
2. 协议应答器：监听 UART 帧，响应主机的配置查询（GetCfg）与周期同步（SyncState）；
3. 数据源：把本地采集到的物理量实时打包为端口值，随 SyncState 响应帧上报。

从机软件分层如图 3 所示：

图 3　FEBS 从机软件分层

2.2 通信帧协议

主从之间采用定制的轻量二进制帧协议，结构固定、解析开销极小，如下所示：

指令码定义：

2.3 自描述配置（GetCfg）

从机上电后并不依赖任何人工配置，而是通过 GetCfg 应答上报一份 JSON 自描述：

{
  "info":  {"type": "skyate_250316", "serial": 1234567890, "proto": 2},
  "BoolPort":  {"Input": 4,  "Output": 7},
  "IntPort":   {"Input": 0,  "Output": 0},
  "FloatPort": {"Input": 16, "Output": 0},
  "ports": [
    {"type": "Bo", "name": "sw0",     "unit": ""},
    {"type": "Bo", "name": "fan",     "unit": ""},
    {"type": "Fi", "name": "sys_temp","unit": "C"},
    {"type": "Fi", "name": "vbus",    "unit": "V"}
  ]
}

要点：

• 设备身份：type（设备型号）与 serial（唯一序列号）使主机可识别与审计接入设备；
• 端口数量：三类端口的输入/输出数量，主机据此动态分配镜像状态表，从机升级 增减端口对主机完全透明；
• 协议版本：proto: 2 表示携带 ports[] 端口元数据（每端口的 name 与 unit）， 主机界面可直接显示 sys_temp (°C) 这样的友好标签；旧版从机（无 proto 字段） 依然兼容，显示退化为 Fi#0 形式；
• 即插即用：主机收到配置后立即进入同步状态，全程无需人工介入。

2.4 高频同步（SyncState）

配对成功后，主机以 1ms 周期发送 SyncState 请求（携带输出数据），从机在同一毫秒内 完成”接收 → 解析 → 驱动输出 → 采集输入 → 应答”的完整闭环，时序如图 4 所示：

图 4　SyncState 1kHz 同步时序

带宽与实时预算（以 1.5 Mbps、BO×7 / BI×4 / FI×16 的典型配置为例）：

波特率选择：16550 类 UART 的波特率来自整数分频，若目标速率不能整除会产生失真， 超过 ±3% 即可能通信失败。FEB 默认采用 1.5 Mbps——在常见 24 MHz UART 时钟下 分频恰为 1（0% 失真），且带宽余量最大；主机侧打开串口时会自动核算实际失真率并在 超限时告警，从机制约协议与主机两侧必须使用一致速率。

2.5 状态表编码

SyncState 帧中的端口数据区（OUT_TAB / IN_TAB）采用紧凑的定长布局：

• Bool 端口（BO/BI）：每端口 1 bit，LSB 在前，按字节打包，字节数 = ⌈数量/8⌉；
• Int 端口（IO/II）：每端口 4 字节，小端序 int32；
• Float 端口（FO/FI）：每端口 4 字节，IEEE 754 单精度，小端序。

以 BO×7、BI×4、FI×16 为例，状态表布局如图 5 所示：

图 5　OUT_TAB / IN_TAB 状态表布局示例

该布局由双方在 GetCfg 配对时根据端口数量独立计算得出，天然一致，无需逐端口 协商；定长帧也让从机端解析可以做到零动态内存分配，满足 MCU 上的确定性要求。

2.6 典型外设接口能力

以实验室车载 FEBS 从机为例，一条 UART 背后聚合的物理接口能力：

3. FEB 主机设计细节

3.1 软件总体结构

febmd 是一个 C11 编写的 Linux 守护进程（约 3000 行，CMake 构建，仅依赖 cJSON 与 libmicrohttpd 两个轻量库），采用”多线程 + 共享数据层”模型，如图 7 所示：

图 6　febmd 线程模型与共享数据层

技术栈选型：

3.2 同步循环（SyncLoop）

SyncLoop 是整个系统的心脏，负责与从机维持 1kHz 的状态同步。其内部是一个三态状态机 （图7）：

图 7　SyncLoop 同步状态机

实时性保障措施：

波特率自检：febmd 打开串口时按 baud_base 核算目标速率的整数分频失真， 失真 > 2% 时升级为 ERROR 日志并给出可整除的候选速率——把”波特率配错”这类 隐性问题在启动阶段就暴露出来，而不是表现为莫名的丢帧。

同步质量统计：每次同步的往返时延（RTT）进入 256 深度滑动窗口，经 HTTP API 暴露成功率、RTT 均值/最大/最小等指标，作为系统健康度的量化依据。

3.3 端口占用与并发安全

FEB 遵循严格的单写者原则：每个输出端口同一时刻只允许一个客户端持有写权限， 从机制上杜绝”两个进程同时抢一个继电器”这类事故。

权限模型：

占用生命周期管理：febmd 维护占用表与”端口 → token”反向索引，完整的申请、 心跳、崩溃回收与再次分配时序如图 8所示：

图 8　端口占用申请、心跳与自动回收时序

自动回收机制覆盖所有异常场景：

写入路径的并发设计——”脏标志 + 暂存区”：

客户端写入只更新暂存区（pending）并置位脏标志（dirty），临界区仅几条赋值语句； SyncLoop 在每个周期开始时批量搬运暂存区 → 输出状态表并清脏标志，然后组装帧发送。 同一周期内同一端口的多次写自然收敛为最后一次值（last-write-wins）， 既保证了数据一致性，又把总线负载降到最低。

3.4 IPC 服务与多语言客户端

IPC 协议：Unix Domain Socket（默认 /var/run/febm/febm.sock，权限 0660）， 请求-响应模式，消息为 Content-Length 头 + JSON 体。IPC 线程用 epoll 管理所有 客户端连接，支持数十个进程并发；连接断开自动释放其名下全部占用令牌。

统一响应结构携带错误码，常用错误码：

客户端库：协议解析全部收敛在 febmd 内，客户端库只是极薄的 IPC 封装—— 这让多语言绑定几乎零成本：

• C（libfebmc）：C 风格 API（febmc_connect / read_port / occupancy_request / write_port / heartbeat ...），内部以 MSG_PEEK 高效解析 Content-Length， 线程安全（多任务可并发调用，库内串行化 IO）；
• Python（febm）：ctypes 绑定 libfebmc，提供 Pythonic 接口——with 上下文 自动连接/释放，Occupancy RAII 对象退出即释放占用，并内置 3s 自动心跳线程， 业务代码无需关心任何保活细节。

from febm import Client, PortType

with Client() as c:                              # 自动连接 + 自动心跳
    temp = c.read_float(PortType.FI, 0)          # 读系统温度（共享读）

    with c.occupancy_request([(PortType.BO, 5)],  # 申请风扇端口占用
                              info="温控风扇") as occ:
        occ.write_bool(PortType.BO, 5, True)      # 开风扇
    # with 退出 / 进程崩溃 → 占用自动释放

并发规模约束：单连接最多同时持有 32 个端口、8 个令牌；febmd 全局最多 64 个客户端——对一台主控上的全部业务进程而言余量充分。

3.5 HTTP 监控与调试

febmd 内嵌 HTTP 服务（默认端口 8765，可选仅绑定回环），提供 Web 状态页与 REST API：

Web 页面 200ms 轮询刷新，开发人员无需任何客户端代码即可总览总线健康度； 调试写入仅供开发环境联调硬件使用——绕过占用是它的价值，独立令牌鉴权与 默认关闭开关则控制其风险。

3.6 可靠性设计

3.7 关键性能指标（实测）

结语

FEB 用”一条 UART + 一个守护进程”解决了嵌入式平台上 IO 扩展的老大难问题： 从机以自描述、零动态内存的固件设计保证了确定性同步；主机以实时调度、占用仲裁 与服务化接口保证了并发安全与工程效率。二者共同构成了实验室各类移动平台 “主控—前端”之间的标准 IO 基础设施。