Linux 3.10内核下CH432T SPI转串口驱动调试与性能优化实践

关注

原创 2026-03-10 00:56:18 208 阅读 AI 写同款· GEO 优化 ›

保姆级教程：在Linux 3.10内核下为CH432T SPI转串口芯片编写稳定驱动（附FIFO配置避坑点）本文提供在Linux 3.10内核下为CH432T SPI转串口芯片开发稳定驱动的详细教程，涵盖SPI配置、寄存器操作和FIFO性能优化等关键点。特别针对FIFO配置中的常见问题进行深入分析，帮助开发者避开调试陷阱，实现高效稳定的串口通信。阅读详情

1. 从一次数据丢失的“灵异事件”说起

大家好，我是老李，一个在嵌入式坑里摸爬滚打了十来年的老码农。最近在做一个基于国产龙芯2K1000处理器的工控项目，主控跑的是Linux 3.10内核。为了扩展串口，我们选用了沁恒的CH432T这颗SPI转4串口的芯片。方案听起来挺成熟，芯片资料也齐全，本以为驱动移植就是调调时序、改改设备树的事儿，结果一上电测试，问题就来了：串口接收数据，时不时就丢几个字节，而且丢得毫无规律，像极了“灵异事件”。

项目工期紧，现场调试的兄弟急得直挠头。数据丢失在工业控制里可是大忌，一个指令没收到，可能就意味着一次误动作。我接手后，第一反应就是祭出逻辑分析仪和示波器，准备跟这个“灵异事件”死磕到底。这篇文章，就是我这次调试CH432T驱动，从问题定位、理论分析到最终性能优化的完整实战记录。我会尽量把涉及到的Linux内核驱动知识、SPI协议细节和芯片寄存器操作讲得通俗些，哪怕你之前没怎么接触过驱动开发，也能跟着我的思路，一起把这个问题“盘”明白。我们的目标很简单：让CH432T在Linux 3.10内核下，跑得既稳定又高效。

2. 认识我们的“主角”：CH432T芯片与SPI协议

在动手调试之前，我们得先摸清手里这颗芯片的“脾气”。CH432T本质上是一个桥接芯片，它的核心任务是把主控（比如我们的龙芯2K1000）通过SPI总线发过来的指令和数据，“翻译”成标准的UART串口信号发出去，同时也把从串口收到的数据，通过SPI总线打包回传给主控。所以，整个通信的基石，就是SPI协议。

2.1 SPI配置：模式与片选是关键

SPI协议有四个模式，区别在于时钟极性（CPOL）和时钟相位（CPHA）。根据CH432T的数据手册，它支持MODE 0（CPOL=0， CPHA=0）和MODE 3（CPOL=1， CPHA=1）。我实测下来，两种模式都可以工作，但为了和主控端最常见的配置保持一致，我选择了MODE 0。这里有个小坑要注意：有些主控的SPI控制器驱动在设备树里配置模式时，可能会用不同的数值表示，一定要核对清楚，最好用逻辑分析仪抓一下时钟和数据线的实际波形，确保相位匹配。

另一个关键点是片选（CS）。CH432T的SPI片选是低电平有效。在Linux的SPI驱动框架里，片选通常由内核的SPI核心和控制器驱动自动管理。我们在设备树里定义好这个SPI设备后，每次发起传输，内核会自动拉低对应的片选线，传输完成后再拉高。这个机制对我们后续分析问题很重要，因为不恰当的传输节奏会导致片选频繁启停，影响效率。

2.2 CH432T的SPI通信“暗语”

和CH432T通信，不是简单地把串口数据扔到SPI总线上就行。它定义了一套简单的“暗语”协议。每次SPI传输，至少是4个字节：

第一个字节是地址/命令码：这个字节的高6位指定你要操作的寄存器地址（比如发送保持寄存器THR是0x00，线路状态寄存器LSR是0x05），最低位（bit 0）指定读写方向：1表示写，0表示读。注意，很多SPI设备是MSB（最高位）先传，CH432T也是如此。
后续字节是数据：如果是写操作，主机就在地址码后面跟上一个字节的要写入的数据；如果是读操作，CH432T会在主机发出地址码后的下一个字节，返回指定寄存器的值。

举个例子，我想查询线路状态寄存器（LSR，地址0x05）的值，看看有没有数据收到。那么我需要发起一次SPI读传输：主机先发送一个字节 0x05 << 2 | 0x00 （即0x14，因为bit0=0是读），然后主机再发送一个虚拟字节（比如0x00）来产生时钟，同时CH432T会利用这个时钟把LSR寄存器的值送出来。所以，哪怕你只是想读取一个字节的寄存器，SPI总线上也至少是2个字节的交互。理解这个“开销”，对后续计算时序和性能瓶颈至关重要。

3. 深入CH432T的寄存器世界

驱动芯片，其实就是和它的寄存器打交道。CH432T的寄存器模型和经典的16C550系列UART兼容，这对我们写驱动是好事，因为Linux内核里已经有非常成熟的串口核心（drivers/tty/serial/8250）框架可以借用。我们需要实现的，主要是一个通过SPI去读写这些寄存器的“桥梁”。下面我挑几个在调试数据丢失问题时最关键的核心寄存器，给大家掰开揉碎了讲。

3.1 数据进出的大门：RBR与THR

RBR（接收缓冲寄存器）：这是串口数据流入的入口。当串口线上收到一个完整的字节后，数据会先放到这里（如果禁用了FIFO），或者放到接收FIFO里。驱动需要定期（比如通过中断）来读取这个寄存器，把数据“搬”到Linux内核的tty缓冲区里。判断有没有数据可读，要看LSR寄存器的DATARDY位。

THR（发送保持寄存器）：这是数据流出的出口。当应用程序通过write系统调用发送串口数据时，驱动最终要把数据写入这个寄存器。如果禁用了FIFO，一次只能写一个字节，并且要等前一个字节完全从串口线上发出去（THR空）才能写下一个，效率很低。所以，开启FIFO是提升性能的关键。

3.2 性能加速器：FCR（FIFO控制寄存器）

这个寄存器是解决我们数据丢失问题的核心。它控制着发送和接收两个FIFO（先入先出队列）。

FIFOEN位：必须置1！开启后，发送和接收FIFO深度都是16字节。这意味着，发送时我们可以一次性给THR写入最多16个字节，CH432T会自己排队慢慢发；接收时，串口线上连续来的16个字节也会被缓存在FIFO里，等待主控来读取。这给了我们一个宝贵的“时间缓冲窗口”。
RECVTG1/RECVTG0位：设置接收FIFO的“中断触发点”。比如设置为01，表示当接收FIFO里存够4个字节时，才触发“接收数据可用”中断。这能有效减少中断次数，降低CPU负担。但在我们数据丢失的场景下，这个值需要谨慎设置，设得太高可能导致数据在FIFO里存满了还没触发中断，反而增加溢出风险。我最初就设成了11（14字节触发），后来证明这是导致问题的一个因素。
RFIFORST和TFIFORST位：分别用于清空接收和发送FIFO。在驱动初始化或出现错误时，记得清空一下，避免残留数据干扰。

3.3 状态侦察兵：LSR（线路状态寄存器）

这个寄存器是驱动了解串口实时状态的眼睛。我们主要关心几位：

DATARDY：为1表示接收FIFO里有数据。这是轮询方式下判断是否需要读取数据的依据。
THRE：为1表示发送保持寄存器（或发送FIFO）为空。可以写入新的发送数据了。
OVERR：这是重点！ 为1表示接收FIFO溢出了！也就是说，数据来的太快，FIFO满了，主控还没读完，新来的数据就把旧数据覆盖了。一旦看到这位被置1，就可以确定发生了数据丢失。
TEMT：为1表示发送移位寄存器TSR也空了，即一个字节完全发到了串口线上。

在调试时，我养成了一个习惯：在中断服务程序或者轮询函数里，不仅读数据，还会把LSR寄存器的值打印出来（用printk），这样能清晰地看到状态变化，快速定位是“没数据来”（DATARDY一直为0）还是“数据来了没来得及读”（OVERR突然变1）。

3.4 速度调节阀：DLL/DLM（波特率除数锁存器）

这对寄存器决定了串口的通信速率。计算公式手册上给了：除数 = 基准时钟 / 16 / 目标波特率。CH432T内部基准时钟通常是1.8432MHz或7.3728MHz。假设我们使用1.8432MHz时钟，想要115200的波特率，那么除数 = 1843200 / 16 / 115200 = 1。也就是说，需要向DLL写入1，DLM写入0。这里要注意DLAB位（在LCR寄存器里）。在读写DLL/DLM之前，必须先把DLAB置1；读写完，再把它清0，才能去访问RBR/THR等数据寄存器。这个顺序搞错，配置就会失败。

4. 数据丢失的“元凶”分析与定位

理论准备就绪，回到我们开头那个“灵异事件”。数据丢失，无外乎几个原因：1）数据根本没发过来；2）数据发过来了，但芯片没收到；3）芯片收到了，但我们的驱动没及时读走，导致溢出。用示波器抓取串口输入信号，确认数据是连续、规整地发过来的，排除原因1和2。那么，焦点就锁定在驱动读取不及时上。

4.1 理论计算：我们的时间窗口有多宽？

这是一个非常关键的定量分析。我们不能光靠感觉，得算一算系统留给我们的反应时间到底有多短。

首先，算算SPI搬运一个字节的成本。 我们的SPI总线时钟是6.25MHz。传输1个bit需要 1 / 6.25e6 = 160纳秒。传输1个字节（8bit）需要 160ns * 8 = 1.28微秒。但是，根据CH432T的SPI协议，我们通过SPI从芯片读取一个字节的串口数据，实际需要完成一次“读寄存器”操作：先发1字节命令（读RBR），再收1字节数据。这至少是 2个字节的SPI传输，耗时 1.28us * 2 = 2.56us。这还只是理想情况，实际Linux的SPI传输还有控制器开销、软件延迟等，用示波器实测下来，完成一次有效的单字节读取，SPI总线占用时间在5微秒左右。如果要连续读16个字节（FIFO深度），这个时间就放大到80微秒左右。

然后，算算串口数据填满FIFO的速度。 串口波特率是115200。假设格式是8位数据、1位停止位、无校验（共10位），那么传输一个字节需要的时间是 10 / 115200 ≈ 86.8微秒。填满整个16字节的接收FIFO需要的时间是 86.8us * 16 ≈ 1.39毫秒。

结论出来了： 串口需要约1.39毫秒送来16个字节，而我们的驱动理论上只需要不到0.1毫秒就能通过SPI把它们全部读走。时间窗口看起来非常充裕，那为什么还会溢出呢？问题肯定不在“读”本身的速度，而在于“读”这个动作能否被及时执行。

4.2 实测波形：揭开“总线霸凌”的真相

理论计算和实际表现对不上，这时候就必须请出示波器了。我同时抓取了三个信号：串口接收数据中断引脚（IRQ）的波形、SPI的时钟线（SCLK）和MOSI（主出从入）数据线。

在数据丢失的时刻，我看到了非常能说明问题的波形：

中断信号（IRQ）长时间保持低电平。这说明CH432T一直在断言中断，告诉主控“我有数据，快来读！”。但主控（我们的驱动）没有及时响应，导致中断无法清除。
在中断拉低期间，SPI的时钟线（SCLK）竟然在持续、密集地活动！ 这意味着SPI总线并没有空闲，而是在忙别的事情。

把这两个现象结合起来，真相浮出水面：是发送数据的程序在“霸占”SPI总线，导致接收中断服务程序无法及时获得总线使用权去读取数据！

具体来说，我的驱动最初采用了一种“简单粗暴”的发送方式：应用程序要发送一串数据，驱动就通过SPI一个字节一个字节地往THR寄存器里写。每写一个字节前，都要通过SPI去读一下LSR寄存器的THRE位，判断是否可以写入。在115200波特率下，发送一个字节需要86.8微秒，而查询THRE并写入一个字节的SPI操作可能只需要几微秒。这导致发送线程在短时间内发起了大量、密集的SPI传输。由于SPI总线是共享的、半双工的，在发送线程频繁占用总线进行“查询-写入”操作时，接收中断服务程序（它也需要SPI总线来读RBR）就被完全“堵”在外面，只能眼睁睁看着接收FIFO被新数据填满、溢出。

5. 驱动优化实战：从“轮询霸凌”到“和谐共享”

找到了病根，药方就清晰了：我们必须优化发送逻辑，减少它对SPI总线的“独占”时间，给接收中断处理留出足够的“呼吸窗口”。

5.1 方案一：化整为零，主动让出CPU

最直接的思路是，发送程序不要一次性试图把所有数据塞进FIFO。既然THR的FIFO深度是16字节，我们可以一次只写入一部分，比如14个字节，然后主动暂停一下。在Linux内核驱动中，我们不能用sched_yield()这种用户空间的函数，而是应该使用内核提供的调度机制。一个简单有效的方法是使用cond_resched()或sched_timeout()。

我修改了发送函数 ch432t_serial_tx_chars 的关键部分：

static void ch432t_serial_tx_chars(struct uart_port *port)
{
    struct ch432t_port *up = (struct ch432t_port *)port;
    int count = 0;
    unsigned char lsr;

    /* 1. 先检查THRE位，判断FIFO是否有空间 */
    lsr = ch432t_spi_read_reg(up, CH432_REG_LSR);
    if (!(lsr & CH432_LSR_THRE)) {
        /* THRE为0，表示FIFO满，无法写入，直接返回 */
        return;
    }

    /* 2. 计算当前可写入的最大字节数（不超过FIFO深度，这里保守点用14） */
    count = up->port.fifosize - 2; // 留一点余量
    if (count > CIRC_CNT_TO_END(up->xmit.head, up->xmit.tail, UART_XMIT_SIZE))
        count = CIRC_CNT_TO_END(up->xmit.head, up->xmit.tail, UART_XMIT_SIZE);

    /* 3. 分批写入，每写一批，检查一下并可能让出CPU */
    while (count > 0) {
        int batch = min(count, 14); // 每批最多写14个
        unsigned char buf[32]; // SPI传输缓冲区
        int i;

        /* 准备SPI写THR的命令和数据 */
        buf[0] = (CH432_REG_THR << 2) | 0x01; // 写命令
        for (i = 0; i < batch; i++) {
            buf[i + 1] = up->xmit.buf[up->xmit.tail];
            uart_xmit_advance(&up->port, 1);
        }

        /* 执行SPI批量写入 */
        ch432t_spi_write_buf(up, buf, batch + 1);

        count -= batch;

        /* 关键优化：每写完一批（或达到一定次数），调用cond_resched() */
        if (count > 0) {
            cond_resched(); // 主动让出CPU，给其他任务（包括接收中断）运行机会
            /* 再次检查THRE，因为让出CPU后，FIFO可能又被硬件消耗了一些空间 */
            lsr = ch432t_spi_read_reg(up, CH432_REG_LSR);
            if (!(lsr & CH432_LSR_THRE)) {
                break; // FIFO又满了，退出循环
            }
        }
    }

    /* ... 后续处理，如判断发送缓冲区是否为空，设置状态等 ... */
}

这个修改的核心是 cond_resched()。它会让当前线程自愿放弃CPU，调度器会去运行其他就绪的线程，其中就很可能包括正在等待处理的串口接收中断下半部（或者负责读取数据的任务）。这样，SPI总线就不会被发送线程长时间霸占，接收端有了及时读取数据的机会。

5.2 方案二：变“轮询”为“中断驱动”

方案一虽然有效，但本质上还是轮询（polling）THRE位。更优雅、更节省CPU资源的方式是采用中断驱动的发送。

CH432T在发送保持寄存器空（THRE）时也会产生中断。我们可以这样设计：

初始化时，使能THRE中断。
当应用程序调用write时，驱动先将数据存入内核的环形缓冲区（xmit），然后尝试写入第一批数据到THR（最多16字节），接着立即返回。剩下的数据留在环形缓冲区里。
当CH432T的发送FIFO空到触发阈值（THRE中断产生），中断服务程序被调用。在中断处理中，我们从环形缓冲区里再取出下一批数据（最多16字节）写入THR。
重复步骤3，直到环形缓冲区清空，然后关闭THRE中断。

这样，发送过程完全由硬件事件（FIFO空）驱动，CPU只在需要填充数据时才操作SPI总线，极大地减少了总线占用。同时，由于中断是异步的，接收中断完全有机会在发送中断的间隙得到处理。

实现这个方案需要修改驱动的中断处理函数（ch432t_serial_isr），同时处理接收中断（LSR的DATARDY或接收超时）和发送中断（IIR的THRE）。中断服务程序要尽可能快，通常只做必要的寄存器读写，把耗时的数据搬运工作放到tasklet或工作队列（workqueue）中。

5.3 方案三：调整FIFO触发阈值与读取策略

除了优化发送，接收端也可以微调。回顾FCR寄存器的RECVTG1/RECVTG0位，它决定了接收FIFO有多少数据时才触发中断。在数据流稳定、但单次数据包较大的场景，可以适当提高这个阈值（比如设为8或14），以减少中断频率。但在数据流可能突发、且对实时性要求高的场景（比如我们的工控指令），较低的阈值（如1或4）能确保数据一到就尽快通知CPU，虽然中断多了，但响应更及时，结合优化的发送逻辑，可以避免溢出。

在中断服务程序中，读取数据时也不要一次只读一个字节。应该像下面这样，一次性把FIFO里当前所有的数据都读出来：

static irqreturn_t ch432t_serial_isr(int irq, void *dev_id)
{
    ...
    lsr = ch432t_spi_read_reg(up, CH432_REG_LSR);
    while (lsr & CH432_LSR_DATARDY) {
        /* 批量读取，假设一次最多读16字节 */
        unsigned char buf[32];
        int i, max_read = 16;
        buf[0] = (CH432_REG_RBR << 2) | 0x00; // 读RBR命令
        /* 发起一次SPI传输，连续读取多个字节。这需要驱动支持连续读模式。
           如果芯片不支持连续地址自增读，则需要循环单字节读。 */
        ch432t_spi_read_buf(up, buf, max_read + 1); // 结果会从buf[1]开始
        for (i = 0; i < max_read; i++) {
            uart_insert_char(port, 0, 0, buf[i+1], TTY_NORMAL);
        }
        /* 再次检查LSR，因为读取过程中可能又来了新数据 */
        lsr = ch432t_spi_read_reg(up, CH432_REG_LSR);
    }
    ...
}

6. 优化后的效果与深度思考

采用了方案一（cond_resched()主动让权）并结合接收端一次性读取策略后，我重新进行了测试。用示波器抓取的波形发生了根本性变化：串口接收中断信号（IRQ）不再是长时间的低电平，而是变成了一连串均匀、短暂的脉冲。每个脉冲代表一次数据到达和及时处理。SPI总线的活动也变得“稀疏”而有规律，发送和接收的SPI传输交错进行，总线利用率健康。

长时间的压力测试（持续高速收发）也不再出现数据丢失，lsr寄存器中的OVERR溢出标志位始终为0。系统稳定性得到了保障。

这次调试经历让我对Linux驱动开发，特别是涉及共享资源（如SPI总线）的驱动，有了更深的理解。在嵌入式系统中，“快”不是唯一指标，“及时”和“公平”往往更重要。一个驱动模块不能想当然地认为它可以独占某个硬件资源。在非实时或弱实时的Linux内核中，调度器的行为、中断的延迟都会影响最终效果。“示波器+逻辑分析仪”是硬件驱动调试的“天眼”，理论计算告诉你应该怎样，而实际波形告诉你究竟发生了什么。当两者不符时，问题往往就藏在细节之中。

对于CH432T这类通过慢速总线（如SPI）扩展高速外设（如串口）的方案，设计驱动时必须充分考虑总线的通信开销和竞争。核心原则是：尽量减少不必要的总线访问，让每一次访问都高效；并且要为其他需要总线的任务（尤其是高优先级的中断）留出窗口。这不仅仅是CH432T驱动的问题，也是所有类似桥接芯片驱动开发中值得反复琢磨和优化的关键点。