简介Realtek RTD2660HD Ver8.0高清数字电视解码芯片源代码包面向嵌入式开发、机顶盒及数字电视方案工程师可用于驱动移植、功能定制与二次开发。包内共293个文件压缩后约9.84MB以头文件h、C源码c、编译中间文件lst/obj为主另含Keil工程文件uvproj/uvopt与启动代码A51覆盖驱动、固件、中间件及应用层目录结构便于按模块查阅。已有2403人学习下载。借助该源码可了解RTD2660HD的DMA、I2C、视频解码、音频处理等实现细节配合Keil工程快速进行代码阅读、编译与调试适合希望深入掌握该芯片底层机制或进行定制化开发的工程师参考。1. 从砖头板到源代码RTD2660工程里藏着多少东西用RTD2660做驱动板维修的都知道网上能找到的固件大多是已经编译好的bin烧进去能亮但按键乱跳、OSD文字错位、HDMI优先级不对这类问题靠调bin是解决不了的。这套2019年的Ver8.0完整源代码用Keil C51打开就能编译改完直接生成新固件终于不用再猜出厂固件里写了什么。这套代码不是那种只给头文件和库文件的SDK而是一个完整的量产嵌入式工程主循环、信号源检测、HDMI与VGA切换、OSD菜单绘制、按键扫描、背光控制、屏参管理全都有。我把bin固件换成源码编译之后原来三块变砖的驱动板全部救回来后续改按键、改菜单、换Logo都是半小时内搞定的事。适合三类人一是修显示器驱动板但只会烧录固件的维修师傅二是做显示信号板想自己定制菜单和按键逻辑的开发者三是想拿RTD2660当8051实战教材的入门工程师。源码到手只算一半真正值钱的是知道从哪几处开始改以及每个功能模块的边界在哪里。2. 源码目录与Keil工程先认清单再动手编译拿到完整的显示驱动板源代码工程第一步不是急着改代码而是先弄清这个SoC的性质、工程目录的模块划分以及编译环境怎么搭。这几件事没理顺后面改任何东西都会在编译阶段反复卡住。2.1 RTD2660方案到底是一颗什么样的SoCRTD2660是显示器驱动板时代相当常见的一颗单芯片方案。它内部是一个增强型8051内核再加HDMI接收前端、VGA ADC、视频处理通路、LVDS/TTL输出、I2C主从控制器和PWM输出。MCU部分负责跑代码视频通路需要MCU通过I2C总线去配置内部各功能模块的寄存器才能正常工作。所以你会看到这套源代码里有大量I2C读写代码这不是冗余而是这套方案的常态。MCU通过I2C访问HDMI接收器的寄存器、回读信号锁定状态、配置EDID甚至通过I2C从机模式让外部工具直接读写MCU内存这些都是这套代码里实际存在的机制。选型上相比外置MCU加独立HDMI接收芯片的做法RTD2660把控制和接收集成在一起BOM成本低做显示器板和电视板良率高。这也是为什么直到今天二手驱动板和公版驱动板里还能大量看到这个型号。需要注意这包代码的编译目标不是通用8051而是拥有扩展XRAM和Code Bank的增强型8051。在Keil里不能直接选AT89C52通常选择Generic 8052再手工打开扩展存储支持内存模型按Large模式处理。如果你打开工程后发现FLASH占用只有几KB多半是内存模型或Code Bank配置没有对齐原工程而不是代码本身就这么小。2.2 工程目录结构哪些文件是编译器看的哪些是产线用的这类驱动板源工程通常按功能模块划分目录2019年的Ver8.0整体框架很清晰。核心模块整理成下表模块目录作用需要修改的场景Main主循环、任务调度、中断初始化改开机流程、功耗、背光时序Source信号源检测、HDMI/VGA切换改信号优先级、切换延时OSD菜单树、绘制函数、字符串表改菜单文字、加功能项、换LogoKey按键扫描、ADC定标配不同按键板Panel屏参表、面板初始化序列换面板、改分辨率AudioI2S输出、音量曲线改默认音量、静音逻辑Config条件编译开关、引脚定义改按键板类型、是否带音频Font字库点阵、OSD字体定义改菜单语言、换字库需要特别强调的是Config和Panel这两个目录才是真正决定驱动板能不能点亮屏幕的地方。很多编译错误的根源不是代码本身有问题而是不同模块之间通过宏定义开关联动的功能没有配对。2.3 搭建Keil C51环境并完成第一次编译编译环境搭建这块按下面流程走可以说是这个场景下最稳妥的路线安装Keil C51这个工程是2019年的用的是C51编译器不要装成MDK-ARM版本否则打不开工程。把整个源码包复制到纯英文路径例如D:\rtd2660_src。C51对中文路径和空格的处理比较弱路径不对会直接导致一堆头文件找不到。双击打开主工程文件rtd2660.uvproj等待工程树加载完成。在Options for Target的Device选项卡里确认芯片型号是Generic 8052如果原工程带厂商的设备包则优先用原设备包。Memory Model选择LargeCode ROM Size按原工程配置确认。常见是64KB以上对应工程里启用了Code Bank切换机制。执行Build。编译完成后先看输出窗口里每个源文件的Code大小再检查生成的HEX文件尺寸。确认编译生成的固件大小是否正常可以用下面的命令ls -lh output/rtd2660.hex output/rtd2660.bin # 如果bin只有几KB先检查启动文件和中断向量定义有没有参与链接 # 正常这类完整工程的bin至少在几十KB到几百KB之间逻辑说明这条命令分别列出HEX和BIN两个文件的大小。BIN通常是编译器或脚本从HEX转换出来的烧录文件。如果固件体积明显异常问题基本出在链接定位上而不是编译警告。提示第一次编译之后别急着烧录。先把原厂固件从驱动板的SFlash里备份一份保存到本地。之后无论改什么都保留一个能在原屏上点亮的基准固件。这东西就是折腾驱动板的后悔药屏参改坏、字库改花随时可以刷回去。3. 三处必改的代码位点按键扫描、信号源优先级、背光控制驱动板定制需求里改得最频繁的三个位置分别是按键板、信号源切换顺序、背光亮度曲线。这三处分别对应源码里的按键扫描任务、信号源检测逻辑和背光PWM配置表。先把这三块吃透其他功能模块的改动就有章法了。3.1 ADC按键定标按键错乱先看阈值表RTD2660驱动板上的按键很少用矩阵管脚大多数公板方案都用一颗电阻分压网络把五六个按键接到同一个ADC脚。按下不同按键分压不同MCU读到的ADC值就不同。源码里的按键扫描任务会维护一张阈值表把ADC读数映射成对应的键码。常见的代码结构是这样的typedef struct { unsigned int adc_min; unsigned int adc_max; unsigned char key_code; // 对应 KEY_MENU / KEY_UP } ADC_KEY_T; const ADC_KEY_T key_table[] { {0, 400, KEY_NONE}, // GND短路或悬空按位AD值 {400, 1000, KEY_MENU}, {1200, 1900, KEY_UP}, {2100, 2700, KEY_DOWN}, {3000, 3800, KEY_EXIT}, {4000, 4500, KEY_SOURCE}, }; #define KEY_TABLE_CNT (sizeof(key_table)/sizeof(ADC_KEY_T))逻辑说明key_scan任务周期性调用ADC读取函数把读到的10位ADC值与表内的区间逐个比较落在哪个区间就触发对应的键。KEY_NONE这个表项并不是多余设计它用来吸收按键板悬空或信号浮空时的误触发。参数说明与坑10位ADC的满量程是0到1023所以表里的数值单位是LSB不是电压。实际板上电阻阻值误差、参考电压漂移都会导致ADC读数偏移尤其相邻两个键的区间不能贴着分界摆。我一般会先实测每个按键按下后的ADC读数然后取相邻按键读数中点作为分界每档之间再留30个LSB左右死区。如果出现“按下按键A偶尔识别成按键B”九成不是硬件坏了而是阈值区间太窄或者死区被填平了。如果按键板不是ADC分压而是GPIO矩阵那源码对应的要改的是Key目录下的读IO电平函数而不是这张ADC表。判断方式很简单看驱动板按键旁边有没有三颗以上的分压电阻有就是ADC方案。3.2 信号源优先级HDMI插上就想抢占的切法显示器驱动板一般同时有HDMI和VGA两个输入。source_detect任务会周期性轮询两个输入口的信号锁定状态代码里通常维护一张初始化顺序表typedef enum { SRC_NULL 0, SRC_HDMI, SRC_VGA, } SRC_ID; const SRC_ID source_seq[] { SRC_HDMI, SRC_VGA }; const unsigned char source_default SRC_HDMI;逻辑说明source_detect常见逻辑是循环查看每个源对应接收通道是否锁定信号锁定之后还要确认HPD热插拔检测有效才会切换到该源。如果当前源信号消失系统不会立刻切换而是要等一个去抖延时这个延时一般在几十毫秒到几百毫秒之间由源码里的delay_ms参数控制。修改顺序其实很直观把source_seq数组里的顺序对调就是让VGA优先把source_default改成SRC_VGA就是冷开机默认进VGA。但要注意source_default只影响冷启动时的初始状态不影响热插拔抢占逻辑。热插拔抢占通常单独实现在HPD中断处理函数里例如hdmi_hpd_handler它接收到HPD跳变后会直接强制切换HDMI。如果改了优先级却发现插入HDMI仍然停留在VGA多半是HPD中断处理分支里硬编码了SRC_HDMI跟source_seq的顺序已经不匹配。查代码的时候看到if(HPD_LEVEL HIGH)这种条件判断多留意else分支优先级抢不回去的问题经常藏在里面。3.3 背光PWM亮度曲线与最低亮度背光控制改动看起来简单实际上踩坑率很高。源码里的背光功能通常提供0到100档亮度每档映射一个PWM占空比存放在一个全局数组里const unsigned char backlight_curve[101] { 6, 8, 12, 15, 20, 25, 32, 40, 50, 62, 75, 85, 95, 100, 100, 100, /* 以上为示意曲线 */ ... };参数说明第一档不要直接设成0这是这套方案下驱动板最容易犯的错。很多升压IC在占空比接近0时会误判为关闭导致亮度最低档直接黑屏。所以0%档实际给6%左右的占空比保证背光最低亮度不会熄灭。如果换了背光驱动板还要检查两件事PWM输出极性是否匹配PWM频率是否落在驱动IC的接受范围内。频率一般在20kHz左右太低了会有可闻啸叫太高了驱动IC反而可能响应不及时。改频率时找背光定时器的预分频寄存器不要改PWM的占空比表否则亮度曲线会整体偏移。这块最简洁的做法是只调前五档的曲线斜率后段保持平坦。大多数使用场景下用户感知最敏感的是低亮度区间的细腻度高端区间100%到底就够用了。4. OSD菜单与屏参表改出自己品牌的中文菜单OSD菜单和屏参表是定制驱动板时最耗时、最出彩的两个地方。菜单要改到自己品牌的文字屏参要跟实际面板严格匹配。这两块涉及的数据结构多改之前必须把代码里的组织方式看透。4.1 OSD菜单结构从菜单项到字符串的映射OSD菜单在代码里不是一个个散落的绘制函数而是一棵静态的菜单树。每个菜单项由结构体数组描述条目字段包括菜单ID、字符串索引、条目类型和子菜单索引typedef struct { unsigned char item_id; unsigned char str_index; unsigned char type; // OSD_ITEM_VALUE / OSD_ITEM_ENTER unsigned char sub_menu; } OSD_ITEM; const OSD_ITEM main_menu[] { {0, STR_BRIGHTNESS, OSD_ITEM_VALUE, 0xFF}, {1, STR_CONTRAST, OSD_ITEM_VALUE, 0xFF}, {2, STR_OSD_SETTING, OSD_ITEM_ENTER, 0x10}, {0xFF} // 结束标记 };逻辑说明OSD任务遍历这个表取出每一项的str_index再到字符串表里取出对应文本按字库规定的尺寸画到缓冲区。最后一条0xFF是结束标记遍历到它就停止绘制。修改时最容易遗漏的是增删菜单项之后字符串表里的总数没同步或者菜单深度超过代码里定义的数组上限结果菜单尾部多出一个空行或者光标选中项和实际执行项错位。不同工程里还有一种写法是把字符串指针直接放进OSD_ITEM结构体里不用索引。这两种写法在改代码时差别不大但调试时要分清楚不能按索引表去查指针型工程否则会读出乱码。4.2 中英文字库为什么显示方块与半字OSD文字用的不是矢量字体而是点阵字库。源代码里font数组存放每个字符的点阵数据中文常用16x16英文常用8x16。新增一个中文字符需要按特定取模方式把字模加到字体数组中并在字符串表应用该字模。以下是一段示意代码展示中文字模在源码中的存储格式// 以16x16英文点阵示例 const unsigned char code font_cn[] { 0x00, 0x00, 0x7F, 0xFC, ... }; #define CN_HEIGHT 16 #define CN_WIDTH 16 #define CN_BYTES (CN_WIDTH * CN_HEIGHT / 8) // 等于32逻辑说明每个16x16汉字在数组里占32字节按逐行扫描的方式排列。取模工具输出时如果选错方向画面就会出现对角线撕裂看起来像字库整体错位。参数说明最坑的是取模方向。显示器OSD字库常见的是逐行式、低位在前也就是从左到右一行一行取位取满两行组成一个字。有人用串口屏的取模习惯选了逐列式结果中文字全部旋转了90度或者出现镜像。半字的出现就更隐蔽。中文按16点阵宽度计算英文按8点阵宽度计算同一行里混排时坐标推进必须对两种字符分别处理。如果代码里只按固定宽度推进就会出现“菜”字半个字被切走的怪象。这类问题不要急着改字体数组先检查折行和坐标推进逻辑通常一两行代码就能解决。4.3 屏参表与初始化时序从面板手册到结构体屏参表是驱动板点屏的核心依赖。启动时MCU读取面板参数并据此配置输出时序。代码里的屏参结构体大致长这样typedef struct { unsigned short h_active; // 水平有效像素 unsigned short v_active; // 垂直有效行数 unsigned short h_total; // 水平总像素 unsigned short v_total; // 垂直总行数 unsigned char h_front_porch; // 水平前沿 unsigned char h_back_porch; // 水平后沿 unsigned char h_sync_width; // 水平同步宽度 unsigned char v_front_porch; unsigned char v_back_porch; unsigned char v_sync_width; unsigned char h_sync_polarity; // 0正 1负 unsigned char v_sync_polarity; unsigned char lvds_bits; // 6bit或8bit unsigned char lvds_channel; // single或dual } PANEL_TIMING;参数说明h_total不是面板手册直接给的值而是h_active加h_front_porch加h_sync_width加h_back_porch之和。像素时钟等于h_total乘以v_total再乘以帧率。有些面板手册同时标注了clock和total可以直接用但很多老面板手册只给porch和sync需要自己算。改屏参时只改分辨率数值是不够的LVDS位宽错了画面会有色斑或整体偏色通道数配置错了直接花屏。所谓“同型号屏”实际上有6bit和8bit两个批次很常见驱动板软件里的even/odd映射表需要逐项对照面板手册的走线定义。建议改屏参时保留原屏初始化列表的备份新面板点不亮时更理性的排查顺序是先确认驱动板输出的LCD电源电压、VGL/VGH电压与面板匹配再回头查时序。不少驱动板点不亮是供电条件不满足导致的不是代码问题。5. 避坑排查编译报错、花屏错键与无背光的五个现场驱动板源码项目的坑集中在两段编译烧录阶段上电显示阶段。下面是这几个月在RTD2660工程实战里遇到最多的五个现场每一条都是实打实的血泪经验。5.1 编译与烧录阶段环境与链接问题坑1Keil打开工程一次性报几十个找不到头文件错误。现象C文件和H文件明明就在同一级目录编译器却报找不到头文件整个输出窗口全是红色。原因工程文件里保存的Include路径是原作者机器上的绝对路径换电脑后完全失效。如果原路径带中文用户名C51的预处理器对中文路径支持很差即使重新指定路径也可能继续报错。解决把整个工程复制到纯英文绝对路径下例如D:\rtd2660_src然后在Options for Target的C51选项卡里删除旧的绝对路径重新添加相对路径“.\src”和“.\inc”。如果电脑当前登录用户名是中文建议直接用D盘根目录建一个新工程文件夹不要放在用户目录下。坑2编译能通过但生成的HEX只有2到3KB烧进去板子没有任何反应。现象编译0错误0警告但你清楚这套代码不可能只占这么点空间。查看生成的HEX大小发现只有几KB。原因链接脚本的code segment被限制在一个很小的空间或者Code Bank机制没有被正确打开。启动文件、中断向量、多个源文件的代码段没有全部链接进来。解决先看Keil输出窗口里每个源文件的Code大小。如果只有个别文件参与了链接多半是Target选项里Code Rom Size设成了2KB这种过小值或者工程里代码分段定位写错了。把Code Rom Size改为64KB以上打开Extended Code Bank选项再重新编译。正常编译后这个工程的BIN应该在几十KB到几百KB之间低于10KB基本都不正常。5.2 上电后的显示与按键问题坑3上电白屏但背光亮工厂模式的彩条却能正常显示。现象背光正常、无图像但进入工厂模式后彩条能完整显示出来换到正常信号画面就是白屏。原因面板本身能出图说明TCON和屏参基本正常。问题出在视频处理通路的输入窗口与输出窗口不匹配或者EDID固件里的活动区定义与屏参不一致。解决先进工厂模式确认彩条正常然后用I2C工具读取EDID重点看显示器名称和活动区描述。接着在源码里找到scaler相关的输入窗口结构体把输入分辨率宏和输出分辨率宏都统一改成面板实际分辨率。常见错误是在配置里同时定义了两个分辨率比如宏PANEL_1920_1080和PANEL_1680_1050都打开了代码默认优先走其中一个导致输出被限制。坑4HDMI输入周期性闪屏画面每隔几秒黑一下VGA输入正常。现象HDMI每隔几秒闪一下黑屏声音同时断断续续VGA画面完全正常。原因HDMI接收器的EDID没有正确发给显卡显卡输出参数跑出了面板可接受范围或者代码里对HDMI初始化寄存器被重复调用导致HDCP或EDID状态机反复复位。解决使用I2C调试工具把代码中外挂存储器里的EDID读出来确认128字节的checksum正确。如果EDID头两个字节不是00 FF说明EDID根本没写进去。如果EDID没问题检查工程里是否在main初始化阶段调用过一次hdmi_init而source_detect函数里又调用了一次同类初始化。重复初始化是闪屏最常见的代码层原因。坑5按键串键严重快速连按的时候尤其明显。现象按下“加”键偶尔识别成“减”键快速操作时串键概率更高。原因ADC按键扫描只做了一次采样没有做数字滤波加上阈值表区间之间没有死区导致按键抖动时ADC读数快速跳动落到邻近区间。解决找到key_scan函数把每个按键的ADC采样次数从1次提高到8次取平均值或者中位数作为最终读数。然后检查阈值表给相邻按键区间补上至少30LSB的死区。如果按键板电阻分压设计本身就靠得太近还要实测每个按键的ADC值与理论值的偏差调整分压电阻配比。另外按键板上RC滤波电容如果容值过大ADC建立时间不够快速连按就会识别错。解决办法是在ADC采样前延时2到5毫秒但要注意把这个延时放到按键任务自己的循环里不要阻塞OSD刷新。6. 最后一招用Logo替换与工厂模式验证整机固件改完最后一个有成就感的地方是开机Logo。这里给出从BMP图到替换源码数组的完整流程以及验证整机逻辑的工厂模式用法。6.1 替换开机Logo的完整流程替换Logo的核心是把一张图片转成C语言数组然后找到源码里对应的常量数组替换掉。操作步骤如下准备一张BMP位图尺寸和屏分辨率按比例缩放建议纯色背景简洁图形避免细线条在点阵化后糊成一片。打开取模工具选择输出C语言数组颜色格式按源码里原Logo数组类型来定。多数RTD2660工程用unsigned int数组也就是RGB565也有的用ARGB1555最高位是透明标志。取模方向选择逐行式、低位在前长宽按16的倍数向上取整不够的补黑边。在源码里搜索logo数组的名称找到数组定义及宽高宏定义// 替换前 const unsigned int code boot_logo[] { 0x0000, 0xFFFF, ... }; #define LOGO_W 320 #define LOGO_H 128参数说明RGB565格式下每个像素占16位高5位为红色、中6位为绿色、低5位为蓝色。ARGB1555模式下最高位为透明标志选错颜色格式时画面会出现整体偏蓝或偏紫。替换数组之后若屏幕显示的颜色不对优先检查取模工具的颜色格式设置不要怀疑面板坏了。透明色处理是第二个坑。部分工程用ARGB1555的最高位做透明有的工程把某个具体颜色值定义为透明两种方案不能混用。替换后如果出现整块底色盖住画面说明透明色方案和代码不匹配。6.2 用工厂模式验证整机别信屏参玄学驱动板代码几乎都保留了工厂模式入口常见激活方式有开机时长按某键、普通菜单里连续按退出键五次等。工厂菜单里通常有彩条、白场、老化模式、版本信息和自动调整功能。我的习惯是每次改完代码固定走四步验证流程第一步烧录后先进工厂模式切彩条输出确认面板没有花屏和色斑。第二步来回拔插HDMI和VGA信号各开关三次确认热插拔切换和信号优先级符合预期。第三步进老化模式至少跑15分钟观察是否有随机黑屏或背光闪烁。第四步把亮度调到最低档确认背光灯没有熄灭再调到最高档确认电流没有过载。从那以后我每次拿到新的RTD2660驱动板都会先看一眼源码版本号再进工厂模式跑一遍彩条和老化确认屏参没匹配错才把固件交给产线。与其相信屏参玄学不如让屏幕自己说话。希望帮到你。本文还有配套的精品资源点击获取