全志A133P平台RS485配置实战：从设备树修改到硬件调试全解析
在全志A133P平台上配置RS485通信，看似简单的设备树修改背后往往隐藏着硬件与软件协同工作的复杂性。本文将带您深入理解RS485流控机制，并通过UART0、UART3和UART4三个典型实例，展示从原理图分析到最终调试的完整流程。不同于基础教程，我们特别关注那些容易忽略的细节问题——比如Pinctrl配置冲突导致的电平异常，以及如何利用全志特有的调试工具快速定位问题。
1. RS485硬件原理与全志平台特性
RS485通信的核心在于差分信号传输和方向控制。在全志A133P平台上，UART控制器通过RTS（Request To Send）引脚控制收发器的方向切换。当RTS为高电平时，收发器进入发送模式；低电平时则切换为接收模式。这种硬件流控机制需要精确的时序配合：
- 发送阶段：RTS先拉高 → 延迟约1ms → 开始发送数据 → 数据发送完成 → 延迟约1ms → RTS拉低
- 接收阶段：RTS保持低电平，收发器处于高阻态，总线上的其他设备可以正常通信
全志A133P的UART控制器内置了RS485模式支持，通过设备树的rs485-en属性即可启用。但不同UART端口存在关键差异：
| UART端口 | 特性差异 | 典型问题 |
|---|---|---|
| UART0 | 常与蓝牙模块复用 | Pinctrl配置冲突 |
| UART3/4 | 独立GPIO控制 | 电平极性配置错误 |
| UART1/2 | 不支持硬件流控 | 误配置RTS/CTS引脚 |
硬件准备阶段，必须确认以下信息：
- 原理图中RS485收发器的使能引脚连接
- 该引脚对应的主控GPIO编号
- 引脚的有效电平（高电平使能还是低电平使能）
提示：使用万用表测量空闲状态下的RTS引脚电平，正常应为低电平。若为高电平，可能表明驱动未正确加载或存在配置冲突。
2. 设备树配置深度解析
设备树配置是RS485功能正常工作的关键。以UART3为例，标准配置如下：
uart3: uart@05000c00 { compatible = "allwinner,sun8i-uart"; reg = <0x05000c00 0x400>; interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_UART3>; resets = <&ccu RST_BUS_UART3>; dmas = <&dma 14>, <&dma 15>; dma-names = "tx", "rx"; rs485-en = <&pio PD 16 1 1 1 1>; status = "okay"; };其中rs485-en属性的参数解析：
&pio PD 16：使用PD组的第16号GPIO- 五个数字分别表示：默认电平、输出驱动能力、上拉/下拉、输入去抖、输出电平
UART0的配置陷阱在于Pinctrl冲突。当发现PG8电平异常时，需要检查UART1的配置：
/* 错误配置：保留了未使用的RTS/CTS引脚 */ uart1_pins_a: uart1@0 { allwinner,pins = "PG6", "PG7", "PG8", "PG9"; allwinner,function = "uart1"; }; /* 正确配置：仅保留TX/RX引脚 */ uart1_pins_a: uart1@0 { allwinner,pins = "PG6", "PG7"; allwinner,function = "uart1"; };常见设备树错误包括：
- GPIO编号与原理图不符
- 电平极性配置错误（1应为高电平使能，0为低电平使能）
- 未禁用其他控制器对同一GPIO的配置
- DMA配置与RS485模式冲突
3. 全志专用调试工具箱
当配置后通信异常时，系统化调试至关重要。全志平台提供了一系列专用工具：
驱动状态检查：
# 查看驱动加载信息 dmesg | grep uart # 过滤RS485相关调试信息 dmesg | grep rs485GPIO状态监控：
# 查看所有GPIO状态 cat /sys/kernel/debug/gpio # 动态监控特定GPIO（PG8示例） watch -n 0.1 "cat /sys/kernel/debug/gpio | grep gpio-200"手动GPIO控制（通过debugfs）：
mount -t debugfs debug /sys/kernel/debug cd /sys/kernel/debug/sunxi_pinctrl # 将PG8设置为输出模式 echo PG8 > sunxi_pin echo out > function # 拉高GPIO echo 1 > data # 拉低GPIO echo 0 > data物理层验证步骤：
- 使用万用表测量RTS引脚电压（发送时应跳变）
- 检查RS485收发器电源电压（通常5V或3.3V）
- 用示波器观察差分信号波形（A-B线间应有±1.5V以上摆幅）
- 终端电阻匹配检查（120Ω端接电阻）
注意：当软件显示GPIO为低但万用表测量为高时，通常表明存在硬件短路或其他控制器占用该引脚。
4. 典型问题解决方案
问题1：只能发送不能接收
- 检查驱动打印确认RTS切换时序
dmesg | grep -E 'gpio_direction_output|rs485_gpio'- 验证接收端差分电压（应大于±200mV）
- 检查设备树中的电平极性（最后一个数字应为1）
问题2：UART0与其他设备冲突
- 确认PG8是否被其他功能占用
cat /sys/kernel/debug/pinctrl/pio/pinmux-pins | grep PG8- 检查所有使用PG8的设备树节点
- 在uboot阶段验证GPIO状态
# 通过sunxi_gpio命令（需uboot支持） sunxi_gpio set PG8 0问题3：通信距离短/数据错误
- 增加终端电阻（总线两端各接120Ω）
- 降低波特率（长距离建议≤19200bps）
- 检查电缆屏蔽层接地
- 使用示波器检查信号过冲/振铃
问题4：驱动加载但GPIO无反应
- 通过debugfs手动控制GPIO验证硬件通路
- 检查GPIO供电域是否使能
- 测量GPIO对地阻抗（正常应＞1kΩ）
经过这些系统化调试，大多数RS485通信问题都能准确定位。实际项目中，建议在硬件设计阶段就保留测试点，并建立标准的调试流程文档。
