海思3516系列芯片SPI速率慢问题深入分析与优化（基于PL022 SPI 控制器）

我在某个海思主控的项目中需要使用SPI接口来驱动一块液晶屏，液晶屏主控为 st7789，分辨率 240x240，图像格式 RGB565。

查阅海思相关手册可知，Hi3516EV200 的 SPI 最高速率为 50MHz，理论上每秒钟可以发送 50M/8=6.25MB 数据。假设我需要在屏幕上以30fps的速率全屏实时显示摄像头的预览画面，每秒的数据量为 240*240*2*30=3456000B=3375KB=3.296MB ，假设 SPI 工作在阻塞模式，则 cpu 使用率为 3.296/6.25*100%=52.7%，看起来还不错。如果我想进一步降低cpu使用率还可以降低预览图分辨率，降低帧率，比如我可以按 240*180 20fps 的规格显示缩略图，那么cpu使用率就可以降到 240*180*2*20/1024/1024/6.25=26.4%。

上面这些都是我在写代码前的理论分析，真实效果当然需要写程序简单测试一下。测试代码内容大致如下：使用原生linux提供的 SPI 接口，即/dev/spidevX.X，主程序中一个死循环没有sleep，使用不同的颜色不停地刷全屏，看一秒钟能达到多少次，也就是刷新率能达到多少帧。

实际测试结果，每秒大约5次！肉眼可见的慢！能很明显看到刷屏的时候是从上到下覆盖过来的！

这么慢的速率就算以240*180的分辨率来刷新预览画面也只能达到7、8帧的水平，何况cpu使用率是100%，其他业务也没办法正常运行，所以spi的速率必须优化。

第一步当然是用逻辑分析仪或示波器抓实际波形，观察是时钟信号没有达到50MHz，还是有其他地方浪费时间。对于逻辑分析仪而言，要考虑采样率是否足够，例如逻辑分析仪的采样率是100MHz，理论上可以采集50MHz的信号，实际采集50MHz的信号很可能采集不准；示波器也一样，示波器需要考虑的是带宽，一般入门级示波器都有100MHz带宽，问题不大。对了，别拿DIY的示波器来捣乱。

这张图就是我通过示波器抓到的海思 SPI 时钟线上的波形，问题非常明显，发送的两个字节之间间隔了 1.656us！开发过任意单片机的spi并实际抓过波形的朋友应该都知道，spi的时钟几乎是连续，正常情况下绝对不可能间隔这么长。

再检查一下spi的时钟有没有达到理论的50MHz，8个clk共计160ns，没问题，达到了理论速率。

题外话：为什么50MHz的方波在示波器上显示为正弦波？因为我这款示波器的带宽只有100MHz，50MHZ方波信号本身没有超过示波器带宽的上限，但是它的2n+1次谐波分量远远高于示波器带宽。所以想要勉强看到50MHz方波的波形，那么示波器至少要能采集到3次谐波信号，也就是150MHz的信号，这就需要一个200MHz带宽的示波器（我买不起！）

简单计算一下，发送一个字节需要 0.16+1.656=1.816us，也就是1秒钟可以发送 1s/1.816us=549450B=536.6KB 的数据，这个数据量甚至不足理论值的十分之一，换算下来确实1秒钟也只能刷5屏。所以接下来的目标就是找出到底是什么原因让发送的两个字节之间占用了足足1.6us。

首先我的发送代码中没有加任何延时函数，所以这1.6us的延时只能来自于linux内核spi驱动。

查看linux内核spi相关源码（提前安装好完整的海思开发环境，并下载对应版本linux内核源码，打海思linux源码patch）
linux-4.9.y\drivers\spi\spi-pl022.c
由源码可知海思的spi使用的是 ARM PrimeCell SSP (PL022) 控制器，这些驱动代码应该非常成熟了，不会存在这么明显的问题，大概看了看源码也没发现啥耗时的地方，之后专门以 ssp-pl022 和 delay 作为关键字google一番也没有发现类似的问题。思索了一下，我决定放弃修改内核驱动，首先内核代码很成熟，基本轮不到我这种小角色去debug，其次每次修改都要重新编译并烧录内核，太麻烦。所以我决定自己重写一个spi内核模块ko驱动。

非常幸运，在海思SDK的 drv.tgz\drv\extdrv\ssp-st7789 中正好有源码，连芯片型号都一样，基于这个代码做一些简单修改就能用。

经过我的一番修改，实际测试下来发现这个ko模块的性能比linux内核spi的性能有一点点提升，延时从1.656us降低到了1.6us以内，基本等于没有优化，这里就不放截图了。

这个代码就比较简单，读起来也不费劲，大概看了一下还是能找到一点优化的地方，注意看spi_write_XXbyte这几个函数，这几个函数内都有这样的代码

spi_enable();
ssp_writew(SSP_DR,spi_data);
ret = hi_spi_check_timeout();
if(ret != 0)
{
    printk("spi_send timeout\n");
}
spi_disable();

在前面的代码中设置过CS片选信号由spi使能信号控制，也就是说，这段代码每次写一个字节都要拉一次CS信号，效率比较低，我将 spi_enable 和 spi_disable 提出来后再次进行测试，速度确实有一定提升，但提升幅度仍然不大，只有大概几百ns的水平，优化效果仍然不理想。

这段代码只剩下两个函数了，ssp_writew 是写寄存器，根本不能优化，只能想办法优化 hi_spi_check_timeout，来看一下这个函数的实现

static int hi_spi_check_timeout(void)
{
    unsigned int value =  0;
    unsigned int tmp = 0;
    while (1)
    {
        ssp_readw(SSP_SR,value);
        if ((value & SPI_SR_TFE) && (!(value & SPI_SR_BSY)))
        {
            break;
        }

        if (tmp++ > MAX_WAIT)
        {
            printk("spi transfer wait timeout!\n");
            return -1;
        }
        udelay(1);
    }
    return 0;
}

逻辑非常简单，不停地读取发送FIFO空和SPI忙的标志位，延时1us继续读，直到发送完成且SPI空闲。看到这个 udelay(1) 你现在的想法肯定和我当时的想法一样：第一次读取发现寄存器没有置位，延时1us，第二次读取寄存器置位，退出循环，现在的发送间隔是1.6us，去掉这个延时尽快读取寄存器，应该直接能优化到0.6us以内。

想得美！实际测试去掉这个 udelay(1) 以后优化效果确实挺明显的，延时直接缩短到 1.2us 左右，但是这个延时还是太长了。

现在再来看这个函数，就剩一个读寄存器了，为了保证可靠传输，读标志位肯定不能去掉，这已经最简单了，还能怎么优化呢？我们重新梳理一下：去掉 udelay(1) 后间隔缩短到 1.2us 左右，说明这里循环读了很多次寄存器，不然怎么还有这么长的延时？那要不就加打印看看这里到底循环读取了几次？来来来，竞猜一下这里到底循环了几次？十次以内？百次以内？还是千次以内？答案是一次！没错只有一次！

1次这个答案可以说即在意料之外也在意料之中。
说它在意料之外是因为读写寄存器这种操作是非常快的，一般而言几个cpu时钟就能完成，但这里读一个寄存器却花费了 1.2us。
说它在意料之内是因为这些物理寄存器都是通过硬件置位的，以发送 FIFO 为空标志为例，当 SPI 发送完成瞬间它就会被硬件置位，这一点在任何一款单片机上都可以验证，实际操作一下就会发现类似的寄存器是瞬间被置位的。pl022 应该是非常成熟的 SPI 控制器，我觉得芯片设计人员不会范发送 FIFO 为空后很长时间才设置标志位这种低级错误。

接下赖重点思考这个问题：为什么 ssp_readw(SSP_SR,value) 这样一个简单的读寄存器操作要 1.2us 之久？
（目前我测试 ssp_writew 写一个寄存器大概在 100ns 以内，ssp_readw 读一个寄存器大概在 1us 左右）
这个问题无论是百度还是谷歌我找了很久都没有找到确切答案，如果有知道的大佬非常欢迎指导！！！不白嫖知识，私信发红包。
下面是我个人的推测，虽然是推测，但我觉得这就是正确答案，仅供参考：

linux 不同于单片机裸机程序那样可以直接访问寄存器，如果需要读写物理寄存器，在内核态使用 ioremap （在用户态使用 mmap）将一段物理地址映射到内核态（或用户态）的虚拟地址空间，再对映射后的地址进行读写。

来看一下实际读写寄存器的这两个接口，很简单就是直接读写某个地址处的数据（前提是这个地址必须经过映射）。

#define  ssp_readw(addr,ret)       (ret =(*(volatile unsigned int *)(addr)))
#define  ssp_writew(addr,value)    ((*(volatile unsigned int *)(addr)) = (value))

首先可以明确一点，读写寄存器的操作必然会经过MMU。
对于写寄存器来说，不需要考虑同步、脏数据等问题，MMU 应该是直接将这个数据写到物理地址了。
对于读寄存器来说，有 volatile 关键字的存在，这里的代码不会去优化，每次读取必须从物理地址进行读取，这里可能需要 cache 回写等操作导致导致读取的速度非常慢。

在 u-boot 下可以直接读写物理寄存器，应该不需要这么久，几个CLK就可以完成吧？这一点我没有验证过，有测试过的朋友欢迎分享。

总之，耗时的地方找到了，想办法优化吧。我这里有两种优化思路：

1. 查阅手册可知，SPI的内部收发部分各有一个宽度 16bit、深度为 256 的 FIFO。我可以一次性写入不超过256字节的数据，然后使用 ssp_readw 不停地读取寄存器，直到发送 FIFO 为空。在50MHz时钟的条件下情况下 ssp_readw 的 1.2us 延时相当于发送了8字节左右，理论上来说如果发送的数据量大于8字节，这个 1.2us 延时等于没有。
2. 每次发送1字节，加适当延时，保证发送相邻两字节之间的间隔尽量短。

目前我采用的就是第二种方法，第一种方法就留给大家验证并开发吧（其实就是我懒）。
来看一下我的现实代码：

void hi_spi_delay(void)
{
    volatile unsigned int tmp = 0;
    while (tmp++ < 30);
}

void spi_write_byte(unsigned char dat)
{
    unsigned short spi_data = 0;
    spi_data = dat;
    ssp_writew(SSP_DR, spi_data);
    hi_spi_delay();
}

这个延迟函数一定要根据编译器、CPU主频、SPI时钟频率等实际测量后进行调整。经过我的反复调整和测量，最终把循环计数设置为了30，来看一下示波器抓到的波形

间隔 65ns，也就是每字节耗时 225us，大约相当于 36MHz 的SPI时钟频率。

改成其他值行不行呢？这是我的测量结果

• 30 可以保证在50MHz时钟下，每两字节之间间隔 65ns，
• 32 可以保证在50MHz时钟下，每两字节之间间隔 80ns，
• 35 可以保证在50MHz时钟下，每两字节之间间隔 100ns，
  但是，重点来了！循环计数小于29或不加延时的间隔是 60ns，似乎达到了某种限制，具体原因没找到，我担心有丢数据的风险，所以将循环计数设置为了30，这个值也正好是可以明显观察到延时函数有效的最小值，SPI 速率虽然没有真正达到理论值，但是对于目前的使用场景来说已经足够了。

前面说了，延时函数一定要根据实际情况进行修改，确保每字节之间有一定间隔。假设你换了海思的另外一款芯片，或者使用了其他基于 ssp-pl022 控制器的芯片，也遇到了类似的 SPI 速率低的问题，但手头没有示波器进行测量怎么办？假设你所使用的芯片提供了精确到10ns的延时函数，直接拿来用就行。没有这样的函数没关系，可以做一个简单的估算，估算结果与实际肯定有偏差，但不管怎么说这个数值也算比较靠谱的。我们来一步一步分析这个延时函数如何实现。

首先是 volatile 关键字，开发调试期间为了方便分析问题，编译优化选项往往设置为 -O0，不论加不加这个关键字都没问题，但正式程序的编译优化选项一般都会设置为-O2，-Os，-O3，这种情况下编译器会直接把这个函数优化掉，所以必须加 volatile 关键字。

确定好你所使用的编译器和编译优化参数，有的芯片厂商会提供多个版本的编译器，或者后来编译器更新了，编译器不同可能会导致代码行为不同，编译优化参数不同也会导致代码行为不同，假设最终发布代码使用-Os，那么测试期间也使用-Os，总之确定好这两点，在之后的开发过程中不要更改。

确定好你的延时函数的循环怎么写，包括但不限于

while (tmp++ < 30);

tmp = 30
while(1) {if(tmp-- == 0){break;}};

tmp = 30
while (tmp--);

for (tmp=0; tmp<30; tmp++);

无论怎么写都能达到延时的作用，有的编译器可能非常聪明，发现循环中什么都没做，最终这4种写法都被优化成了相同的汇编代码，但有的编译器可能不会，总之你不能保证编译器会把他们优化成相同的汇编代码，所以确定了延时函数的写法以后在之后的开发过程中不要更改。

下一步将循环计数设置为比较大的数，例如十万，一百万，执行这个函数并计算耗时，不论是用秒表，还是用 gettimeofday，或者是 time 命令，总之最终目的是算出1个循环耗时多少。假设我测量出循环百万次耗时5.3ms，那么循环一次耗时就是5.3ns。向上取整按一次循环耗时6ns计算，为什么这样做？自己想。

假设 SPI 的时钟速率是50MHz，发送数据位宽是 8bit，则发送1次耗时 1s / 50MHz * 8 = 160ns，延时循环的次数为 160 / 6 = 26.6，向上取整为27次。考虑到函数调用的耗时、读写寄存器的耗时等，实际两次发送之间的间隔肯定比它略长，但无论怎么说，27 就是我们估算出来的延时循环计数。

当然还有更靠谱一点的估算方法。目前我的延时函数及对应的汇编代码如下：

void hi_spi_delay(void)
{
    volatile unsigned int tmp = 0;
    while (tmp++ < 30);
}

Dump of assembler code for function hi_spi_delay:
   0x00010454 <+0>:  mov r3, #0
   0x00010458 <+4>:  sub sp, sp, #8
   0x0001045c <+8>:  str r3, [sp, #4]
   0x00010460 <+12>: ldr r3, [sp, #4]
   0x00010464 <+16>: cmp r3, #29
   0x00010468 <+20>: add r3, r3, #1
   0x0001046c <+24>: str r3, [sp, #4]
   0x00010470 <+28>: bls 0x10460 <hi_spi_delay+12>
   0x00010474 <+32>: add sp, sp, #8
   0x00010478 <+36>: bx  lr
End of assembler dump.

循环体对应的就是这5句

   0x00010460 <+12>: ldr r3, [sp, #4]
   0x00010464 <+16>: cmp r3, #29
   0x00010468 <+20>: add r3, r3, #1
   0x0001046c <+24>: str r3, [sp, #4]
   0x00010470 <+28>: bls 0x10460 <hi_spi_delay+12>

我所使用的芯片采用Cortex-A7架构，我实在没找到它的指令周期的文档，这里用Cortex-A9的替代一下，ARM官网文档如下 https://developer.arm.com/documentation/ddi0388/f/Instruction-Cycle-Timings?lang=en ，跳转指令的周期是不确定的，其他4个指令的都是单周期指令，循环中大多情况都是跳转，只有最后一次是不跳转，我们也按单周期计算好了。由此可知，循环一次需要5个周期，CPU的主频是900MHz，假设CPU主频固定，不超频，也不降频进入低功耗模式，那么循环一次耗时 1s / 900MHz * 5 = 5.55ns，这可以说是一个很精确的值了，同样的条件下可以算出需要的循环次数为 160 / 5.55 = 28.8，向上取整为29次。是不是和我目前使用的循环计数30基本一致？

好了，到此为止开发过程中遇到的问题还有我自己的疑惑都讲完了，有问题欢迎大家讨论。

如果你有朋友正好在海思工作，请将本文转发给他，我不知道海思其他产品线的芯片会不会也有这个问题。我这样写的代码多少有些随意，希望海思官方能优化一下 SPI 的速率问题。