1.tlv����Դ��
2.使用protobuf实现序列化与反序列化
3.TLV320AIC23的应用

tlv����Դ��

       FPGA高端项目：SDI 视频+音频编解码，解解析提供工程源码和技术支持

       本文详述了一款使用Xilinx 7系列Kintex7--xc7ktffg-2型号FPGA实现的析源3G-SDI视频+音频编解码方案，涵盖了编码、数据音频解码及视频解码过程，解解析并提供了完整的析源工程源码及技术支持。该设计适用于需要处理SDI视频与音频的数据热血江湖源码使用教程项目，如医疗、解解析军工领域或图像处理等高速接口相关应用。析源

       设计分为三部分：3G-SDI视频编码、数据3G-SDI音频解码和3G-SDI视频解码，解解析整合为一个工程，析源包括视频发送和视频+音频接收功能。数据在视频接收阶段，解解析首先通过GVA芯片进行均衡EQ处理，析源随后使用Xilinx官方GTX原语进行串并转换，数据调用SMPTE SD/HD/3G-SDI IP核实现解码。音频解码则采用UHD-SDI Audio IP核，最后将音频数据转换为i2s格式并输出到扬声器。vchat源码视频发送部分，使用静态彩条作为源数据，通过SMPTE SD/HD/3G-SDI IP核编码，并由GTX进行串化，GV芯片增强驱动，最终通过SDI转HDMI盒子显示。

       设计参考了Xilinx官方文档，确保了在不同输入状态下的线速率切换，确保了GTX的稳定运行。IP配置简洁明了，支持SD-SDI、HD-SDI和3G-SDI的编解码。音频解码后输出至i2s模块，再通过TLVAIC芯片播放SDI音频。视频发送通过静态彩条生成，经过编码、串化及驱动增强后，webapi 源码通过SDI接口输出至显示器。

       该设计在Vivado.2版本下实现，提供了一套完整的工程源码，供用户移植及开发使用。同时，作者还提供了相关的GT高速接口解决方案，包括基于A7系列FPGA的GTP方案、K7或ZYNQ系列FPGA的GTX方案、KU或V7系列FPGA的GTH方案及KU+系列FPGA的GTY方案。

       为了帮助用户更好地理解和应用该设计，作者在文章末尾提供了获取完整工程源码及技术支持的方式。请注意，由于代码文件较大，无法通过邮箱发送，而是采用百度网盘链接方式提供下载。请耐心阅读至文章结尾，按照指引获取资源。dotnetbar 源码

       特别提醒：本工程及其源码仅供个人学习和研究使用，禁止用于商业用途。如在使用过程中遇到问题或有任何疑问，请随时联系博主或关注官方渠道，获取技术支持。本设计及源码包含了作者和网络资源的贡献，若有冒犯之处，请私信博主批评指正。

使用protobuf实现序列化与反序列化

       protobuf是用来干嘛的？

       protobuf是一种用于对结构数据进行序列化的工具，从而实现数据存储和交换。（主要用于网络通信中收发两端进行消息交互。所谓的“结构数据”是指类似于struct结构体的数据，可用于表示一个网络消息。当结构体中存在函数指针类型时，直接对其存储或传输相当于是“浅拷贝”，而对其序列化后则是“深拷贝”。）

       序列化：将结构数据或者对象转换成能够用于存储和传输的mbr 源码格式。 反序列化：在其他的计算环境中，将序列化后的数据还原为数据结构和对象。

       从“序列化”字面上的理解，似乎使用C语言中的struct结构体就可以实现序列化的功能：将结构数据填充到定义好的结构体中的对应字段即可，接收方再对结构体进行解析。

       在单机的不同进程间通信时，使用struct结构体这种方法实现“序列化”和“反序列化”的功能问题不大，但是，在网络编程中，即面向网络中不同主机间的通信时，则不能使用struct结构体，原因在于：

       （1）跨语言平台，例如发送方是用C语言编写的程序，接收方是用Java语言编写的程序，不同语言的struct结构体定义方式不同，不能直接解析；

       （2）struct结构体存在内存对齐和CPU不兼容的问题。

       因此，在网络编程中，实现“序列化”和“反序列化”功能需要使用通用的组件，如 Json、XML、protobuf 等。

       ① 性能高效： 与XML相比，protobuf更小（3 ~ 倍）、更快（ ~ 倍）、更为简单。

       ② 语言无关、平台无关： protobuf支持Java、C++、Python等多种语言，支持多个平台。

       ③ 扩展性、兼容性强： 只需要使用protobuf对结构数据进行一次描述，即可从各种数据流中读取结构数据，更新数据结构时不会破坏原有的程序。

       Protobuf与XML、Json的性能对比：

       测试万次序列化：

       测试万次反序列化：

       protobuf 2 中有三种数据类型限定修饰符：

       required表示字段必选，optional表示字段可选，repeated表示一个数组类型。

       其中， required 和 optional 已在 proto3 弃用了。

       protobuf中常用的数据类型：

       下载protobuf压缩包后，解压、配置、编译、安装，即可使用protoc命令查看Linux中是否安装成功：

       使用protobuf时，需要先根据应用需求编写 .proto 文件定义消息体格式，例如：

       其中，syntax关键字表示使用的protobuf的版本，如不指定则默认使用 "proto2"；package关键字表示“包”，生成目标语言文件后对应C++中的namespace命名空间，用于防止不同的消息类型间的命名冲突。

       然后使用 protobuf编译器（protoc命令）将编写好的 .proto 文件生成目标语言文件（例如目标语言是C++，则会生成 .cc 和 .h 文件），例如：

       其中：

       $SRC_DIR表示 .proto文件所在的源目录； $DST_DIR表示生成目标语言代码的目标目录； xxx.proto表示要对哪个.proto文件进行解析； --cpp_out表示生成C++代码。

       编译完成后，将会在目标目录中生成xxx.pb.h和xxx.pb.cc文件，将其引入到我们的C++工程中即可实现使用protobuf进行序列化：

       在C++源文件中包含xxx.pb.h头文件，在g++编译时链接xxx.pb.cc源文件即可：

       在protobuf源码中的/examples 目录下有官方提供的protobuf使用示例：addressbook.proto

       参考官方示例实现C++使用protobuf进行序列化和反序列化：

       addressbook.proto :生成的addressbook.pb.h 文件内容摘要：add_person.cpp :

       输出结果：

       三种序列化的方法没有本质上的区别，只是序列化后输出的格式不同，可以供不同的应用场景使用。 序列化的API函数均为const成员函数，因为序列化不会改变类对象的内容，而是将序列化的结果保存到函数入参指定的地址中。

       .proto文件中的option选项用于配置protobuf编译后生成目标语言文件中的代码量，可设置为SPEED， CODE_SIZE， LITE_RUNTIME 三种。 默认option选项为 SPEED，常用的选项为 LITE_RUNTIME。

       三者的区别在于：

       ① SPEED（默认值）： 表示生成的代码运行效率高，但是由此生成的代码编译后会占用更多的空间。

       ② CODE_SIZE： 与SPEED恰恰相反，代码运行效率较低，但是由此生成的代码编译后会占用更少的空间，通常用于资源有限的平台，如Mobile。

       ③ LITE_RUNTIME： 生成的代码执行效率高，同时生成代码编译后的所占用的空间也非常少。 这是以牺牲Protobuf提供的反射功能为代价的。 因此我们在C++中链接Protobuf库时仅需链接libprotobuf-lite，而非protobuf。

       SPEED 和 LITE_RUNTIME相比，在于调试级别上，例如 msg.SerializeToString(&str;); 在 SPEED 模式下会利用反射机制打印出详细字段和字段值，但是 LITE_RUNTIME 则仅仅打印字段值组成的字符串。

       因此：可以在调试阶段使用 SPEED 模式，而上线以后提升性能使用 LITE_RUNTIME 模式优化。

       最直观的区别是使用三种不同的 option 选项时，编译后产生的 .pb.h 中自定义的类所继承的 protobuf类不同：

       ① protobuf 将消息里的每个字段进行编码后，再利用TLV或者TV的方式进行数据存储； ② protobuf 对于不同类型的数据会使用不同的编码和存储方式； ③ protobuf 的编码和存储方式是其性能优越、数据体积小的原因。

TLVAIC的应用

       åŸºäºŽDDK的TLVAIC型编解码器的驱动设计

       DSP/BIOS Driver Developer’s Kit(DDK)是TI为简化驱动程序开发为TMS系列DSP及其EVM板等提供的驱动程序开发套件。该套件为TMS系列各种外围器件提供完整的标准化驱动程序模型，使得驱动程序可以很方便地移植到其他应用中，大大提高驱动程序开发的效率。DDK是对每种TMS系列DSP都提供的芯片支持库(Chip Support Library—CSL)的补充，CSL提供对外围器件寄存器配置及初始化等的低级控制，DDK完全通过CSL来对外围器件进行控制。简单地说。DDK建立在CSL上层．所以用DDK来开发驱动程序将更为快捷且可移植性更好。

       DDK为开发驱动程序定义了标准模型和一系列的API。为简化程序设计。标准模型又被分为二个层次．其中高层称为Class driver，低层称为Mini—driver。Class drivei与器件相对独立．完成诸如缓冲区管理和请求同步等功能．同时扮演着与API和Mini—driver二者接口的角色。Mini—driver完成特定的器件初始化和控制功能．它符合IOM(I/O Mini—driver)的接口标准。DDK的这种分层结构使得驱动开发人员仅需了解单一的Mini—driver API就可以完成整体外围器件的驱动设计，而且这一过程比设计整个驱动程序要简单得多，因为Class driver控制了缓冲区管理和同步等。DDK提供3种Class driver．分别为SIO/DIO、PIP/PIO和GIO，它们都可以和任何Mini—driver结合使用。

       2 TLVAIC的驱动设计基础

       DDK的标准模型结构如图1所示。高层的应用和底层驱动相互没有直接的关联，开发中只需通过Class driver控制Mini—driver。

       ä¸‹é¢ä»¥DM EVM板为例．说明基于DDK的TLVAIC的驱动程序设计方法。

       é¦–先，需要使用配置工具建立驱动程序的入口。在DSP/BIOS con_fig下的cdb文件中．依次选择In-puffOutplut---Deviee Drivers→User→defined Drivers．在这些例程中一般已经添加了udevCodec．如果需要的话，用户可以自行添加或编辑。右键单击选择Properties选项来编辑其属性，其属性应设置如下：

       Comment：可以加入自己的注释

       lnit function：键入EVMDM_EDMA_AIC一init

       Function table ptr：键入 EVMDM_EDMA_A-IC一Fxn8

       Function table type：选择IOM_Fxns

       Deviceid：该项会被自动忽略．因为DM EVM板上只有一块TLVAIC

       Device params ptr：TLVAIC参数结构的入口指针．使用缺省参数时设为0x0

       Device global data ptr：必须设置为OxO

       æ­£ç¡®é…ç½®é©±åŠ¨ç¨‹åºå…¥å£åŽï¼Žå°±è¦æŒ‰ç…§éœ€è¦è®¾ç½®ç›¸å…³çš„参数。下面具体讨论TLVAIC参数的设置。

       TLVAIC的参数结构体原型如下：

       typedef struct

       åœ¨ä¸€èˆ¬åº”用中。上述结构体的大多数参数无需更改，需要修改的主要是aieConfig．它是TLVAIC控制寄存器值．需要通过它来控制TLVAIC的工作模式、输入/输出选择、采样率等重要参数。

       é™¤äº†å¤ä½å¯„存器外．TLVAIC共有9个控制寄存器．每个寄存器控制字长为9bit．地址位为7bit，共有bit。地址位为高7位而控制字在低9位。具体如下：

       Register0:左声道输入音量控制，缺省值为 0x

       Register1:右声道输入音量控制，缺省值为 0x

       Register 2：左声道输出音量控制。缺省值为OxF9

       Register 3：右声道输出音量控制，缺省值为OxF9

       Register 4：模拟音频通道设置．缺省值为Ox

       Register 5：数字音频通道设置。缺省值为0x

       Register 6：节电模式控制．缺省值为0x

       Register 7：数字音频接口格式控制，缺省值为0x

       Register 8：采样率控制，缺省为kHz，对DMEVM板．缺省值为Ox

       Register 9：数字音频接口激活开关．缺省值为0x

       é€šå¸¸æƒ…况下需要修改的寄存器包括4号和8号寄存器．即选择是由mic输入还是由line in输入和根据需要选择采样率。这2个寄存器的详细配置如下：

       4号寄存器配置见表1，其中，D2位。INSEL(In-put select for ADC)是输入选择，“O”为line in；“l”为mic.D1位MICM(Microphone mute)是mic静音开关．为“l”表示静音。DO位MICB(Microphone boost)如设置为“1”将为mic输入提供dB的增益。8号寄存器配置见表2，其中，采样率控制位为D5~D2的SR[3：O]。对于DM EVM板，设置方式见表3。

       å¯è§ï¼Žéœ€è¦é€šè¿‡4号寄存器的D2来选择输入，同时考虑Dl和DO对mic的控制；采样率的控制通过设置8号寄存器的SR[3：0]来实现。

       3 TLVAIC的驱动配置方法

       å¾ˆå¤šåˆå­¦è€…在运行DM EVM的echo或其他音频例程时，最容易碰到的问题是通过line in输入时有输出．而通过mic输入时没有输出，更不要说改变采样率了。即使参考资料编辑aic-h和emvdm_edma_aic．h修改Dcfauh参数仍然无法解决。

       å‡ºçŽ°è¿™æ ·çš„问题时。首先要了解TLVAIC的模拟音频输入为mic和line in二选一的，其次要知道如何能够正确配置TLVAIC的参数使之满足特定应用的需要。如果仔细分析echo例程和其他音频例程的话，可以发现只有在echo例程中包含了aie.h和emvdm_edma_aie．h 2个头文件。其实在echo例程中．所包含的这2个头文件和TLVAIC的初始化语句实际并未使用。如果屏蔽掉对这2个头文件的包含以及TLVAIC的初始化语句，会发现编译后仍然能够正常运行。实际上echo例程中的TLVAIC初始化语句只是提供了对Ⅱ,VAIC进行配置的一种方法而并未直接使用。该方法在DDK包的emvdm部分说明文件中也已提及。

       ç”±äºŽåœ¨echo例程中初始化驱动程序人口和其他的音频例程一样使用了默认参数，而默认参数是通过调用DDK包中的evmdm_edma_aic．库获得的．该库不变则配置也不变，于是就会出现上述问题。

       åœ¨æ˜Žç¡®äº†ä»¥ä¸ŠåŽŸç†åŽï¼Žé€šè¿‡å®žè·µè¯æ˜Žï¼Œæœ¬æ–‡æä¾›çš„以下三种配置方法可以适应各种应用。

       æ–¹æ³•ä¸€

       æ—¢ç„¶é»˜è®¤å‚数是通过调用evmdm_edlna_a-ic．库获得的．那么自然可以通过修改该库来达到修改参数的目的。TI提供的DDK包中包含了各种库的源代码．这使得修改库文件成为可能。本文用到的库生成工程是tiddksrc\audio\evmdm目录下的evmdm_edma_mc_．pjt，只需要打开该工程．修改其中aic．h中的默认参数，重新编译就能生成新的库文件。这样，所有的音频例程都会默认按修改过的参数运行。

       è¿™ç§æ–¹æ³•é€‚合TLVAIC参数配置相对固定的应用场合。配置完全通过调用evmdm_ed_ma_aic．库初始化时进行．不用在应用工程文件中添加任何附加代码．使得工程文件更简洁．可移植性更高。

       æ–¹æ³•äºŒ

       è‡ªå®šä¹‰ç¬¦åˆæ ‡å‡†ç»“æž„EVMDM_EDMA_A．IC一DevParams的结构体，例如：

       ç„¶åŽå°†â€œ_myParms”作为Device params ptr在指定人口指针时替代默认的0x0。这就符合TI推荐的方法，在echo例程中的相关代码也说明了这种方法。

       è¿™ç§æ–¹æ³•èƒ½å¤Ÿé€‚应几乎任何使用情况，初始化参数自定义非常明确，代码易读性较高。但是不建议像echo例程中那样直接包含默认参数的头文件．最好参照该头文件定义自己的结构体。

       æ–¹æ³•ä¸‰

       é€šè¿‡ä»”细分析生成evmdm_edma_aic．库的源代码，可以发现对TLVAIC寄存器的设置是通过AIC_setParams()函数来完成的。在大多数情况下，只要修改寄存器值而不必修改标准结构EVMDM_EDMA_AIC_DevParams结构体中的其他变量。所以可以调用AIC_setParams()函数来完成对TLVAIC参数的配置。这样就只需要定义1个符合标准的寄存器数组．将数组名作为参数来调用AIC_setParamsf()函数就可以达到目的。

       è¿™ç§æ–¹æ³•ä½¿ç”¨çµæ´»ï¼Œä»£ç é•¿åº¦å¾ˆçŸ­ï¼Œå«ä¹‰éžå¸¸æ˜Žç¡®ï¼Œå¯ä»¥ç”¨ä¸åŒå‚数多次调用．尤其适用于TLVAIC参数可变的特殊场合。

       åœ¨å®žé™…工作基础上对TLVAIC参数配置提出了3种方法，各有特点且都十分实用。在进行基于DDK的TLVAIC驱动程序设计时．可以根据需要方便地选用。