Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2578320
  • 博文数量: 333
  • 博客积分: 4817
  • 博客等级: 上校
  • 技术积分: 4413
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-28 10:51
文章分类

全部博文(333)

文章存档

2017年(20)

2016年(57)

2015年(27)

2014年(20)

2013年(21)

2012年(164)

2011年(24)

分类: LINUX

2012-04-07 13:38:17

转载:

SPI总线上有两类设备:一类是主控端,通常作为SOC系统的一个子模块出现,比如很多嵌入式MPU中都常常包含SPI模块。一类是受控 端,例如一些SPI接口的Flash、传感器等等。主控端是SPI总线的控制者,通过使用SPI协议主动发起SPI总线上的会话。而受控端则被动接受 SPI主控端的指令,并作出响应的响应。

Linux目前只支持SPI主控端,不能支持SPI受控端设备。

Linux中的SPI是依靠SPI子系统实现的。这个子系统向下直接和SPI主控设备硬件交互,读取SPI总线上的数据。向上则和FS子系统、MTD子系统、字符设备子系统等等交互,给用户空间提供访问接口。

在SPI子系统中,包含两类设备驱动。一类称之为Controller driver,用于驱动SPI主控设备,以和SPI总线交互,读写通信数据。另一类称之为Protocol driver,用于解析Controller driver读取的数据,形成有意义的协议数据。举例来说,将AT25芯片通过SPI总线和LPC3250的SPI控制器联接在一起,构成一个SPI总线 通信系统。Protocol driver的作用,就是根据用户空间或者上层子系统的请求,(比如读写Flash指定地址出的数据),找到对应的SPI指令,并生成一个SPI会话帧 (指令+地址+数据)数据。Controller driver的作用,就是将这个会话帧的数据通过SPI控制器的硬件,发到SPI总线上去。

由此可见,SPI子系统中有两种设备,一种是Controller driver驱动的,称之为spi_master。另一种是由Protocol driver驱动的,称之为spi_device(个人觉得这种称法不太准确,这个设备只是协议解析设备,而非真正的spi设备)。

内核之所以把SPI子系统这么划分,是因为SPI主控器功能单一,只负责和SPI总线交互,读写数据。但数据的具体含义,根据SPI总线上的设备不同,而千差万别。

内核一方面把SPI通信系统分成上面两个部分,另一方面创建了一个spi核心系统,用于联接这两部分。

根据上面的分析我们知道,SPI通信的数据流大致是:
1、用户请求=>Protocol driver分析请求,生成SPI通信帧=>Controller driver将通信帧发送到SPI总线上;
2、SPI设备传回数据=>Controller driver从SPI总线上读回=>Protocol解析通信数据并上报;

其中Protocol和Controller之间的交互中,SPI帧是一个比较关键的数据结构。Protocol通过分析上层请求生成这种帧,并且 解析这种帧得到SPI设备的响应的结果。Controller通过和SPI总线交互,收发这样的帧。在Linux内核中,这个帧通过一个叫做 spi_message的结构来实现。

在有数据请求时,Protocol解析请求生成这个帧,并发送到SPI核心子系统。SPI核心子系统通过Protocol设备的信息,找到对应的 Controller设备,并将这个帧发送给Controller。Controller接受到这个帧后发送到SPI总线上。返程类似。

关于SPI Controller和Protocol这两种设备以及SPI核心子系统相互之间是如何工作的,请参考下一篇《Linux内核SPI子系统实现分析》。

阅读(6098) | 评论(1) | 转发(3) |
给主人留下些什么吧!~~

hushup2014-05-27 00:30:52

写得是真清晰