HDMI回顾

    今天有空看了一下MStar的HDMI Transmitter的source code。两个月前用过了SIL的HDMI Transmitter9030,正好有个机会做个比较。

    一般来说芯片商建议的HDMI Transmitter player方案主要是由是一块MCU+一块Transmit芯片,其中那块MCU是用来配置HDMITX,以及与player的解码主chip进行通讯的。在播放过程中,我们可以通过主动和被动的模式来配置HDMI的输出,主动地模式是由那块MCU与player的MPEG decoder通过异步通讯等到更新的video resolution和audio referenceclock,从而对Transmit芯片进行配置。被动模式则由MCU去读取HDMITX内部的一些寄存器,例如Pixel Clock的值和Video resolution的值(640X480,720X480等),以及Sync的极性,根据变化来配置HDMITX,而HDMITX则是从输入信号上采样等到这些数值,用于进行HDMI输出编码。

     因此不管做哪一个方案,我得到的sourcecode都是51单片机的代码,老YU说看别人的代码是长经验的(同意),这次我也总算温习了一把忘得差不多的单片机coding技术了。

所以先讲一点51的基本知识,也算是自己回顾一下

1.MCU51内部有4K的程序存储器,如果在实际运用中内存不够的话,可以在此基础上扩展到64K大小,对于程序员来讲,无论是内部的EPROM,还是扩展的程序存储器是没有什么区别的,在MCU内部有一个十六位的程序记数器PC可以寻址片内及片外的EPROM。

 

2.MCU51有128字节的RAM(data变量),也可以外接RAM电路,是数据存储器的容量达到64K字节

 

3.8051 特有的数据类型的定义

 

code    以 MOVC @A+DPTR 读取的程式

看到这个熟悉的DPTR寄存器。让我想到了80386中的GDTR跟LDTR,当然后两个是CPU中的段描述表寄存器,是在段式内存管理中用来查询段描述表指针跟段寄存器的,而DPTR则是由DPH(8bit)跟DPL(8bit)组成的16bit直接寻址寄存器。

 

data    可以直接存取的內部RAM

        固定指前面0x00-0x7f的128个RAM,可以用acc直接读写的,速度最快,生成的代码也最小。而从0x80开始到0xff的RAM都被定义成了MCU的设备寄存器,例如P0,P1之类的

idata    以 Mov @Rn 存取的內部RAM

固定指前面0x00-0xff的256个RAM,其中前128和data的128完全相同,只是因为访问的方式不同。idata是用类似C中的指针方式(我们用来声明程序段内的局部变量,因此是用寄存器Rn来存取)

bdata    可以位元定址(Bit Addressable)的內部RAM

         个人认为像C中struct里面的位元定址

xdata    以 MOVX @DPTR 存取的外部RAM

一般指外部0x0000-0xffff空间,所以要用DPTR的16位寻址(我们用来存放大量的全局变量,放在外部的扩展mem内)

pdata    以 MOVX @Rn 存取的外部RAM

         指外部扩展RAM的低256个字节,据说C51对这个有Bug,不推荐使用

 

4.还有一些特殊的地方就是

 srf,定义一个8位的设备。

srf16,定义一个16位的设备。

sbit,定义一个位的设备。

用这些语句定义后,就可以在C中象汇编一样使用这些硬件设备。

 

讲完前面的一大段“荡~~~气回肠”的介绍之后,我来谈谈自己对使用这两款芯片的体会。

首先要感慨一下美帝的强大,SIL的芯片模块清晰,使用起来如石上清泉,松间明月般沁人心脾,80pin的PQFP封装,薄薄的一小片低功耗chip提供了强劲的从480i到1080i,从32KHz到192KHz,Video/Audio编码加密的功能。

而且比较有特色的是它的内部集成了一个I2C的逻辑,接管了DDC总线的通讯,加上那些secret keys都是存在片内的memory内,从而在进行HDCP(High-bandwidth Digital Content Protection System)的密钥的计算和交换时变得更加方便与安全。

回头看看Mstar 的TX,由于集成了一个video ADC在里面,芯片的体积大了很多(估计因为模拟的逻辑很占面积)。增加Video ADC的优点在于使模拟输入->HDMI输出成为了可能,从而可以提供更多的方案供player的生产商选择,但是缺点也很明显,模数转换部分的加入打乱了整体的结构,光看register map就给人一种乱哄哄的感觉。不过最让人faint的是它的cipher keys calculation部分竟然是放在chip外面来做的,而且将那一堆secret keys放在一个外部的RAM里面,丫也不怕被人拿去做破解用(虽说肯定是再次加过密的),且不说这些,光那些key的选取、计算,都要耗去多少MIPs,实在是对系统资源的无情的榨取。

再看看代码,更加体现出SIL作为HDMI标准的制定者之一的优势来。那个在SIL写code的俄罗斯老头思路清楚,代码简洁,通篇甚至看不到指针的使用,程序的流程非常直观(不过有个很明显的逻辑bug被我发现,不知道给我的是不是full released版本)。而MStar的代码就有点乱了,全局variable、struct一大堆,判断条件很多都是if(condition1&& condition2&& condition3…),sigh,这咋让人整啊,给人的印象是对HDMI理解不是很深刻,require strong intellect of HDMI。

不过作为一家台湾的design house,在那么短的时间内,设计出可以商业应用的HDMITX,赶上美日,我为自己的中国同胞感到自豪。赞,希望他们tapeout的下一版能越来越好,越来越强。

最后谈一下HDMI的输出效果,可能这也是大家最关心的部分,通过在一台2000美刀的带HDMI输入的Panasonic LCD上数周的调试,与分量端子输入相比较,我可以很确定的告诉大家,HDMI输出很清晰,价格也很贵,普及还需时日。

 

:关于HDCP,顾名思义,它是一个用来对数字信号进行加密的系统,在我看来老外们实在是放心不下他们版权,挖空心思想出这种高级的算法来,就是为了防止高清的视音频的信号在传输过程中被抓取,直接灌成盗版。在DVI接口设计的时候就有了该系统,但是只是一个optional的功能,现在则被强制加到了新一代的高清数字接口HDMI上,作为一个HDMI标准的一部分。想当初模拟的时候有MacroVision一样,保护版权就像是他们的立命根深一般。

HDCP的基本原理是这样的,每个HDMI的设备有一独一无二的KSV(Key Selection Vector),通过该vector从一个Device key array中得到自己的唯一的Secret Device key,再通过该key生成一系列encrypt keys来进行加密(是对每个pixel进行加密哦),然后每隔2s左右还要变换一次encrypt keys,DDC bus的作用就是协调这些密钥的更替与交互。

  • 0
    点赞
  • 0
    收藏
  • 打赏
    打赏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论 2

打赏作者

enigmaboy

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值