YTM32同步串行通信引擎SPI外设详解（slave part）

本文主要是介绍YTM32同步串行通信引擎SPI外设详解（slave part），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

YTM32同步串行通信引擎SPI外设详解（slave part）

文章目录

YTM32同步串行通信引擎SPI外设详解（slave part）
- Introduction
- Pricinple & Mechinism
- - 引脚信号
  - Slave从机工作模式
  - 发送/命令FIFO和接收FIFO
  - Match匹配接收功能
  - 硬件片选和内部的自动片选
- Application Information
- - spi_slave_basic样例工程
  - 预先准备1个数还是2个数？？？
- Conclusion

Introduction

最近接到不少客户的设计需求，需要使用一颗小MCU作为大芯片的扩展引脚芯片，通过通信过程控制小MCU的引脚电平输入和输出，并进一步可能会利用小MCU上的其它片上资源，即所谓的“卫星芯片”。其中，大芯片同卫星芯片的通信接口多选用SPI总线，如此就需要使用MCU的SPI从机（Slave）功能。笔者后续会基于SPI设计一套通信协议，但为了评估和验证SPI引擎的从机功能，在本文以YTM32B1LE05微控制器为例，详解SPI从机的硬件工作机制及使用要点。

Pricinple & Mechinism

引脚信号

无论是工作在master还是slave模式，SPI外设的SOUT都是发送数据的引脚、SIN都是接收数据的引脚。SCK引脚在master模式的数据方向是输出，主动向总线发出时钟信号，在slave模式下的数据方向是输入，被动接收总线上的时钟信号。

当然，如果用户需要使用MOSI/MISO这种接法，SPI外设也提供交换SOUT和SIN信号的配置，见SPI_CTRL[PINCFG]寄存器字段。

Slave从机工作模式

YTM32的SPI外设模块同时实现了主机（Master）和从机（Slave）的功能，但每个SPI外设的实例只能以其中一种方式工作（配置SPI_CTRL[MODE]寄存器位，默认值为0，对应从机模式）。

SPI从机不能主动发起传输，只能同步应答SPI主机的发送过程，但实际SPI传输的发送过程和接收过程是同步进行的，因此SPI从机需要预先向发送FIFO中写入即将要发送的数据，如此，当SPI主机发送数据时，SPI从机可以将预先在发送FIFO中准备好的数据同步回送给主机。否则，若SPI从机移位器向发送FIFO要数，但不可得时，就会产生Underflow错误事件（下溢），对应有SPI_STS[TXUNIF]标志位置位并可产生中断。

SPI通信的节奏完全由主机掌控，由SPI主机产生通信时钟信号，SPI从机从总线上读通信时钟信号，而不是自己产生时钟，对应地，SPI外设的SPI_CLK寄存器在从机模式下也不起作用。

发送/命令FIFO和接收FIFO

从调试SPI主机过程中得到的经验，虽然发送FIFO也承担了命令FIFO的功能，但命令FIFO不会作用于数据流本身，若仅关注数据，则在实用场景中，SPI_TXCFG寄存器可以被当做是一个配置发送参数的寄存器（命令FIFO中的命令字作用于移位器的功能配置项，发送FIFO中的内容作用于移位器的数据内容），而不用考虑其向FIFO中写命令然后生效的机制。但写SPI_TXCFG寄存器时要特别注意：

写SPI_TXCFG寄存器需要在SPI引擎处于Idle状态下才能生效。
SPI_TXCFG[CONTC]寄存器位仍会锁定SPI_TXCFG寄存器高8位置。高8位中有CPOL和CPHA的配置，这两个配置在从机模式下仍然其作用。

SPI外设工作在主机模式时，每当向发送FIFO中写数后，SPI引擎会自动启动发送过程（自动搬数从发送FIFO到发送移位器，在送上总线）。但当工作在从机模式时，软件向发送FIFO写数后，发送FIFO会把数暂存起来，等外部的SPI主机发起传输时，先将总线上收到的数存入接收FIFO，同时将预先写入FIFO的数送上线。

使用接收FIFO的时候，还有一个屏蔽接收的功能。当配置了SPI_TXCFG[MSKRX]=1后，SPI外设的移位器从总线上换下来的数将被抛弃，不会送入接收FIFO。启用这个功能的意义在于，如果确实不需要从接收FIFO中读数，可以避免接收FIFO溢出产生报错事件。

Match匹配接收功能

Match功能作用于接收过程中。虽然Match功能在主机模式下也能工作，但在从机模式下才有实际意义。Match功能会比较接收移位器中接收数据与SPI_MATCH1和SPI_MATCH2寄存器中的数据，仅当收到匹配的数据才会送入接收FIFO。

Match的机制作用在移位器上。确切地说，是移位器到接收FIFO的通路上。
如果配置了SPI_TXCFG[MSKRX]=1，则接收FIFO会拒收一些来自于移位器送入的数，当然也不会触发Match事件。
通过SPI_CTRL[RXMO]启用Match功能，只接收Match数据模式（Receive Data Match Only ）。
在应用上可以配置启用只接收Match数据的功能，当触发Match事件后（收到匹配的数），再配置放开接收FIFO（SPI_TXCFG[MSKRX]=0）可以收数。此时，为了正常捕获后续的数据并存入接收FIFO，需要在此时清SPI_CTRL[RXMO]控制位，关闭仅Match接收功能，并清Match事件的标志位SPI_STS[MATIF]。

有关于Match功能的系统框图，如图x所示。

在这里插入图片描述

图x SPI的Match和Mask功能框图

硬件片选和内部的自动片选

SPI从机需要被片选信号激活（在PCS信号线上拉低），才能启用数据收发过程。当PCS线的片选信号被放开，则SPI从机硬件停止通信过程。常规使用场景中，PCS线上的片选信号线是由外部的SPI主机管控的。但SPI外设可以通过配置SPI_CTRL[AUTOCS]寄存器位，启动SPI模块内部自动产生片选的功能，利用时钟线上的活跃信号自动产生片选信号，送给SPI从机的移位器，从而触发传输过程：

配置SPI_CTRL[AUTOCS]=1，启动SPI模块内部自动产生片选。
必须要设置SPI_TXCFG[CPHA]=1，SPI_TXCFG[CPOL]=1，对应设置时钟线空闲为高电平，在时钟的下降沿采样接收数据（同时触发SPI从机启动先收后发的传输过程）。这类似于UART总线上提取开始信号的模式。

切记，无论使用来自于SPI总线上的硬件片选（真片选），还是利用SPI外设内部自动产生的片选信号（假片选），SPI从机的收发器（移位器）必须由片选信号激活才能启动有效的通信过程。

Application Information

spi_slave_basic样例工程

在样例工程spi_slave_basic中，实现了一个演示使用SPI从机的用例。

main()函数启动后：

初始化SPI外设为slave模式，发送和接收过程均使用轮询操作。
先向发送FIFO中送入0xFF，预先填充一个将要同master交换的数。

在while(1)循环中：

轮询接收来自于master的数，同时由硬件自动送出之前在发送FIFO中存的数。
当收到数后，将刚收到的数送入发送FIFO。这个数将在下次接收master发数的时候换出去。

运行spi_slave_basic样例工程，需要配合一个能够主动发送数据的spi master设备，可以使用另一块运行spi_basic_master样例工程的板子，也可以用专门产生SPI数据信号的工具（例如uart2spi_master样例工程）。同时可以用逻辑分析仪搭在SPI总线的信号线上，观察数据信号。样例正常运行的情况下：

先复位运行spi_slave_basic工程的电路板，再启动spi master的设备。
通过逻辑分析的界面可以看到，spi master接收的数据流，第一个数是0xFF，后续接收的都是前一次发送的数。

使用两块evb-ytm32b1le05-q64开发板运行样例，连线时要注意，板子上的丝印对应的插针信号，如图x所示。

在这里插入图片描述

图x evb-ytm32b1le05-q64开发板的SPI信号

两块板子连线时，一块板子的SIN和对面板子的SOUT的信号对接。

预先准备1个数还是2个数？？？

在实验过程中出现了一个有趣的现象：当连续传输模式时（master在连续发数过程中保持PCS拉低），spi slave回发的数列相对于spi master发来的数总是有两个字节的延后，与预期的实验现象（延后一个字节）不符。如图x所示。图中从机在最开始发出的0x11是软件预先写入从机的发送FIFO的，但后面紧跟的0xFF有些莫名其妙。

在这里插入图片描述

图x 连续传输模式下的传输延后

并且SPI模块的发送FIFO也出现了Underflow的事件。如图x所示。意思是提前喂给发送FIFO的数不够，还得再多喂？

在这里插入图片描述

图x SPI Slave在传输过程中出现Underflow事件

那试试预先给发送FIFO喂两个数0x11、0x22，再试试。有SPI传输波形如图x所示。

在这里插入图片描述

图x 预先填充两个数到SPI Slave的发送FIFO

从图x中可以看到，预先喂给发送FIFO的两个数都顺序送到总线上了，再没有出现莫名其妙的0xFF。同时，观察Overflow事件的标志位也没有产生。看起来是相安无事。

为什么不是像手册里说的需要预先喂1个，而是2个？这个问题曾让我百思不得其解，也做了一些实验，预先喂更多的数据，这个收发延后的字节数量会增多，但至少还是2个字节。咨询我的同事 Major 之后，得到了一个关键的信息点，从机模式下的连续模式的行为。（赶快抄到本本上！！！）

根据常规的理解和手册上字面表述的意思，slave在同master通信之前，要预先向发送FIFO中送个数，如此在master发起通信时，slave可以将预先填充的数送上总线。刚送数上线之后的一瞬间，PCS仍保持选中，slave判定处于连续模式，为可能即将到来的传输过程做好准备，发送移位器立即向发送FIFO要数。根据样例工程的逻辑，再送入发送FIFO的数要来自于刚收到的数。但此时，接收FIFO刚收到数（也有可能还没送到，在从移位器转移到接收FIFO的路上），软件还没来得及从接收FIFO中读数，更没来得及向发送FIFO送数。所以，此时发送FIFO是空的！发送移位器也是空的！Underflow事件发生！发送移位器说了，“我饿。。。没有吃上饭就要出工，我只能吐泡泡。。。

这种情况下，可以有两种解法：

使用中断方式或者DMA等方式取代CPU，在需要的时候，立即自动给发送FIFO装入预先准备好的数。本例中，要从收到数的接收FIFO中取数后再向发送FIFO写数，在要送数的一刻还在收数，实际已经是慢了一拍。
或可使用非连续传输，在发送移位器向发送FIFO要数之前，slave检测到PCS信号松开，就停止要数的请求。在下次启动传输前，中间等待的过程，有足够时间给软件从接收FIFO中把数拿出来再送入发送FIFO，再被发送移位器要走，应对下一次master发起的传输。

通过实验证实，在非连续模式下，这个延后果然就变成了一个字节，同预期相符。如图x所示。

在这里插入图片描述