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格式并输出到扬声器。xilinx源码破解视频发送部分，使用静态彩条作为源数据，通过SMPTE SD/HD/3G-SDI IP核编码，并由GTX进行串化，GV芯片增强驱动，最终通过SDI转HDMI盒子显示。

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

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

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

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

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

       protobuf是用来干嘛的？

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

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

       从“序列化”字面上的理解，似乎使用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驱动程序设计时．可以根据需要方便地选用。