文章转载自:http://blog.csdn.net/ajigegege/article/details/16354563
这段时间做了IIS的试验。被这个试验也折腾了很久。总的来讲IIS还是一个相对简单的通信协议。
s3c2440一共有5个引脚用于IIS:IISDO、IISDI、IISSCLK、IISLRCK和CDCLK。前两个引脚用于数字音频信号的输出和输入,另外三个引脚都与音频信号的频率有关。
要用好IIS,就要把信号频率设置正确。下面介绍这几个时钟:
fs:采样频率。fs不是任意设置的,一般基于不同的应用场合和听觉效果,设置不同的几个固定的值,如8kHz、16kHz、22.05kHz、44.1kHz、48kHz、96kHz等。通常,在wav文件的头部中, 会给出该文件的fs。
IISSCLK:串行时钟,每一个时钟信号传送一位音频信号,因此IISSCLK的频率=声道数×采样频率×采样位数。如采样频率fs为44.1kHz,采样的位数为16位,声道数2个(左、右两个声道),则IISSCLK的频率=32fs=1411.2kHz。
IISLRCK:帧时钟,用于切换左、右声道,如IISLRCK为高电平表示正在传输的是左声道数据,为低电平表示正在传输的是右声道数据。IISLRCK的频率=采样频率。
CDCLK:由于IIS只负责数字音频信号的传输,而要真正实现音频信号的放、录,还需要额外的处理芯片(在这里,我们使用的是UDA1341),CDCLK为该芯片提供系统同步时钟,即编解码时钟,主要用于音频的A/D、D/A采样时的采样时钟。一般CDCLK=256fs或384fs,通过寄存器可以配置。
这里有一个重要的约束关系:PCLK经过两个预分频器处理后分别得到IISSCLK、IISLRCK和CDCLK(预分频器A得到IISSCLK、IISLRCK,预分频器B得到CDCLK)。寄存器IISPSR是IIS预分频器寄存器,5~9位是预分频器A,0~4位是预分频器B,一般来说,这两个预分频器的值N相等。我们是通过CDCLK来计算预分频器B的值N的,即CDCLK=PCLK / (N+1)。对于给定的wav文件,fs是确定的。因此这里就需要协调:PCLK、CDCLK、和N的值。有时需要重新调整系统时钟(因为保持PCLK不变,只改变CDCLK和N的值很难满足CDCLK=256fs或者384fs。)
PCLK与FCLK有一定的比例关系,而FCLK又是由输入频率Fin得到。在这里,我们为了简化计算,不改变PCLK与FCLK的比例关系(即维持在启动代码中定义的1:8的关系),那么由Fin而得到CDCLK一共涉及到四个参数:MDIV、PDIV、SDIV和前面公式中的N,涉及到的寄存器有MPLLCON和IISPSR。因此要得到这四个参数值,就需要一点耐心地计算,原则是误差最小,其中需要注意的是,计算的结果(包括中间过程的结果)不要溢出,即不要超过32位。例如Fin为12MHz,我们设置采样频率fs=44.1kHz,而CDCLK=384fs=16.9344MHz,那么经过计算,最终得到N=3,MDIV=150,PDIV=5,SDIV=0,即IISPSR = (3<<5) | 3;,MPLLCON = (150<<12) | (5<<4) | 0。
在arm中MPLL的频率就等于FCLK的频率。
s3c2440有关IIS的寄存器除了IISPSR外,还包括IIS控制寄存器IISCON,主要用于控制数据传输的方式、预分频器和IIS接口是否开启;IIS模式寄存器IISMOD,主要用于设置IIS的时钟源、主从方式、接收发送方式、串行接口方式、每个声道串行数据位数和各种频率值;IIS的FIFO接口寄存器IISFCON用于设置和判断数据传输的FIFO状态;而寄存器IISFIFO则用于音频数据的传输。
在mini2440上,负责具体解码音频的芯片是uda1341。s3c2440与UDA1341之间除了我们前面介绍过的IIS接口相连接外,还有一个称之为L3总线的连接,用于s3c2440配置UDA1341内部的寄存器。IIS用于实现ARM和uda1341之间数据的传输,L3总线用于实现arm对uda1341的配置。由于s3c2440不具备L3总线接口,因此我们是用三个通用IO口来模拟L3,从而实现L3总线的传输。
L3就是line 3(3条线)的意思,它只有L3DATA(数据线:用于传输数据)、L3MODE(模式线:用于选择模式)、L3CLOCK(时钟线:用于传输时钟)。L3一共有两个模式:地址模式和数据传输模式,先传输地址模式数据,再传输数据模式数据。L3MODE为低时是地址模式,L3MODE为高时是数据传输模式。L3DATA和L3CLOCK相互作用,完成8位数据的传输,传输的顺序是先低位数据,再高位数据。对于clock没有特别精确的频率要求,因此,我们在程序中通过手动将一个gpio拉高拉低,从而模拟了一个时钟信号。在拉高拉低的同时,再配合数据的传输,就可以了(传输时,是把数据按位送出的,L3是串行的协议)。
地址模式是用于选择设备和定义目标寄存器,在这种模式下,8位数据的含义是:高6位是设备地址(UDA1341的地址为000101),低两位是后面数据模式下寄存器的类型(00:DATA0,01:DATA1,10:STATUS)。只要没有再改变地址模式下的数据,则数据模式下的数据始终是传输到上一个地址模式所定义的寄存器内。
传输数据模式下,STATUS是用于设置复位,系统时钟频率、数据输入模式、DC滤波等内容。DATA0分为直接寻址模式和扩展寻址模式,直接寻址模式是直接进行模式的控制,包括音量、静音等等,而扩展寻址模式是在直接寻址模式下先设置3位扩展地址,再在直接寻址模式下设置5位扩展数据。在DATA1下,可以读取到被检测峰值。至于具体的DATA0、DATA1、STATUS下。
在我们的程序中,通过下面这个函数实现L3的协议:就是实现从arm给uda写入数据。(主要是配置它的寄存器)
放音的程序就是先通过L3协议配置uda,然后再配置arm的寄存器。这样就可以播放音乐了。在uda的配置中,会设置CDCLK的频率。要保证对uda的设置和对arm的设置是一致的。
另外,需要注意的是wav文件的头部格式。在wav文件的头部中,有这段音频的采样率、声道数、每个采样点用多少bit表示(一般是8bit或是16bit)。
这里记录一下我自己的经历,刚开始时,我在网上下载了很多wav的音频,但是这些音频都是单声道,并且一个采样点用8bit表示,对于这种音乐,IISMOD[1:0]
无法配置。因此,都播不出声音。这也就意味着uda不支持这种格式。后来,我参考了2440test那个裸机程序,那里用的一段wav是xp启动时的音乐,并且在2440test中,实现了对wav音乐格式的解析。这样,我就顺利的实现了音乐的播放。而在2440test里,对于8bit的单声道wav认为格式是错误的,这也就证实了我的猜测。其实,最重要的还是频率的设置(包括从fin设置MPLL,再到FCLK、PCLK,再到CDCLK的设置)。
另外,手动实现l3协议的传输也是很值得学习的。 录音的试验我没有做,mini2440上面录音的插口在哪里?