简介RTD2660 是一款面向液晶屏与 OLED 屏显示控制的高性能微控制器这个压缩包提供的是它的完整源代码适合从事固件开发、显示驱动调试以及学习嵌入式底层原理的工程师与爱好者可支撑二次开发、功能修改和故障定位。压缩包中一共有 184 个文件以 c 语言源文件和 h 头文件为主其中源文件有 54 个头文件有 87 个另外还包含启动汇编代码、可烧录的固件文件、工程配置文件以及位图图片等辅助内容压缩后体积只有 1.62 MB整体目录清晰适合直接阅读和编译。通过阅读这些代码可以清楚看到 RTD2660 在开机时如何配置寄存器、建立通信接口、管理显示内存也能够针对显示异常做排查对显示参数做精细调整还能把驱动移植到 Linux 或 RTOS 等系统上运行是很有价值的实践参考。已有 732 人浏览学习建议结合数据手册从启动代码和基础驱动读起再逐步进入中断处理、任务调度、内存管理等嵌入式核心内容从而建立完整的显示控制知识体系。1. 拿到 RTD2660 源码先分清它到底能改什么如果你手头有块 RTD2660 的显示器驱动板或者想把一块老屏用 HDMI 点亮那么 “RTD2660 source code” 这类源码包就是比 Datasheet 更容易走通的路。RTD2660 是瑞昱面向低成本显示器的双输入主控VGA、HDMI 都收核心是一颗 8051所以它的源码结构和调试方式跟 Linux 驱动完全不同没有内核只有裸机工程、寄存器宏和一套离不开 SPI flash 的启动流程。这类包解压后通常叫 RTD2660-master目标不是让你看穿整套方案而是让你能换 EDID、改 OSD 文案、调屏参、点自己手里的面板。适合三类人做便携屏和驱动板的硬件工程师、修驱动板的老手、想用低成本板子做复古显示输出的玩家。下面从源码结构讲起落到可复现的编译、改参和烧录。2. 从 RTD2660 源码包定位启动流程与编译工具链2.1 先解读目录boot loader、主程序、OSD 数据在哪个文件解压 RTD2660-master(1).zip 后常见的目录层级是 app、drv、osd、fls、include 这几个。我一般不会急着看 app/main.c而是先看 fls 目录里跟 SPI flash 读写相关的文件以及 boot 段代码因为 RTD2660 的启动顺序是 boot loader 先从 flash 里读出段地址再跳到主程序段执行。把文件分类看清楚后面改参数时才不会改错对象主循环逻辑通常在 app 目录下的 main.c 和 video 相关文件里drv 里是 I2C、GPIO、内部寄存器的封装osd 目录下是菜单字库、菜单结构体和按键处理。网上流传的 RTD2660 源码包多半会把 EDID 默认值放在一块独立 C 数组里而板上的 24C02 EEPROM 才是实际首选的 EDID 来源这个关系在第三部分会重点讲。文件/目录典型内容改它的目的app/main.c主循环、分辨率检测状态机调整初始化顺序、加自定义逻辑app/video_*.c输入源切换、PLL 配置修 HDMI 握手、调 RGB 输出范围drv/gpio.c管脚复用、上下拉配置适配按键板、读 EEPROMdrv/i2c.cI2C 读写封装读取 EDID、操作音频/控制信号osd/osd_*.c菜单项、字库、字符串表改菜单语言、加自定义字符串fls/flash_*.cSPI flash 读写和加载理解固件分段方式、做整片备份判断一个源码包能不能直接用我习惯先看 fls 里的 flash 地址映射表。RTD2660 的固件通常分成 code 段、OSD 数据段和 dataload 段各段烧录地址不同。如果只有源码没有地址映射编译出来也没法手工合成可烧录的 bin这时候要么找原配烧录工具要么自己按 boot loader 的段表拼包。2.2 8051 内核决定了编译器和内存模型怎么选RTD2660 的数据手册和源码注释里都明确写了它是 8051 兼容内核这意味着编译器只能在 Keil C51 和 SDCC 之间选。原厂工程一般是 Keil 的 .uvproj编译器是 C51.exe配合 BL51 链接器想在 Linux 上做自动化编译SDCC 也可以编但要注意两点。第一源码里大量通过 sbit 直接声明 SFR 位地址SDCC 的语法是__sbit __at (地址)跟 Keil 不同批量替换时要小心地址别对错。第二内存模型的选择比普通 MCU 更敏感RTD2660 的裸机程序经常直接操作 xdata 和 code 区而 SDCC 默认的 small 模型会把局部变量放 dataRAM 一旦不够编译能过但运行时会随机死机。内存模型变量默认位置RTD2660 上的风险smalldata内部 128B变量溢出覆盖寄存器组largexdata外部扩展所有变量访问变慢但稳定混合code/idata/xdata 手工指定最贴近原厂工程的习惯在原厂工程里xram 大小经常定义成 1024 或 4096对应板载 SRAM 颗粒或主控内置容量。不要贪大随便往上加加大会导致 startup 初始化时把内存清出原有范围表现是上电花屏或按键无响应反而更难排查。提示如果看到#pragma NOAREGS这类预处理指令说明该文件需要关闭寄存器绝对寻址改成 SDCC 时要整体检查一遍否则 GPIO 读写出错。2.3 用 Keil C51 命令行走通最小编译没有原厂 IDE 时命令行也能完成编译。常见做法是把工程里的源文件列表导出来用 C51.EXE 逐个编译成 .obj再用 BL51.EXE 链接。最小命令如下C51.EXE app/main.c DB OE PL(65) BROWSE DEBUG OBJECTEXTEND C51.EXE drv/rtd_gpio.c DB OE PL(65) C51.EXE drv/rtd_i2c.c DB OE PL(65) C51.EXE osd/osd_menu.c DB OE PL(65) BL51.EXE main.obj, rtd_gpio.obj, rtd_i2c.obj, osd_menu.obj TO rtd2660.abs XDATA(0x0000-0x1FFF) CODE(0x0000-0x7FFF) RAMSIZE(256)这里的DB表示生成调试信息OE是对象扩展PL(65)把 char 默认按 signed char 处理跟源码里大量使用 int8_t 的习惯保持一致。BL51 里的 XDATA 范围要跟板子实际 SRAM 匹配CODE 范围对应主控可寻址的 flash 空间链接报 L107 或 L128 溢出时先查这两行而不是去删业务代码。在 Linux 环境或者不想碰 Keil 授权的情况下SDCC 的等价方案是用 Makefile 把编译、转 hex、转 bin 一次做完TARGET rtd2660.ihx SRCS app/main.c drv/rtd_gpio.c drv/rtd_i2c.c osd/osd_menu.c CC sdcc CFLAGS -mcs51 --model-large --iram-size 256 --xram-size 4096 --code-size 32768 $(TARGET): $(SRCS) $(CC) $(CFLAGS) $(SRCS) -o $ packihx $ rtd2660.hex objcopy -I ihex -O binary rtd2660.hex rtd2660.bin这段 Makefile 里--model-large让局部变量默认落在 xdata是内存紧张场景下的保守做法宁可慢一点也不要溢出--code-size 32768对应 32KB code 区改成比自己 flash 大的值不会提高能力反而让链接器以为空间够用。最后两步把 Intel HEX 转成 bin是为了适配大多数 ISP 烧录工具因为不少工具只认纯二进制。3. 在 RTD2660 源码里改 EDID 和输出时序参数3.1 找到 EDID 数据块是查 EEPROM 还是查代码表RTD2660 的 EDID 往往不由源码直接决定而是板载一颗 24C02 或 24C04 EEPROM上电后由主控通过 I2C/DDC 读取。常见的源码包里会附带一个 edid.h 或 panel_edid.c里面是 128 字节数组用途是 EEPROM 为空或校验失败时的兜底数据。逻辑上一般是先尝试读 EEPROM成功且 checksum 通过就用外部数据否则 fallback 到内置表。改 EDID 之前先确认你要改的是哪一份只改源码数组而 EEPROM 里已有一份旧数据你会发现重新编译烧录后读出来的 EDID 毫无变化这是改 EDID 时最容易踩的坑。EDID 数据块在源码里的样子大致如下/* edid_builtin.c */ const unsigned char code default_edid[128] { 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, /* header */ 0x49, 0x23, /* vendor: RIC15bit 编码 */ 0x00, 0x00, /* product code */ 0x01, 0x00, /* serial */ 0x01, 0x03, /* version 1.3 */ /* ... 中间是基本显示参数和色度数据 ... */ /* offset 54 开始是 4 个 Detailed Timing Descriptor */ };这里的code关键字表示数组存放在 flash 而不是 RAM对 8051 来说是为了省 data 空间。改 EDID 时要清楚manufacturer 和 product code 走的是旧协议里的 15 位压缩格式不是直接填 ASCII想改成自己公司的 ID 时得先按协议编码不要凭直觉填字符。3.2 修改 1366x76860Hz 的详细时序描述符EDID 128 字节里从 offset 54从 0 计数开始是 4 个 18 字节的详细时序描述符其中第一个 DTD 一般描述首选分辨率。以 1366x76860Hz 为例pixel clock 是 85.5MHz水平有效 1368水平 blank 160垂直有效 768垂直 blank 26。这里有个多数人不知道的细节1366 不能被 8 整除而 EDID 的 horizontal active 虽能表达任意 12 bit 数但大量老显卡驱动解析时对 1366 这种非 8 对齐值处理有问题所以驱动板固件里普遍把水平有效值设成 1368多的 2 个像素算在 blank 里画面实际显示的仍是 1366。改 DTD 前我习惯先用一段 Python 把时序算好再回去填二进制而不是对着 EDID 字节瞎猜h_active 1368 # 实际使用 1368画面显示 1366 h_blank 160 v_active 768 v_blank 26 pixel_clock 85_500_000 h_total h_active h_blank v_total v_active v_blank frame_rate pixel_clock / (h_total * v_total) print(frefreshrate: {frame_rate:.3f} Hz) print(fh_total: {h_total}, v_total: {v_total})这个脚本算出来的结果应该在 59.94Hz 附近符合 VESA 标准的 60Hz 档位。填 DTD 时pixel clock 的低字节在前、高字节在后单位是 10kHz85.5MHz 对 10kHz 是 8550换算成十六进制再按小端填入H/V 的 active、blank、sync offset、sync width 都是分散在 16 位字段里的写的时候最好像上面一样先列成表再逐项换算。提示很多源码里的默认 EDID 不带扩展块带扩展块时每 128 字节都要单独算 checksum不是只改最后一块就完事。3.3 辅助检查EDID checksum 与 H/V 参数据表128 字节 EDID 的最后一个字节是 checksum规则是整个块累加后模 256 必须等于 0。任何一次修改都要重算可以直接用命令行python3 -c dopen(edid.bin,rb).read(); print(hex((256 - sum(d[:127]) % 256) % 256))输出的值就是最后一个字节应该填写的数。如果手头没有独立 bin 文件也可以把源码数组导出来再套这条命令。实际改 DTD 时下面这套常用分辨率参数可以直接照抄省去很多换算分辨率像素时钟(MHz)H.activeH.blankH.syncV.activeV.blankV.sync1920x108060148.519202808810804541680x105060119.0168024010410504131366x7686085.51368160327682631280x102460108.0128040811210244231024x7686065.01024320136768386填完 DTD 后真正点屏时还有一个关键配置RTD2660 的 LVDS 输出参数不在 EDID 里而在 panel.c 或类似的屏参数表里包括通道数、bit 位宽、时钟极性。EDID 决定的是显卡端输出什么信号panel 表决定的是主控怎么驱动液晶面板两者必须一致否则会出现有信号但画面撕裂或花屏的现象。4. 在 RTD2660 源码里定制 OSD 菜单、按键和开机 LOGO4.1 OSD 菜单表的挂接位置与字符串存储RTD2660 的 OSD 不是操作系统里的图形界面而是主控直接叠加在画面上的位图。源码 osd 目录下会有一个菜单结构体数组每个菜单项记录坐标、字符串索引、类型和回调函数。我一般先找 osd_string.h 里的字符串表再找菜单数组因为改菜单文案只需要改字符串表不需要动菜单结构这样改动面最小。/* osd/menu_main.c字段含义以实际头文件为准 */ const MENU_ITEM code main_menu[] { {0, 20, 18, STR_BRIGHTNESS, MENU_TYPE_SLIDER, 0, NULL}, {0, 30, 18, STR_CONTRAST, MENU_TYPE_SLIDER, 0, NULL}, {0, 40, 18, STR_LANGUAGE, MENU_TYPE_SUBMENU, 0, (void*)lang_menu}, {0, 50, 18, STR_EXIT, MENU_TYPE_ACTION, 0, NULL}, };这个数组里的 4 个数字分别是 x、y、行高和字符串索引。字符串索引指向另一个 code 数组存的是每个字符的字模编号。一个容易踩的坑是RTD2660 源码里的中文字库往往不是 GB2312 全集只有 OSD 里预先烧好的那几个汉字点阵。直接往字符串表里填一个不存在的汉字编译不会报错屏幕上只会出现空框或乱码这时需要把字模加到 font 段里再重新映射字符串索引。4.2 按键扫描与去抖的驱动逻辑按键板的 GPIO 一般挂在 P0 或 P1 口源码里会有一个 key_scan 函数每个扫描周期把按键读一遍。最省事的方案是让 OSD 主循环按 10ms 周期调用扫描函数再配合连续两次相同的按键值作为去抖条件/* drv/key.c */ unsigned char key_scan(void) { unsigned char key 0; if (GPIO_PIN_READ(KEY_UP_PIN) 0) key | KEY_UP; if (GPIO_PIN_READ(KEY_DOWN_PIN) 0) key | KEY_DOWN; if (GPIO_PIN_READ(KEY_MENU_PIN) 0) key | KEY_MENU; return key; } void key_task(void) { static unsigned char last_key 0; unsigned char cur_key key_scan(); if (cur_key ! last_key) { last_key cur_key; /* 状态变化先记录不处理 */ return; } if (last_key ! 0) { osd_key_event(last_key); /* 连续两次读到相同值才上报 */ } }读回来的值等于 0 表示按下因为按键板通常是把 GPIO 短接到地。去抖采用连续两次一致的方式简单而且够用。RTD2660 的 GPIO 内部上拉需要显式打开如果在驱动初始化里没配上拉按键悬空时电平漂移菜单会自己跳来跳去多数按键乱跳问题不是硬件坏而是上下拉没配。按键名GPIO上报事件调试要点KEY_MENUP1.0打开/关闭 OSD、返回上级必须使能内部上拉KEY_UPP1.1菜单上移、数值加可用示波器看按下时电平KEY_DOWNP1.2菜单下移、数值减检查是否与其他功能复用KEY_AUTOP1.3自动调整画面VGA 输入时常用HDMI 下可忽略4.3 开机 LOGO 的 1bpp 转 C 数组方法开机 LOGO 存在 flash 的一段固定地址OSD 初始化时按 1bpp每像素 1 比特解析显示。把图片转成 C 数组的常见做法用 Python 完成图片缩放到 320x240转灰度再按 128 阈值压成黑白然后按每字节 8 像素打包。from PIL import Image img Image.open(logo.png).convert(L).resize((320, 240)) bw img.point(lambda p: 0 if p 128 else 255, 1) pixels bw.tobytes() # 已经是 1-bit 数据 with open(logo.h, w) as f: f.write(const unsigned char code logo_bmp[9600] {\n) for i in range(0, len(pixels), 16): f.write( , .join(f0x{b:02X} for b in pixels[i:i16]) ,\n) f.write(};\n)320x240 的 1bpp 数据正好是 9600 字节生成的数组可以直接替换源码里的 logo_bmp。如果主控访问 flash 要求按字对齐把数组长度补齐到偶数即可。烧录时 logo 数组要放到 OSD 数据段的指定地址而不是 code 段具体地址看 flash 映射表。图片超过屏幕分辨率时只会显示左上角部分不会被拉伸所以 LOGO 素材尽量控制在 320x240 以内。5. RTD2660 源码改完怎么验证备份、烧录、看 EDID 回读改完代码先别急着烧第一步是备份原固件。RTD2660 的 SPI flash 里除了主程序还有 OSD 字库、logo 和 EDID 默认值整片读出来后要按 code 段、osd 段、dataload 段分段保存否则想还原时只能重新找原厂工具。备份后用grep在 bin 文件里搜版本字符串能快速确认固件型号和对应板卡。烧录时优先走 RTD2660 的 ISP 在线烧录通过 HDMI 或 VGA 口连接不用拆 flash。ISP 模式下主控跑在 boot loader 里只接收烧录工具下发的数据即使你改坏的程序也不会在这时被执行连接不上就先查 DDC 通道电平典型症状是工具提示 no ack。烧录完成后接电脑验证 EDIDLinux 环境直接读内核导出的节点edid-decode /sys/class/drm/card0-HDMI-A-1/edid重点看 Detailed Timing Descriptor 里的水平 1368、垂直 768 是否按预期出现以及最后的 Checksum 是否显示 OK。如果在 Windows 下验证用软读取器读到的 EDID 可能带缓存拔插后再查一次更保险。调试阶段还有一个能省事的技巧改完源码里的内置 EDID 表但不想动 EEPROM 时直接把 drv/ddc.c 里if (eeprom_valid ! 0)这类条件改成常量 0强制跳过 EEPROM 读取让主控总是用内置表。这样少一个变量确认没问题再把条件改回来。记得同时检查 panel.c 里的 LVDS 初始化参数和 EDID 是否一致两边不一致时会出现有同步信号但画面花屏或偏色的现象症状非常像 HDMI 线材接触不良排查时容易走弯路。本文还有配套的精品资源点击获取