您的位置: OpenADSP社区论坛 -> Blackfin专区 -> 新手上路 -> 浅谈BF537处理器中sport口时分复用的理解(... 
本帖共有461个阅读者
发表帖子 发表投票 回复主题
浅谈BF537处理器中sport口时分复用的理解(转载)
尊贵身份标志
OpenADSP(管理员)
OpenADSP
头衔:社区公民
帮派:无帮无派
帖数:5187
金钱:34761
积分:6369
注册时间:2011/6/7
楼主信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
浅谈BF537处理器中sport口时分复用的理解(转载)
基于自动缓冲DMA模式下的Sport口的多通道操作

1, 基础知识

在给出例程之前,先了解一下相关的基础知识。

Sport接口提供一种多通道的操作模式,运用这种模式可以以时分复用的方式进行通信。在多通道模式中,每个数据字都占用一个独立的通道。每个sport最多可以进行128个通道的通信,sport口可以自动地选择某个通道而忽略其他的通道。Sport在每个通道中都可以进行发送,接收,或者同时发送和接收,或者什么都不做。多通道也可以运行在DMA模式下。

Sport多通道发送选择寄存器和多通道接收选择寄存器的设置必须在sport发送或者接收使能事前进行。也就是sport,DMA使能是所有相关寄存器设置之后的最后一步。

下图表示了一个多通道传输的实例,它具有以下特点:

在一个串行总线上用时分复用的模式进行传输,它的数据的发送和接收占用不同通道。

独立的选择发送或者接收通道

RFS信号最为帧开始的标志

TFS信号作为数据有效的标志

通道0和2用于接收,通道1和2用于发送多通道帧延时设置为1

多通道操作的使能

   SPORTx_MCM2中的MCMEN位置位使能SPORT多通道模式,sport的接收和发送时同时使能的,所有如果使能sport发送,那么接收也必须用多通道模式。  

帧同步信号

在多通道模式中所有的接收和发送设备都必须有一个唯一的参考时序。RFS用来做为这个唯一的参考时序,RFS标志着一个数据块的开始。

       在sport多通道模式下,接受方和发送方都用RFS来做为帧同步信号。RFS标志着多通道传输的开始。    

RFS在被发送方接收的到时候,传输就开始了,在传输期间的其他的RFS信号时背忽略的。

多通道帧同步延时

在多通道模式中, SPORTx_MCMC2寄存器的MFD域定义了在帧同步的有效沿和第一个数据位的时钟个数。这个位的设置为不同的设备接口提供了方便。MFD为0的时候,第一个数据位是和帧同步位同时发出的,也就是说没有延时。MFD最大的可设定值是15。

窗口大小

       窗口大小定义了被多通道选择寄存器使能的通道的个数。被使能的序列被称为被激活的窗口。WSIZE[3:0]的值可以取0—15,对应8---128个窗口大小,递增值是8个通道。默认值是0,对应8个通道。WSIZE[3:0]的值与被激活的通道个数的关于如下:

Number of words in active window = 8 x (WSIZE + 1)

分布在窗口外面的多通道被使能将要被忽略。

窗口偏移

       窗口偏移说明了,在1024个通道里面,被激活的窗口的起始位置。0表示没有偏移。例如wsize=0 woff=93,表示被激活的通道是8个,起始位置是93,即93—100通道是被激活。在sport被使能之后,这两个值是不能改变的。

通道选择寄存器

       这里的通道就是指的时分复用里的通道,每个通道一般是3—32位的一个数据字,具体字长可以自由设定。多通道选择寄存器中的每个位对应一个通道,置1说明使能对应的通道,0表示不使能对应的通道。SPORTx_MRCSn 和 SPORTx_MTCSn被用来使能接收和发送的有效通道。发送和接收分别有四个32位寄存器,共可以设置128个通道。


我是OP...
等级:管理员 参考IP地址:*.*.*.*
2015/12/13 18:51:16
尊贵身份标志
OpenADSP(管理员)
OpenADSP
头衔:社区公民
帮派:无帮无派
帖数:5187
金钱:34761
积分:6369
注册时间:2011/6/7
1信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线

2, 多通道设置例程

多通道应用背景:三个过程板与一个中心处理单元用sport总线相连,数据单向移动,从过程板向中心处理单元传送,传送方式:基于自动缓冲的DMA模式的sport多通道时分复用。

多通道时分复用的时候,sport口寄存器的设置:例如,两个设备,设备1设备2都向设备3发送,采用时分复用的方式主要寄存器设置如下:

基本参数:DSP : blackfin536

                 SCLK  100MHz

发送端没什么可说的,重点解释下面两个寄存器的设置

设备一:(发送)

       *pSPORT1_MCMC1 =0x1000;//设备1窗口大小是16,偏移量是0

       *pSPORT1_MCMC2 =MFD_1 |MCMEN;

       *pSPORT1_MTCS0 = 0x0000FFFF; 发送通道是16个通道

设备二:(发送)

*pSPORT1_MCMC1 =0x1010;//设备2窗口大小是16,偏移量是16

       *pSPORT1_MCMC2 =MFD_1 |MCMEN;

       *pSPORT1_MTCS0 = 0x0000FFFF; 发送通道是前16个通道

设备三:接收设备  系统时钟100MHz

       *pSPORT0_TCR1 = TCKFE | ITCLK;

       *pSPORT0_TCR2 = SLEN_32 ;//| TSFSE;  //这里设置字长是32位,可根据需要设定

            

       *pSPORT0_RCR1 =  RCKFE | IRFS | IRCLK;  //多通道时发送端提供帧同步

       *pSPORT0_RCR2 = SLEN_32 ;  //这里设置字长是32位,可根据需要设定

       *pSPORT0_RCLKDIV = 0x0001;   //发送时钟分频,可根据需要设定

       *pSPORT0_RFSDIV = 0x03C0;    //帧同步分频

      

            

       *pSPORT0_MCMC1 = 0x3000;  //窗口大小是32.就是说每个接收循环接收32个字,窗口偏移是0,就是从0通道开始接收

       *pSPORT0_MCMC2 =  MFD_1 | MCMEN;

       *pSPORT0_MTCS0 = 0x00000000;

       *pSPORT0_MTCS1 = 0x00000000;

       *pSPORT0_MTCS2 = 0x00000000;

       *pSPORT0_MTCS3 = 0x00000000;

       *pSPORT0_MRCS0 = 0xFFFFFFFF;  接收通道,32个通道

       *pSPORT0_MRCS1 = 0x00000000;

       *pSPORT0_MRCS2 = 0x00000000;

       *pSPORT0_MRCS3 = 0x00000000;


我是OP...
等级:管理员 参考IP地址:*.*.*.*
2015/12/13 18:51:34
尊贵身份标志
OpenADSP(管理员)
OpenADSP
头衔:社区公民
帮派:无帮无派
帖数:5187
金钱:34761
积分:6369
注册时间:2011/6/7
2信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线

调试过程中遇到的问题:收到的数据出现丢包或者重复包的现象。

原来是发送端的寄存器设置的问题,在DMA3_CONFIG这个寄存器中有个SYNC项的设置,在运用多通道时分复用的时候错误的将SYNC位置1了,就出现了上述的现象。原来这个SYNC位的作用是这样的:当DMA发送缓冲区的数据的最后一个数据移到sport FIFO中去的时候,就发生中断,然后刷新缓冲区,这是没有置位SYNC的情况。在置位SYNC之后的情况就变了,是sport FIFO中的数据的最后一个数倍发送出去之后才会产生中断,这样的话就会出现上述的错误现象,为什么会出现这样的现象呢?这是因为DMA缓冲区向sport FIFO中转移数据与sport FIFO向tx寄存器中发送数据的过程是连续的,加上SYNC这个位之后,当DMA缓冲区内的最后一个数据移动到SPORT FIFO中去的时候,并没有产生中断,这时发送过程还是正在执行的,当下一次再从DMA 缓冲区向FIFO中移动数据的时候,因为之前没有中断发生,DMA的缓冲区也没有刷新,它里面还是以前的数据,所以它又从第一个数据开始移动,所以这时又把DMA缓冲区内的第一个数据移出来了。当这个过程进行两次的时候,sport把这个循环进行完了,产生中断,这时DMA缓冲区的数据才开始刷新,所以,下一包数据实际上是前一包的数据的前两个字,加上DMA缓冲区刷新的数据的第三个字往后的数据,以此往复。


我是OP...
等级:管理员 参考IP地址:*.*.*.*
2015/12/13 18:51:48
Powered by OpenADSP Copyright © 2010 www.Openadsp.com. All rights reserved.154252 Call, 1 Queries, Processed in 0.015625 second(s),