RETAP 手持天线控制终端项目复盘

这是一个面向电调天线现场维护的手持控制终端，对接 UMTS（3G）基站 Node B 的 Iuant 接口和 RETAP 协议标准。软件部分负责把底层协议能力做成一台可以独立使用的本地工具：扫描总线设备、选择目标天线、执行校准、设置倾角、读取设备信息、从存储卡下发配置和固件。

这个项目不只是做菜单。菜单只是操作入口，软件部分还要把标准协议对接、多设备扫描、地址绑定、文件维护、USB 存储模式和现场反馈串成一套可用流程。

下面是完整的仿真界面总览，覆盖扫描、主菜单、校准、倾角、信息、文件、设置和英文界面。

脱敏说明：本文只保留软件交互、仿真界面和公开标准对接层面的内容。文章不包含客户信息、真实设备型号、私有字段、具体协议帧内容、具体固件文件和源代码实现细节。
天线列表	主菜单
校准确认	校准成功
设置倾角	倾角输入数值
倾角确认弹窗	倾角设置成功
天线信息顶部	天线信息底部
配置文件列表	固件更新列表
其他设置	输出电压设置
语言设置	英文主菜单
英文天线信息界面

一、现场维护功能范围

终端服务现场维护，不以研发调试台为主要使用场景。用户需要拿着设备接上线缆，通过屏幕和按键完成维护动作。

这一部分的重点是把 RETAP 协议能力变成现场可执行动作。现场人员不需要知道协议帧、命令码和连接时序，只需要从菜单里选择目标操作。

二、天线扫描算法

设备扫描是这个项目里比较重要的部分。总线上可能挂着多台设备，终端需要在不知道完整设备编号的情况下发现它们，并给它们分配可通信的短地址。

扫描过程按数字分支逐层尝试：

1. 候选列表先放入最低位的数字分支。
2. 每次取出一个候选，构造一段匹配条件发起扫描。
3. 如果收到有效响应，就把设备加入结果表，并尝试给它分配短地址。
4. 如果出现校验冲突、未知响应或地址绑定失败，说明这个分支下可能有多台设备，需要继续展开下一层。
5. 如果没有响应，这个分支直接剪掉。
6. 候选列表清空后，扫描结束。

这比完整穷举设备编号更适合资源受限的手持终端。终端根据响应结果判断当前分支下是否还有设备，只在必要分支上继续深入。扫描完成后，设备列表会直接变成菜单列表，用户选中某一项后，后续操作都围绕这个目标设备执行。

这套扫描流程也解决了一个现场工具常见问题：发现设备和控制设备不能割裂。扫描只找到编号还不够，终端还要立刻完成地址绑定、连接准备和结果缓存，主菜单才能直接进入校准、倾角、配置、固件这些动作。

三、Iuant 和 RETAP 协议对接

UMTS 基站系统里，Node B 通过 Iuant 接口管理远程电调天线。RETAP 负责承载电调天线相关的远程控制能力，例如设备发现、地址分配、连接、校准、倾角读取、倾角设置、信息读取、配置下发和固件下载。

这个项目做的是一个本地手持维护终端。它不代替基站主设备，定位是现场维护场景下的 Iuant/RETAP 关键控制工具，把标准协议调用包装成本机菜单动作。

项目里把协议处理分成两层：

业务功能只面对应用层动作。比如“设置倾角”不需要关心一帧怎么拼、校验怎么计算、接收缓存怎么清，只需要完成目标设备选择、输入值检查和结果提示。

这个分层避免了把按钮直接接到串口发送里。串口、协议帧、标准服务和 UI 动作之间有清楚分工，后续增加自检、告警读取、清除告警等能力时，可以继续复用同一套调用方式。

四、多级动态菜单

菜单系统做的不只是列出几个静态页面。它用链表或动态容器组织菜单层级，每个菜单节点只保存三类信息：显示内容、节点类型、触发动作。

这种设计带来两个好处：

• 固定功能可以在启动时创建，比如校准、倾角、信息、配置、固件和系统设置。
• 动态内容可以在进入页面前生成，比如扫描出的设备列表、存储卡里的配置文件列表、固件文件列表。

菜单控件按现场操作拆成几类：

渲染路径和执行路径分开。渲染路径只负责标题、列表、高亮、滚动条、数值条、弹窗和加载条；执行路径只负责上移、下移、确认、返回和数字输入。确认键再根据节点类型触发跳转、函数动作、数值编辑或单选切换。

天线扫描这类操作无法瞬间完成，界面会进入加载状态。加载条本质上是一段沿屏幕边框循环的动画：从左上角走到右上角，再拐到右下角、左下角，最后回到左上角。走完一圈后任务未必结束，动画会继续循环播放，用来表示扫描或协议等待仍在进行。

这样做方便扩展。新增一个现场功能，不需要重写整页 UI；新增一个动态列表，也不需要提前写死菜单项。菜单只负责组织操作入口，不接管协议和文件系统的职责。

五、文件系统和 USB 维护入口

文件系统在这个项目里承担现场维护入口。配置文件和固件文件都从存储卡进入终端，菜单只负责把这些文件变成可选择的操作项。

文件链路分成四步：

1. 启动后挂载 FAT 文件系统，保证终端能按普通目录读取文件。
2. 进入配置或固件菜单时扫描目录，把文件名动态生成成菜单列表。
3. 用户确认某个文件后，终端读取文件内容并显示执行状态。
4. 业务层把文件数据交给协议层，由协议层发送给当前选中的设备。

配置下发适合现场批量参数维护。用户把配置文件放进存储卡，终端读取后直接发送给当前目标设备。固件更新的风险更高，所以流程被拆成开始、数据发送、结束三个阶段，终端把这套协议时序包装成一个菜单动作，现场人员只看到“选择文件”和“更新结果”。

USB 维护入口解决的是文件怎么进设备。终端检测到 USB 接入时进入 Mass Storage 存储模式，电脑侧可以像操作 U 盘一样更新存储卡内容；正常控制模式下，USB 不参与协议控制，终端继续作为手持设备工作。

这个双模式设计让维护流程完整起来：

电脑拷贝配置/固件
    ↓
USB 存储模式写入存储卡
    ↓
终端回到控制模式
    ↓
菜单扫描文件列表
    ↓
选择文件并发送到目标设备

文件系统、USB 和协议层各自只做自己的事。文件系统负责组织输入，USB 负责和电脑交换文件，协议层负责把选中的内容发给设备。这样现场更新不依赖烧录器，也不需要把电脑接到协议总线上。

六、多语言界面和实时反馈

终端支持中文和英文界面。多语言没有重新做两套菜单，同一套菜单层级、同一套动作绑定、同一套协议调用复用不同文本资源。语言切换只改变界面文案，不改变业务流程。

这点对现场工具很实用：设备扫描、校准、倾角设置、配置下发、固件更新这些动作在中文和英文界面下保持同样的位置和操作路径，维护人员不会因为语言变化进入另一套流程。

多语言只是本机交互的一部分。这个项目还有多个并行职责：按键扫描、LCD 刷新、LED 提示、蜂鸣器提示、电池电压采样、USB 检测和协议操作。如果全部塞进一个阻塞循环，界面反馈会很差，现场人员很难判断设备是在执行、卡住还是失败。

RTOS 的作用是把这些职责拆开：

按键扫描也做成独立职责。矩阵按键先被周期性扫描和消抖，再转换成统一的按键事件，最后投递给菜单层。菜单层不直接读 GPIO，只消费“上、下、确认、返回、数字”这些语义动作。这样硬件按键抖动、长按节奏和菜单跳转逻辑不会混在一起。

这部分提升的是现场可用性。协议命令可能需要等待，文件发送可能需要持续一段时间，用户界面必须给出明确反馈。终端通过弹窗、进度边框、提示音和状态灯，把底层等待变成用户能理解的操作状态。

弹窗出现前还做了背景模糊动画。这个效果把用户注意力从菜单列表切到当前确认或错误状态，避免误以为高亮菜单仍然可以继续操作。低分辨率单色屏上能用的视觉层次很少，模糊背景、反色弹窗和边框进度条就是主要的信息分层手段。

这里的模糊算法很轻量。单色屏没有灰度层，也不适合做真正的图像卷积，所以做法是对背景区域按棋盘格采样，核心判断只有一行：

x % 2 == y % 2 && x % 2 == 0

这条条件会选中隔点像素，相当于从背景里抽出一半像素点。随后再分几帧把这些采样点做 1 到 2 个像素的小位移，并在每一帧后短暂停留。人眼看到的是背景被打散、抖开、退到后面的效果，前景弹窗再用反色实心块压上去，视觉焦点就自然落在弹窗文字上。这个做法计算量低、显存操作简单，也很适合 MCU 上的单色 LCD。

除了操作成功提示，界面也覆盖了现场常见异常状态，例如低电量和输入范围错误。这些提示虽然只是 UI 层画面，但能避免现场人员把电池、电缆、输入值或协议等待混在一起判断。

七、软件部分交付内容

软件部分最终交付了五类能力：

• 把 RETAP 标准协议产品化：协议对接不只停留在调试函数，最终被包装成现场人员可操作的控制终端。
• 多设备扫描：用分支尝试和响应结果发现多设备，避免直接穷举完整编号。
• 动态菜单：设备列表、配置列表和固件列表都来自运行时数据，服务真实维护流程。
• 文件通道：SD 负责配置和固件输入，USB 存储模式负责文件更新，现场维护路径完整。
• 多语言和 RTOS 保证交互体验：中英文界面复用同一套流程，按键、显示、提示、电量和协议等待各司其职。

这些能力组合在一起，形成的是一台可独立使用的嵌入式手持维护终端。它覆盖 Iuant/RETAP 标准协议对接、底层总线通信、协议分层、设备发现算法、本地 UI、多语言界面、文件系统、USB 维护入口和多任务交互，没有停留在单个菜单 demo 或单个协议 demo。