简介：一套基于51单片机的格力空调遥控码接收演示程序，定位为单片机红外遥控解码入门与实战参考，适合学习中断编程、1602液晶显示和红外协议解析的开发者。压缩包含56个文件，大小约5.17MB，以C源码、KEIL工程文件（uv2/plg）和HEX烧录文件为主，同时包含LST/OBJ中间文件、PDF/JPG说明图片以及DOC分析文档，可满足从代码阅读、工程编译到资料查阅的完整学习流程。程序采用中断方式捕获遥控码，解码结果实时显示在1602液晶上，并附有多个版本迭代的遥控器解码工程，便于对照学习。已有1100余人浏览学习这套程序。透过源码和文档，读者可掌握格力空调遥控码的时序特征、按键键值映射以及在51平台上的完整实现思路，适合在空调控制类项目中直接参考或二次开发。
1. 格力空调遥控码接收：一个比标准 NEC 协议更折腾的活
网上能找到的红外遥控解码例程，九成都是针对标准 NEC 协议的。你把那些代码直接烧进 51 单片机，对着格力空调按遥控器，大概率什么都解不出来——不是代码写得不对，是格力遥控器的编码格式本来就和 NEC 不一样。格力空调遥控码的引导码、数据位的脉宽定义、帧中间的间隔码都有自己的讲究，而且不同批次、不同型号的格力遥控器，编码细节还会有差异。这个标题说的「格力空调遥控码接收程序」，本质上就是要在 51 单片机这种资源极其有限的平台上，用定时器加外部中断把格力这套非标准的红外编码解出来，为后续的空调控制、智能家居联动打地基。适合谁看？手里有 51 开发板、想搞懂红外解码原理的初学者，或是正在做空调红外网关、需要解析格力码的从业者。看完这篇，你能从零把接收程序和波形验证完整跑通。
2. 格力遥控码的特征：为什么通用 NEC 库解不开
先解决「这是什么」的问题。格力空调遥控器发送的红外信号，载波频率和大多数家电遥控器一样是 38kHz，调制方式也是脉宽调制，但帧结构和标准 NEC 差得很远。标准 NEC 的引导码是 9ms 高电平加 4.5ms 低电平，格力用的是更短的引导码，通常是 9ms 高电平加 4.5ms 低电平的变体——有些型号是 4.5ms 引导码加 4.5ms 间隔，有些是 9ms 加 4.5ms 但数据位定义完全不同。更麻烦的是，格力码的数据位不是 NEC 那种「560μs 高电平加 1.69ms 低电平表示 1，560μs 高电平加 560μs 低电平表示 0」的固定搭配，而是有自己的一套脉宽组合。你如果用标准 NEC 的解码逻辑去解析，会把引导码之后的每一位都判错，解出来的码值毫无意义。
2.1 格力码的帧结构：引导码、数据位与帧间隔
我实际抓过格力多个型号遥控器的波形，常见的格力帧结构大致是这样的：一帧完整的遥控码，开头是一个引导码，引导码之后是 8 位地址码加 8 位地址反码，再往后是 8 位数据码加 8 位数据反码，有的型号还会在数据段后再加一段校验或者重复码。但和 NEC 最大的区别在于，格力码在每个 8 位字节之间会插入一个间隔码——这个间隔码的脉宽长度和引导码很像，导致很多解码程序会把中间间隔误判成新的一帧开始。
数据位的判定也有讲究。格力的「1」和「0」不是用高电平持续时间来区分，而是用高电平之后的低电平持续时间来区分。我抓到的典型波形里，数据位的高电平时间通常是 560μs 左右固定不变，而低电平时间，「0」大约是 560μs，「1」大约是 1.68ms。这和 NEC 恰好反过来——NEC 是高低电平的组合区分，格力是靠低电平长度区分。所以解码程序的重点不是测高电平，而是精确测量每一位之间的低电平宽度，用低电平宽度来判 0 还是 1。
2.2 为什么用 51 单片机做这件事：资源匹配与实时性
有人会问，现在 STM32、ESP32 满地都是，为什么还要用 51 单片机来做？这里有几个现实原因。第一，51 单片机做红外接收是经典教学场景，很多高校的实验平台和开发板都是 51 内核，学习成本最低；第二，51 单片机的定时器工作在 12MHz 晶振下，定时精度足够分辨 560μs 和 1.68ms 的脉宽差异，加上外部中断可以做到边沿触发，完全能胜任红外解码这种毫秒级实时任务；第三，格力空调的红外控制只需要发送端单向通讯，接收端只需要解码，不需要复杂的协议栈，51 的资源刚好够用，成本也能压到几块钱。
不过有一个前提：51 单片机的主频不能太低。我用过 11.0592MHz 和 12MHz 晶振都能稳定解，但如果是老的 6MHz 晶振，定时器计数分辨率会变粗，560μs 的脉宽测量误差会被放大，解错码的概率会明显升高。所以我一般会建议用 12MHz 晶振，并在解码时对定时器计数器的溢出做处理，避免长时间测量时计数器回绕。
3. 接收端硬件搭接与波形抓取：先把信号搞干净
解码程序写得再好，硬件信号脏了也是白搭。格力空调遥控码接收端的硬件核心就三个东西：红外一体化接收头、上拉电阻和去耦电容。一体化接收头内部已经集成了光敏二极管、放大电路和解调电路，输出端直接给出解调后的高低电平信号，接上就能用，不用自己搭 38kHz 解调电路。最常见的就是三脚封装，一脚接地、一脚接电源、一脚输出。
3.1 接收头接线与上拉电阻选择
接收头的输出脚是开漏输出，必须接上拉电阻才能输出正常的高电平。上拉电阻选 10kΩ 即可，阻值太小会增大功耗，太大则上升沿变缓，影响脉宽测量精度。电源脚要并联一个 10μF 电解电容和一个 0.1μF 陶瓷电容，分别滤除低频纹波和高频噪声。很多初学者在这里翻车——接收头的电源如果直接接单片机 5V 而没加去耦电容，遥控器按下时输出波形上会叠加电源噪声，导致解码程序把一段正常的高电平误判成多段短脉冲。
输出脚直接接单片机的外部中断引脚，比如 P3.2（INT0）。注意选带外部中断的引脚，别随便接普通 IO 口然后用轮询方式采样。轮询方式在 51 上很难做到精确测量 560μs 级别的脉宽，因为主循环的指令周期不一致，测量误差会漂移。外部中断加定时器才是正路。
3.2 用逻辑分析仪确认波形：解码前必须先验证
代码开写之前，强烈建议用逻辑分析仪抓一段遥控器的原始波形。逻辑分析仪不贵，USB 接口的 8 通道也就几十块，采样率 24MHz 足够用。抓的时候把接收头输出脚接到逻辑分析仪的通道上，按下遥控器任意按键，抓完整帧，然后把波形放大看引导码和数据位的脉宽。
这一步能帮你确认三件事：引导码的实际高低电平时间是多少、数据位高电平是否稳定在 560μs 附近、低电平的「1」和「0」的区分度是否明显。我遇到过一台格力遥控器，数据位的「1」低电平只有 1.5ms 而不是标准的 1.68ms，如果按标准值去设阈值，就会把「1」误判成「0」。这种型号差异只能靠实测波形来校准，不能靠猜。
4. 解码程序设计：定时器 + 外部中断的核心代码
现在进入正题：怎么写解码程序。51 单片机的资源有限，不能像 STM32 那样用输入捕获硬件自动记录边沿时间，只能靠外部中断触发。我的方案是：外部中断配置为下降沿触发，每次下降沿进入中断时，读取定时器的当前计数值，和上一次下降沿的时间戳相减，得到这段时间的宽度。因为红外信号的每一段都是从高电平开始、低电平结束，下降沿恰好是每一段的边界。两次下降沿之间的时间，就是一段完整的高电平加低电平的总时长。再结合上一次中断时记录的电平状态，就能拆出高电平时间和低电平时间。
4.1 定时器初始化与边沿捕获配置
先看定时器和中断的初始化代码。这里用定时器 0 作为时间基准，配置为方式 1，16 位计数，不自动重装。外部中断 INT0 配置为下降沿触发。
// 定时器0初始化，工作方式1，16位计数器 void timer0_init() { TMOD &= 0xF0; // 清空定时器0的配置位 TMOD |= 0x01; // 定时器0，方式1：16位定时 TH0 = 0x00; // 计数器初值设为0 TL0 = 0x00; TR0 = 1; // 启动定时器 } // 外部中断0初始化，下降沿触发 void int0_init() { IT0 = 1; // INT0下降沿触发 EX0 = 1; // 使能外部中断0 EA = 1; // 开总中断 }这段代码的关键点是定时器初值设成 0，让计数器从 0 开始自由计数。每次进入中断时读取 TH0 和 TL0 组合成 16 位值，就能得到当前时间戳。由于定时器每溢出一次是 65536 个计数周期，在 12MHz 晶振下，一个机器周期是 1μs，定时器计数频率也是 1MHz，所以 65536μs 的溢出周期远大于红外信号每一段的宽度，单次测量不会回绕。
参数说明：TMOD 的高四位是定时器 1 的配置，低四位是定时器 0 的配置。方式 1 是 16 位不自动重装，适合这种需要连续计数的场景。IT0 置 1 表示 INT0 下降沿触发，IT0 置 0 则是低电平触发，这里必须用下降沿，因为红外信号的每一段都是高电平开始低电平结束，下降沿就是段的边界。
4.2 完整解码流程：时间戳差值法与状态标记
收到下降沿中断后，要做两步：第一步读取当前时间戳，第二步和上一次的时间戳做差值，得到段的宽度。但问题来了——如果不记录上一次下降沿时的电平状态，光靠段宽度没法区分是「高电平段」还是「低电平段」。所以我在中断服务程序里维护一个变量记录当前正在接收的段的状态。
// 全局变量 volatile unsigned int last_time = 0; // 上一次下降沿的时间戳 volatile unsigned char bit_count = 0; // 已接收的数据位个数 volatile unsigned char rcv_state = 0; // 接收状态机状态 volatile unsigned long frame_data = 0; // 解出的数据位 volatile unsigned char low_time_flag = 0; // 标记当前段是低电平段 // 外部中断0服务程序 void int0_isr() __interrupt 0 { unsigned int now_time; unsigned int interval; now_time = (TH0 << 8) | TL0; // 读取当前时间戳 interval = now_time - last_time; // 计算段宽度 last_time = now_time; // 更新上一次时间戳 // 第一次进入中断，只记录时间戳，丢弃首段 if (last_time == 0) { return; } // 根据段宽度判断当前收到的是什么 if (interval > 8000) { // 大于8ms，这是引导码 rcv_state = 1; // 进入数据接收状态 bit_count = 0; frame_data = 0; } else if (rcv_state == 1) { // 数据位处理，根据低电平宽度判0/1 // 注意：这里的interval是上一次下降沿到这次下降沿的总宽度 // 需要结合上一次记录的段状态来拆分 if (interval > 2000) { // 宽间隔，这是1 frame_data = (frame_data << 1) | 1; bit_count++; } else if (interval > 800) { // 窄间隔，这是0 frame_data = (frame_data << 1) | 0; bit_count++; } } }这段代码的逻辑说明：每次下降沿中断时，interval 是上一次下降沿到这一次下降沿的总时间，即一段高电平加一段低电平的总宽度。格力码的数据位高电平固定约 560μs，所以总宽度大约等于 560μs 加低电平宽度。低电平是 560μs 时总宽约 1.12ms，判断为 0；低电平是 1.68ms 时总宽约 2.24ms，判断为 1。所以在代码里，interval 大于 2000μs 判为 1，大于 800μs 判为 0，小于 800μs 的丢弃。这个阈值可以根据实际波形微调，比如我前面提到的某个遥控器的 1 低电平只有 1.5ms，对应的总宽约 2.06ms，阈值就要往下调。
需要特别强调的是，第一次进入中断时 last_time 为 0，这里用了一个粗糙的判断方式。严谨的做法是设一个标志位标记是否收到过第一次中断。因为引导码的高电平时间本身就可能接近 9ms，加上 4.5ms 的低电平，总宽度远大于 8ms，所以引导码的判定用 interval > 8000 是成立的。但如果你用的格力遥控器引导码偏短，比如实测只有 4ms 加 4ms，那这个阈值也得跟着改。
5. 避坑：格力码接收最常见的 5 个翻车现场
这里把实际调试中踩过的坑集中写出来，每一条都是「现象 → 原因 → 解决」的结构，照着排查能省大量时间。
5.1 按下按键解出的码值不稳定，每次都不一样
现象：同一按键按十次，串口打印出来的码值有五六种不同结果。原因多半是数据位的低电平「1」和「0」的判定阈值设置不当，或者定时器测量误差偏大。我排查过一台板子，发现是 12MHz 晶振的负载电容没焊，导致实际振荡频率偏离标称值，定时器计时偏快，560μs 的脉宽测出来只有 530μs。解决方法是先换高精度晶振，再用逻辑分析仪实测脉宽校准阈值，不要依赖理论值。晶振这个坑在 51 上特别常见，便宜晶振的精度参差，有条件用有源晶振或者陶瓷谐振器时注意标称误差。
5.2 信号源离接收头太近，导致解码失败
现象：遥控器离接收头只有 5cm，按下后完全无反应；拿远到 50cm 反而正常。原因是红外接收头在近距离接收时，前级放大器进入饱和区，输出波形严重畸变，高电平时间被拉长，低电平时间被压缩。解决方法是接收头前面加一层红外滤光片（注意不要用透明白色塑料片），或者把接收头凹进去一点，避免直接暴露在强红外下。这个现象在空调遥控器这类近距离场景中更容易出现，因为空调遥控器使用时距离一般就 1～3 米，反而不容易触发。
5.3 解出的码值看起来对，但发送回空调没反应
现象：用逻辑分析仪对比，解出的码值和原厂遥控器的波形不一致。原因有两类。第一类是解码时丢了某个中间间隔码，导致后续所有数据位整体错位。格力码每 8 位数据之间会有一个间隔码，间隔码的宽度接近引导码，容易被误判成新一帧的起始。第二类是数据位判 1 和 0 的阈值边界没处理好，个别位判反。解决办法是在解码状态机里显式区分「引导码」「间隔码」「数据位」三种状态，不要一刀切用宽度值硬判。间隔码的特征是它之后跟随的必然是下一组 8 位数据的起始位，所以可以通过位计数来识别——每收满 8 位就预期一个间隔码。
5.4 程序跑着跑着进入死循环，必须复位
现象：按下遥控器后，单片机整个程序卡死，连流水灯都不闪了。原因大概率是中断服务程序执行时间过长，或者 while 循环里等待某个标志位时没有超时保护。51 的中断优先级是固定的，如果外部中断里做了太多数据处理，比如长整型移位和乘法，会导致中断服务程序超过下一个下降沿的到达时间，丢中断后状态机卡在中间状态。解决方法是中断里只做时间戳记录和简单的宽度判断，数据位拼接和状态转移可以放主循环里处理。另外，所有等待标志位的 while 循环必须加超时退出，防止遥控器没按或信号丢失时程序永远卡住。
5.5 解码程序在别的板子上跑不通
现象：同一份代码，在某开发板上稳定运行，换了一块板子后完全解不出码。原因通常是板子上的晶振频率不一致、外部中断引脚被复用、或者接收头的电源设计不同。51 的 P3.2 脚除了是 INT0 还有第二功能，如果板子上 P3.2 被其他外设占用，中断触发就会异常。解决方法是先确认两块板子的晶振频率，如果频率不同，定时器初值和阈值都要重新换算；然后检查原理图确认 P3.2 没有被复用。最好的做法是画板时把接收头输出单独引到一个干净的 IO 口，只做中断输入用。
6. 进阶验证：把解出的格力码和编码表比对
解码程序写完能跑通，只算成功了一半。真正要确认解码结果正确，需要把解出的每一帧数据拆开，和格力空调遥控器的编码定义逐位核对。这里给一个可操作的方法：先按遥控器上温度「+」键，再按温度「−」键，分别解出两组码，用串口打印成 16 进制，然后做三件事。
第一件，检查两组码的地址码部分是否一致。格力空调遥控器的地址码通常是固定的，不同的键码只改变数据码部分。如果地址码对不上，说明解码时序还有问题。第二件，看温度+和温度−的数据码差异是否符合预期。一个合法的格力码，键码部分通常只有某一位或某几位不同，如果两组码差异巨大，基本可以断定解码错位。第三件，把解出的数据码和从逻辑分析仪抓到的原始波形手动解码结果比对。逻辑分析仪抓到的波形是客观的，手动按脉宽解码出的每一位就是标准答案，程序解出的结果和它一致才算通过。
我一般会在主循环里把解码结果通过串口以二进制格式输出，然后把二进制字符串按空格分成几组，对应帧结构里的地址码、地址反码、数据码、数据反码段，人工核对每一个分段的逻辑关系。温度+和温度−的码，在数据码段应该仅有 1～2 位的差异，这样就验证了解码程序的正确性。这个验证步骤做完，你才算真正掌握了格力空调遥控码的接收能力，后面不管是做空调红外网关，还是自己 DIY 一个空调伴侣，地基都稳了。
最后说个习惯性建议：解码程序里所有脉宽阈值，不要写成魔数散落在代码里，统一用宏定义放在文件头部，标注实测值范围。这样换遥控器型号、换晶振频率时，只需要改宏定义就能重新适配。我吃过不写注释的亏，隔三个月回头看自己代码，对着一个「9000」完全想不起是引导码阈值还是间隔码阈值——希望这篇能帮你少走这些弯路。
本文还有配套的精品资源，点击获取
