当前位置：首页 > news >正文

迅为iTOP-RK3568开发板RS485踩坑实录：SP3485E驱动修改、设备树配置与boot.img烧写全流程

news 2026/6/1 13:51:42

RK3568开发板RS485驱动深度改造：从设备树配置到内核驱动的完整实践指南

在工业控制、智能家居和自动化设备领域，RS485通信因其抗干扰能力强、传输距离远等优势成为首选方案。当我们使用RK3568这类高性能处理器开发相关产品时，如何正确配置RS485接口往往成为第一个技术挑战。本文将带你深入Linux内核驱动层面，完整解决SP3485E芯片在RK3568平台上的RS485通信问题。

1. RS485通信原理与RK3568硬件分析

RS485与常见的UART通信有着本质区别。它采用差分信号传输，支持半双工通信，这意味着同一时刻只能有一个设备发送数据。这种特性要求我们必须精确控制收发状态的切换时机。

迅为iTOP-RK3568开发板采用的SP3485E芯片是一款3.3V低功耗RS485收发器，其关键特性包括：

最高10Mbps传输速率
1/8单位负载，允许总线上挂载多达256个设备
热插拔保护功能

硬件连接上，SP3485E的DE(Driver Enable)和RE(Receiver Enable)引脚通常连接在一起，由同一个GPIO控制。当GPIO为高电平时，芯片处于发送模式；低电平时则切换为接收模式。

常见问题根源分析：

切换时机不当导致数据截断
延时计算不准确造成总线冲突
驱动层与应用层控制权混乱

2. 设备树配置深度解析

设备树(Device Tree)是现代Linux内核管理硬件资源的基石。对于RS485配置，我们需要重点关注串口节点和相关GPIO设置。

2.1 原始设备树问题定位

迅为开发板默认配置将RS485控制引脚独立定义：

rk_485_ctl: rk-485-ctl { compatible = "topeet,rs485_ctl"; gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&rk_485_gpio>; };

这种配置方式存在明显缺陷：

控制逻辑与应用层耦合度过高
缺乏标准RS485属性支持
无法利用内核原生RS485框架

2.2 优化后的设备树配置

我们应采用Linux标准RS485属性进行重构：

&uart7 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&uart7m1_xfer>; rts-gpio = <&gpio0 22 GPIO_ACTIVE_HIGH>; linux,rs485-enabled-at-boot-time; rs485-rts-delay = <1 1>; /* 前后延时各1ms */ };

关键参数说明：

参数	作用	推荐值
rts-gpio	指定控制引脚	根据原理图确定
linux,rs485-enabled-at-boot-time	启动时启用RS485	必须设置
rs485-rts-delay	发送前后延时	<1 1>~<5 5>

3. 内核驱动改造实战

Linux内核已内置RS485支持框架，我们需要针对RK3568平台进行适配改造。

3.1 serial.h结构体扩展

首先在include/uapi/linux/serial.h中扩展serial_rs485结构体：

struct serial_rs485 { __u32 flags; #define SER_RS485_ENABLED (1 << 0) #define SER_RS485_RTS_ON_SEND (1 << 1) #define SER_RS485_RTS_AFTER_SEND (1 << 2) __u32 delay_rts_before_send; __u32 delay_rts_after_send; __u32 padding[5]; __u32 rts_gpio; // 新增GPIO编号字段 };

3.2 8250_dw.c驱动修改

在RK3568的DW8250驱动中增加GPIO控制逻辑：

#include <linux/gpio.h> #include <linux/of_gpio.h> static int dw8250_probe(struct platform_device *pdev) { /* 原有代码... */ // 获取设备树中定义的GPIO uart.port.rs485.rts_gpio = of_get_named_gpio(p->dev->of_node, "rts-gpio", 0); if(gpio_is_valid(uart.port.rs485.rts_gpio)) { gpio_direction_output(uart.port.rs485.rts_gpio, 0); gpio_set_value(uart.port.rs485.rts_gpio, 0); // 默认接收模式 } /* 原有代码... */ }

3.3 8250_port.c发送控制

最关键的发送流程改造：

static void serial8250_tx_chars(struct uart_8250_port *up) { struct uart_port *port = &up->port; int lsr, i; /* 发送前设置GPIO为高电平 */ if(gpio_is_valid(up->port.rs485.rts_gpio)) { gpio_set_value(up->port.rs485.rts_gpio, 1); udelay(up->port.rs485.delay_rts_before_send * 1000); } /* 原始发送逻辑... */ /* 等待发送完成 */ if(gpio_is_valid(up->port.rs485.rts_gpio)) { for(i = 0; i < 50; i++) { // 超时约150ms lsr = serial_in(up, UART_LSR); if((lsr & UART_LSR_TEMT) == UART_LSR_TEMT) break; mdelay(3); } gpio_set_value(up->port.rs485.rts_gpio, 0); udelay(up->port.rs485.delay_rts_after_send * 1000); } }

4. 编译与验证全流程

4.1 内核编译关键步骤

# 进入内核目录 cd ~/rk356x_linux/kernel # 配置编译选项 make ARCH=arm64 rockchip_defconfig make ARCH=arm64 menuconfig # 确保8250驱动已选 # 编译内核和驱动模块 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 # 生成boot.img ../rkbin/tools/mkkrnlimg arch/arm64/boot/Image ../boot.img

4.2 烧写与测试

使用RKDevTool烧写boot.img后，通过以下命令验证：

# 查看串口信息 dmesg | grep ttyS # 测试RS485通信 stty -F /dev/ttyS7 115200 cs8 -parenb echo "test" > /dev/ttyS7

常见问题排查表：

现象	可能原因	解决方案
无任何响应	GPIO控制未生效	检查设备树gpio编号
发送数据不完整	切换时机过早	增加delay_rts_after_send
接收乱码	总线冲突	检查终端电阻(120Ω)
偶尔通信失败	延时不足	调整前后延时参数

5. 高级优化与生产建议

在实际项目中，我们还需要考虑以下进阶问题：

动态延时调整：根据波特率自动计算最佳延时

void calculate_rs485_delay(struct uart_port *port) { unsigned int bit_time = 1000000 / (port->uartclk / 16); port->rs485.delay_rts_after_send = bit_time * port->frame_size * 2; }