Marvell-linux研究—背景知识
转载时请注明出处和作者联系方式:http://blog.csdn.net/absurd
作者联系方式:李先静 <xianjimli at hotmail dot com>
更新时间:2007-6-21
在正式进入Marvell-linux研究之前,我们介绍一点背景知识,让没有手机开发经验的朋友有个概念。
1. 基带(BaseBand)
基带是传统手机中最重要的功能,它直接与无线网络交互,负责信号的发送和接收。所有编码/解码和网络协议处理都是它负责的,这一部分也是最复杂,涉及专利最多的部分。所幸的是,大部分处理都集成在芯片里了,对于一般手机设计来说,至少在软件方面是不用太关心的。
我们知道,交变电流在流经导体时会产生无线电波,无线电波可以经过空间传播出去,这就是无线发送的原理。而无线电波又可以让导体产生电流,电流信号可恢复为与发送时的一致信号,这就是无线接收的原理。
在无线电设备中,这里的导体就是天线,天线的长度是有要求的,它一般不能小于波长的一半,像耳朵能听声音频率范围是20Hz~20KHz,最敏感的部分在2500赫兹到3000赫兹之间。因为波长x频率=光速,以3000赫兹的无线电波为例,它对应的波长是100公里,如果直接收/发这种电波,那么天线长度至少要50公里,我们当然不可能在手机上安装一个50公里长的天线,怎么办呢?
要缩短天线的长度,只能提高电波的频率。发送时,把低频信号调制在高频信号上再发送出去,接收时,先得到高频信号,然后从中解调出低频信号。这里高频信号称为载波,一般GSM手机使用1800M或900M的载波,而CDMA使用800M或1900M的载波。当然这里的频率指的是中心频率,信号本身要占一定的带宽,而且为了避免干扰,发送和接收所用的频率也不一样,以900M的载波来看,接收频率为925M-960M,发送频率为880M-915M。
高频信号是真正在空间中传播的无线信号,对高频信号的处理也就是所谓的射频(RF) 信号处理,高频信号让天线变短了,这是它的好处,同时也带来了副作用,因为它的波长太短,它可能把印刷板上的导线都当作天线,在上面产生感应电流,原本两根无关的导线,现在变得关系暧昧,加上无线电波的反射互相影响,使其中充满太多不确定因素,导致射频电路设计非常复杂。按照温伯格的《系统化思维导论》里的说法,这是一个典型的中数系统,即不能采用小数系统中那样的简化,又不能采用大数系统中的概率统计。
手机的功率比较小,它不能直接与卫星建立通信,而是与基站(BS)之间通信,基站呈蜂窝状布置,所以以前称手机为蜂窝电话。
现在的手机都是数字信号,即使音频信号也要进行数字编码之后才能传递,任何通信都有一套通信协议,手机和基站之间的通信当然也不例外,多个手机共享基站,信道的建立,手机在基站之间的切换,如此等等,还有很多复杂的情况,所以整套协议非常复杂。
多个手机共享一个基站,如何共享,这就是所谓的多址问题。常见的有频分多址(FDMA)、时分多址(TDMA)和码分多址(CDMA)。在2G中通常使用频分多址(FDMA)和时分多址(TDMA)的组合,而在3G中使用码分多址(CDMA)。
2. 应用处理器(AP)
AP从逻辑上讲是一个独立的东西,在物理上可以独立于基带处理器,也可以从属于基带处理器。如果使用Marvell的Monahans系列芯片,那么可以肯定AP是独立于基带处理器的。
AP的功能是运行应用程序,我们常说的MMI就是在这上面运行,一般手机设计公司的主要工作就是开发这些应用程序。一个典型软件(linux平台)的分层视图如下图所示:
在Marvell-linux这个系列中,我们关注的主要是linux kernel中与平台相关的部分。
3. BB与AP的桥梁
既然像电话这种通信类应用程序是在AP上跑的,而通信功能又是在BB上实现的,那么就一定会存在一个连接AP和BB的通道。
最常见的连接方式就是串口,在linux下,也就是tty设备。在AP这边,用AT命令控制BB,来实现打电话和发短信等功能,在3GPP的《AT command set for User Equipment (UE)》文档中定义标准的AT命令,各个模组厂家为了增加功能,在上面都做了些扩展,在使用AT时,要参考模组厂家的手册。
AT命令是文本格式的,它经过串口发送到BB。它控制BB来完成打电话和发短信等传统功能没有问题,但是要通过BB无线上网(如GPRS),就遇到麻烦了,因为上网的数据是二进制的,如果和AT命令混在一起从串口传输,那就会乱成一团了。
为了解决AT命令和二进制数据共享串口的问题,3GPP制定了一个称为多路复用的协议,它把一个物理串口虚拟成多个逻辑上的串口。应用程序使用各自独立的虚拟串口而互不干扰。
有人会问GPRS数据和AT命令是通过多路复用协议经串口在AP和BB之间传递的,那么打电话时的语音数据呢,是不是也是走条通道呢?答案是否,因为那样做效率太低了,所以对于下行语音数据,BB解码后直接送到speaker,对上行的语音数据,从MIC采样/处理后,直接通过BB发送出去。
~~end~~