嵌入式Linux系统下基于UDA1341芯片的音频驱动程序设计.pdf

第 29 卷第 4 期计算机应用与软件Vol.29 No 42012 年 4 月Computer Applications and SoftwareApr 2012嵌入式 Linux 系统下基于 UDA1341 芯片的音频驱动程序设计霍燃高丽萍陈庆奎(上海理工大学光电信息与计算机工程学院上海 200093)收稿日期:2011 06 28。国家自然科学基金项目(60203011);上海市教委晨光计划项目(10CG49);上海高校选拔培养优秀青年教师科研专项基金项目(SLG1007)。霍燃，硕士生，主研领域:嵌入式系统开发。摘要论述嵌入式 Linux 系统基于 UDA1341 芯片的音频驱动程序设计方法。该方法以 UDA1341 音频芯片及 IIS(Inter-ICSound)总线为硬件架构，以 OSS(Open Sound System)模型为软件基础，可以方便地扩充到其他应用平台。以实验证明了该方法的有效性。关键词嵌入式 LinuxUDA1341IIS 总线OSS 模型音频驱动中图分类号TP368 1文献标识码AAUDIO DRIVER PROGRAMMING BASED ON UDA1341 FOREMBEDDED LINUX SYSTEMHuo RanGao LipingChen Qingkui(School of Optical-Electrical and Computer Engineering，University of Shanghai for Science and Technology，Shanghai 200093，China)AbstractThe paper discusses an audio driver programming design approach based on UDA1341 chip for embedded Linux system Thismethod makes use of UDA1341 audio chip and IIS bus as the hardware architecture and OSS model as the software foundation It can beextended to other application platforms conveniently The effectiveness of the approach is verified with experimentKeywordsEmbedded LinuxUDA1341IIS busOSS modelAudio driver0引言音频系统是嵌入式系统应用中的一个重要组成部分，广泛应用在车载 GPS 导航、智能手机、DV 摄像机、智能家居和公共场所的多媒体系统中。与传统的音频系统相比较，嵌入式音频系统具有操作简单，成本低廉，能有效地控制功耗并大幅提高产品可靠性等特点。但要实现这些功能，系统开发和设计的难度也相应地增大。嵌入式音频系统包括硬件部分和软件部分。本文所讨论的系统在硬件上使用的基于 内部集成电路声音 IIS1 总线的音频系统体系结构。软件部分主要是以开放式声音系统 OSS 模型2 为基础实现嵌入式 Linux 下的各种音频功能的驱动程序。本文以 UDA1341TS 音频编码解码芯片3 为例，讨论了音频驱动程序设计方法，而驱动程序的实现主要依赖于音频总线接口、相应硬件的工作原理以及在嵌入式 Linux 下设备管理方式和驱动程序的体系结构。1IIS 总线IIS 总线也常被写作为 I2S，是工业和嵌入式领域常采用的音频总线之一，它是 Philips 公司提出的串行数字音频总线传输协议。通过该协议嵌入式处理器(如 S3C2410)就可以与外部的音频芯片(UDA1341TS)进行数据传输。IIS 总线接口通常用 5根线来与外部芯片进行连接(如图 1 所示)。它们是:I2SDI串行数据输入线。I2SDO串行数据输出线。SCLK串行数据提供位时钟。LRCLK切换左右声道数据帧。MCLK同步时钟。图 1IIS 总线连接基于 ARM9 的三星 S3C24104 微处理器内置了 IIS 总线接口可直接与外音频芯片 UDA1341TS 的 IIS 接口相连接。为了使引脚个数尽可能少，S3C2410 只使用了四条线引与 UDA1341TS芯片相连:串行数据输入线(IISDI)、串行数据输出线(IISDO)、第 4 期霍燃等:嵌入式 Linux 系统下基于 UDA1341 芯片的音频驱动程序设计17串行数据位时钟(IISCLK)、左右声道选择(IISLRCK)。具体引脚连接方式如图 2 所示。图 2S3C2410 与 UDA1341TS 之间的引脚连接图IIS 寄存器的设置是与驱动程序关系最密切的部分。在驱动程序中必须对 IIS 总线的各种寄存器进行正确的设置才能保证 IIS 总线正常工作，其中包括 IISCON(IIS 控制寄存器)、IIS-MOD(IIS 模式寄存器)等。IISCON 寄存器的位描述见表 1。表 1IISCON 寄存器的位描述IISCON位描述初值左/右声道指示(只读)80=左声道 1=右声道1发送 FIFO 准备好标志(只读)70=FIFO 没准备好(空)I=FIFO 准备好(非空)0接受 FIFO 准备好标志(只读)60=FIFO 没准备好(满)I=FIFO 准备好(非满)0发送 DMA 服务请求使能 50=请求禁止 1=请求使能0接受 DMA 服务请求使能 40=请求禁止 1=请求使能0发送声道空闲信号 3在闲置状态 IISLRCK 是停止的(暂停 Tx)。只有在 IIS 是主控时这一位才有效。0=产生IISLRCK，1=不产生 IISLRCK0接受声道空闲信号 2在闲置状态 IISLRCK 是停止的(暂停 Rx)。只有在 IIS 是主控时这一位才有效。0=产生IISLRCK，1=不产生 IISLRCK0IIS 比率使能 10=比率禁止 1=比率使能0IIS 接口使能 IIS(开始)00=IIS 禁止(停止)1=IIS 使能(开始)02UDA1341TS 芯片UDA1341TS 是 Philips 公司生产的低功耗、全双工音频编码解码芯片，其不但能完成基本的 D/A 和 A/D 转换功能，而且还具有出色的音频控制(由 Mixer 完成)数字信号处理(DSP)功能。可以应用于多种需要进行声音录入或输出的嵌入式多媒体设备中。UDA1341TS 支持 IIS 总线数据格式，字节长度最高可到20 位，但由于 IIS 总线只能处理声音数据，所以它不但提供了基本的 IIS 总线接口和麦克风扬声器接口，还提供了 L3 控制总线接口，实现了音量控制等功能。2 1控制信号的传输为了实现对音频特性的控制功能，可将 S3C2410 微处理器直接与外部音频芯片 UDA1341TS 的 L3 控制接口相连接，其具体连接方式为将 UDA1431TS 的 L3 控制接口引脚 L3MODE，L3DATA，L3CLOCK 连接到 S3C2410 的三个通用数据引脚上，从而实现对控制信号的传输如图 2 所示。2 2音频数据的传输CPU 与外部芯片进行数据传输的方式有两种:一种是传统的中断方式，另一个是直接存储器存取 DMA 方式。音频数据的传输可以通过先入先出 FIFO 的寄存器队列来完成 但是由于S3C2410 处理器的音频 FIFO 寄存器队列只有 64 字节，如果CPU 采用中断的方式来为 FIFO 队列填充数据，不但很难保证音频播放的连续性，而且还会由于 CPU 频繁的响应中断而导致系统执行效率的降低和性能的下降，所以通常系统都会采用DMA 方式进行音频数据传输。为了实现全双工数据传输，使录音和放音可以同时进行，通常使用两个 DMA 通道，并在内存中建立双缓冲区甚至是多个缓冲区，用来实现同时录音和放音。处理器通过 IIS 总线和系统总线来完成和音频芯片之间的数据传输，它们之间的连接示意图如图 3 所示。图 3音频系统连接示意图3Linux 下的设备管理为了使 Linux 内核能够以模块化方式管理设备并向向应用程序开发人员提供统一且简单易用的接口，Linux 采用的是设备文件的管理方式5，即将各种设备都映射成一种特殊的文件设备文件，它是通过一个 structfile 结构体来表示的，与普通文件的表示方法完全相同。这使得应用程序的开发人员可以像访问普通文件一样通过访问设备文件来实现对相应设备的访问。Linux 标识设备的方法是使用设备类型、主设备号、次设备号的方法，主设备号是系统中唯一的正整数，而次设备号在为在同一设备类型中区分不同的设备而备用的。同时，Linux 引入了设备文件系统(devfs)把设备文件纳入到文件系统的管理范围之内，设备文件则通过驱动程序完成在设备文件系统中的注册与管理。Linux 对设备文件的操作就是通过调用相应的驱动程序，也就是说设备驱动程序提供了对这些设备文件访问的接口。设备驱动程序接口就是一个 file_operations 数据结构，这个 file_oper-ations 结构中的成员都是函数指针，每个进程对设备的操作都会根据设备的主次设备号，转换成对 file_operations 结构的访问。通过该接口用户可以打开、关闭、读数据、写数据、控制设备等操作，相应的操作函数为 open()、release()、read()、write()、ioctl()等。开发驱动程序就是要根据相应的硬件来实现这些接口函数的功能。4Linux 下音频驱动程序OSS 是 Linux 下常用的一种音频体系结构。OSS 是 Linux下一种音频编程的标准模型，它包含一套完整的内核驱动程序模块，为各种声卡提供统一且简单易用的编程接口，即 open()、read()、ioctl()等。而 OSS 的硬件标准中包括两种最基本的音频设备:混音器(Mixer)和数字信号处理器(DSP)。UDA1341TS芯片正是一个符合这种标准的音频设备，它内部的 Mixer 通过18计算机应用与软件2012 年L3 控制接口与 S3C2410 的数据接口相连，实现了对音频的各种控制功能(包括音量大小、声道选择、声音速度等)。它的 DSP部分则通过 IIS 总线与微处理器相连，主要实现的是编码和解码，即录音放音等功能。Mixer 对应的驱动程序接口为:static struct file_operations smdk2410_mixer_fops=ioctl:smdk2410_mixer_ioctl，/控制声音特性open:smdk2410_mixer_open，/打开混音设备文件release:smdk2410_mixer_release，/关闭混音设备文件;DSP 对应的驱动程序接口为:static struct file_operations smdk2410_audio_fops=llseek:smdk_2410_audio_llsee，/重新选择播放位置read:smdk_2410_audio_read，/播放声音write:smdk_2410_audio_write，/录制声音poll:smdk_2410_audio_poll，/选择操作ioctl:smdk_2410_audio_ioctl，/其他操作open:smdk_2410_audio_open，/打开声音设备文件release:smdk_2410_audio_release，/关闭声音设备文件;这两个驱动程序接口就是两个 file_operations 类型的结构体，编写驱动程序就是要实现结构体中每个成员函数的功能。驱动程序在向 Linux 系统注册成功时会返回一个唯一的主设备号。每个成员都对应一个系统调用，在系统调用时通过设备号找到对应硬件的设备驱动程序，并读取这个结构体中成员函数的指针，从而获得该函数实现的功能。4 1UDA1341TS 音频驱动的实现UDA1341T 芯片的两个设备 Mixer(混音器)和 DSP(数字信号处理器)在 Linux 设备文件系统(devfs)中被映射为两个设备文件，分别为/dev/sound/dsp 和 dev/sound/mixer。它们是在驱动程序中用 register_sound_mixer()和 register_sound_dsp()函数进行注册的，这两个函数在 drivers/sound/sound_core c 中被定义。使用下面两语句即可实现音频驱动的加载:audio_dev_mixer=register_sound_mixer(smdk2410_mixer_fops，1);audio_dev_dsp=register_sound_dsp(smdk2410_audio_fops，1);其中，第一个参数是 file_operatios 结构类型的指针，其中定义了设备的操作函数;第二个参数是设备标识，注册成功后返回的是一个非负整数，注册失败则返回一个负数。在卸载时输入注册时的设备号即可。下面两个函数实现了从内核中卸载设备的功能:unregister_sound_mixer(audio_dev_mixer);unregister_sound_dsp(audio_dev_dsp);(1)UDA1341 驱动加载及初始化驱动程序加加载及初始化的代码在函数 s3c2410_uda1341_init()中实现，主要是完成有关的硬件始化工作，其中包括 CPU的 L3 总线和 IIS 总线的初始化，UDA1341 的初始化，还有 DMA缓冲区的初始化;函数 init_uda1341()用来完成 UDA1341 芯片的初始化，主要是根据它的芯片手册对它的各个寄存器进行赋值，完成对音频的一些如初始音量、默认声道、采样率等特性的设置，然后需要申请两个 DMA 通道，我们将 DMA_CH1 设置为输入通道:in-put_stream dma_ch=DMA_CH1，DMA_CH2 设置为输入通道:output_stream dma_ch=DMA_CH2，并通过 audio_init_dma()函数进行 DMA 缓冲区的申请。进行驱动程序卸载时用函数 void_exit s3c2410_uda1341_exit()来实现，主要是注销音频设备文件和混音设备文件，用 audio_clear_dma()函数来释放 DMA资源。(2)Mixer 设备驱动程序的实现Mixer 设备不执行读写操作，主要用来控制混音效果，它是通过 L3 控制总线接口与 S3C2410 的三个通用数据引脚相连来达到控制目的。Mixer 的驱动程序主要有三个函数:打开设备open()、关闭设备 release()和一个控制调用 ioctl()Mixer 的打开和关闭是通过两个系统定义的宏 MOD_INC_USE_COUNT 和MOD_DEC_USE_COUNT 来实现的;而 Mixer 的控制函数 iotcl()则通到应用程序传递过来的 CMD 参数来选择对应的实现代码。(3)DSP 设备的打开与关闭DSP 设备的打开是通过在 DSP 设备对应的 file_operations类型的 smdk_2410_audio_fops 中，找到 open 操作对应的函数指针指向打开操作的函数 smdk_2410_audio_open()来进行的，这个函数根据传递过来的参数执行具体的打开操作。它主要完成的工作有以下几方面:判断在 open()系统调用时传递过来的打开方式的参数，包括 O_RDONLY，O_WRONLY 或 O_RDWR 等方式。初始化一些声音特性，如声音采样率等。IIS 总线的初始化，对 IIS 总线的一些寄存器进行设置，若用只读方式打开可以用函数 init_s3c2410_iis_bus_rx()将 IIS总线初始化为接收模式;若用只写方式打开可以用函数 init_s3c2410_iis_bus_tx()将 IIS 总线初始化为发送模式;若用读写方式打开可以用函数 init_s3c2410_iis_bus_rxtx()将 IIS 总线初始化为全双工模式。最后将系统定义的宏 MOD_INC_USE_COUNT 进行加 1操作，这个宏定义的是驱动模块的数量。当 DSP 设备使用完成，为了不占用系统资源，需要通过与DSP 设备相对应的 file_operations 类型的 smdk_2410_audio_fops中，找到 release 操作对应的函数 smdk_2410_audio_release()来释放该设备。音频设备的打开过程如图 4 所示。图 4UDA1431 初始化过程(4)DSP 设备读写操作读写操作是该驱动程序中的关键操作，它们实现的就是音频的输入输出，即录制与播放的功能。它们是通过 DSP 设备对应的 smdk_2410_audio_fops 结构体中 smdk_2410_audio_read()第 4 期霍燃等:嵌入式 Linux 系统下基于 UDA1341 芯片的音频驱动程序设计19和 smdk_2410_audio_write()来完成的。下面主要分析一下 write()的实现过程:首先是判断设备的打开方式，可以通过参数 O_WRON-LY 或 O_RDWR 设置为只读方式或读写方式。然后是对 DMA 缓冲区的操作。首先判断是否创建了DMA 缓冲区，通常情况下如果是 DSP 设备第一次 open 以后，并没有创建，所以需要通过 audio_setup_buf()来创建 DMA 缓冲区，并对缓冲区进行管理。最后是进行音频缓冲区信号量的释放。(5)DSP 设备控制操作为了实现一些对音频特性的控制，如采样率、立体声、声道选择、声音速度等，就需要实现驱动程序入口中的 smdk_2410_audil_ioctl()函数，它和 Mixer 设备驱动程序入口的 smdk_2410_audil_ioctl()函数共同实现对音频特性的控制。smdk_2410_au-dil_ioctl()是一个可以带自定义的命令参数的函数，通过这个命令参数实现相应的功能。参数 cmd 是在系统调用时传递进来的，而在函数内部则是通过一组 case 语句按 cmd 的参数值来实现相应的功能，如 SOUND_PCM_READ_RATE(读取速率)、SNDCTL_DSP_RESETS(复位)、SNDCTL_DSP_SETFRAGMENT(设置 DSP 段大小)等。这种驱动程序设计的方法比较灵活，为驱动程序的编写提供了丰富的接口。另外还有两个控制函数smdk2410_audio_llseek()和 smdk2410_audio_poll()，它们实现了诸如从某个指定位置进行播放、暂停和继续等功能。4 2用 WAV 音频文件测试驱动程序WAV 全称 Wave Audio Files，WAV 来源于对声音模拟波形的采样。为了测试编写好的音频驱动，我们通过 Linux 下的 cp命令将一段 WAV 音频拷备到驱动程序目录中，其命令为:cp test wav/dev/sound/并用 wavplay 程序进行播放测试6(如图 5 所示)。通过测试得到了良好的播放效果，说明音频驱动程序可以正常工作。图 5WAV 文件播放测试5结语本文在以 UDA1341TS 音频芯片为核心器件的音频系统和嵌入式 Linux 系统内核为基础，讨论并实现了一个 OSS 音频驱动程序，对 Linux 下驱动程序的开发具有一定的指导意义。为了进行更为深入的研究和开发，我们还需要继续开发一些其他的驱动程序功能，以实现更丰富的应用。随着嵌入式系统的快速发展，嵌入式音频技术的应用必定会更加广泛。参考文献1 The I2S-Bus SpecificationS Philips Semiconductors Co，20002 http:/www opensound com/oss html3 UDA1341TS Specification S Philips Semiconductors Co，20004 S3C2410A 32bit RISC Microprocessor User ManualM Samsung E-lectronics Co，20045 李俊 嵌入式 Linux 设备驱动开发详解M 人民邮电出版社，20086 刘淼 嵌入式系统接口设计与 Linux 驱动程序开发M 北京航空航天大学出版社，2006(上接第 5 页)假设客户对需求的把握性不好，那么此时系统要求对变化性很高。假设变化性的重要性和期望值都是 5，而开发时间和成本的重要性和期望值都为 1，那么关于“资料补充”的推荐解决方案是 B(S11，S22，S31)。2)常见情况，当质量属性期望值、重要性及问题的重要性发生变化时，最终的评价结果和推荐方案也会发生变化。比如在某时期，要求对“资料补充”需求分解的问题的重要性重新分配，问题 I2的重要性程度为 0 5，而 I1是 0 2。系统的可靠性的期望值变成 4;功能的重要性变成 1;开发时间的重要性为 2，期望值为 1;安全性的重要性为 5，期望值为 4。此时的推荐方案是 E(S12，S23，S31)。5结语本文通过给出一个具体的数学模型，将需求关注的质量属性的期望值作为评价目标，把最终组成的总体备选解决方案关于质量属性的权值与期望值比较，然后计算出总体备选方案的评价值，通过排序推荐出总体备选方案，完成复杂的决策过程。将该模型用于具体的实际项目(审计管理系统)中，推荐了排名最优的总体备选解决方案，并讨论了方法的局限性。针对这些局限性，未来的工作需要将上下文环境和质量属性等使用形式化的语言描述。同时对解决方案冲突进行描述和检查，应用构件组装的相关技术半自动地给出组装建议。参考文献1 Jansen A，Bosch J Software Architecture as a Set of Architectural De-sign Decisions C/Proc 5th Working IEEE/IFIP Conf on SoftwareArchitecture(WICSA05)2005:109-1192 Vander Ven J S，Jansen A G J，Nijhuis J A G，et al Design decisions:The bridge between rationale and architectureM/Rationale Man-agement in Software Engineering Springer-Verlag，2006:329-3483 Tyree J，Akerman Architecture decisions:Demystifying architecture J IEEE Software2005，22(2):19-274 Jansen A，Ven J A D，Avgeriou P，et al Tool Support for ArchitecturalDecisionsC/Proc 6th Working IEEE/IFIP Conf on Software Ar-chitecture(WICSA07)2007:33-405 Bass L，Clements P，Kazman R Software Architecture in PracticeM Addison-Wesley，20036 Philippe Kruchten，Patricia Lago，Hans van Vliet Building Up and Rea-soning About Architectural Knowledge M Springer，2006:43-587 Malan R，Bredemeyer D Less is More with Minimalist Architecture M IEEE IT Professional，2002:46-488 Cui Xiaofeng，Sun Yanchun，Mei Hong Towards Automated SolutionSynthesis and Rationale Capture in Decision-Centric Architecture De-sign C/WICSA，2008:221-2309 Shari Lawrence Pfleeger，Joanne M Atlee Software Enginerring Theoryand Practice OL http:/www potal acm org 10 Allan Maclean，Richard M Young，Thomas P Moran Design RationaleThe Argument Behind The ArtifactM CHI，1989