简介：基于51单片机的格力空调遥控码接收程序，以中断方式捕获空调遥控信号，并在1602液晶上实时显示解码结果，适合电子爱好者、嵌入式初学者以及家电通信逆向开发人员参考，可作为单片机外部中断应用与遥控码解析的入门实例。压缩包共56个文件，约5.17兆字节，包含C语言源代码、Keil工程文件、HEX烧录文件、PDF说明文档及图片等，其中5份C程序涵盖解码与液晶显示逻辑，4份PDF提供图文资料，多个压缩包分卷存放历史版本，Word说明文档则对格力遥控码协议进行了分析。已有1177人学习下载。压缩包完整保留了从早期调试到最终版的多个解码程序版本，便于对照学习中断时序设计、码型对比与液晶驱动，目录结构清晰，反映了典型的单片机开发流程，对红外遥控编码、中断接收及1602显示应用均有实践参考意义。
1. 格力空调遥控码接收程序：51单片机怎么把红外遥控变成可控信号
格力空调遥控码接收程序，51单片机做的——这份资源我拆过之后的第一感受是：它把“红外遥控解码”从一个玄学问题，变成了一个可以按图索骥的电平测量问题。你只需要一块51单片机最小系统板、一个几块钱的一体化红外接收头，就能把格力空调遥控器发出的38kHz载波信号，逐位捕获成0和1的数据帧，再通过串口打印或者映射成IO控制。它适合想搞懂红外协议的学生、要给空调做红外转发的DIY玩家、以及准备做空调智能联动却卡在解码环节的从业者。注意，它不是一个开箱即用的完整智能空调项目，而是一个可靠的前端解码器，具体按键对应的码表需要你自己抓取。下面我从协议原理、硬件接线到程序解析，把这份资源的落地路径一次性讲透。
2. 红外遥控原理与格力空调遥控码协议：先搞懂电平宽度再写解码程序
2.1 一体化接收头：为什么输出的是方波而不是正弦波
格力空调遥控器发出来的并不是连续红外光，而是被38kHz载波调制过的信号。你可以把38kHz理解成红外LED在极快速地开关，每秒钟通断三万八千次。遥控器内部先由MCU把按键信息编码成一系列高低电平序列，接着用这个序列去控制载波通断：发射载波的时间段对应“有脉冲”，停止载波的时间段对应“无脉冲”。红外发射管最终发出的就是这种断续的载波包络。
如果直接拿光敏管接收，你得到的是一串叠加了38kHz成分的微弱模拟信号，根本没有单片机可以直接读取的逻辑电平。一体化红外接收头（常见的三脚封装，型号很多）内部集成了光敏二极管、前置放大器、限幅器、带通滤波器、解调器和输出整形电路。它的职责只有一个：识别接收频段内有没有载波。有载波时，输出脚拉低；没有载波时，输出脚保持高。于是你在单片机引脚上看到的是一串干净的TTL方波，低电平表示载波正在发射，高电平表示载波间隙。
这里有一个新手最容易栽跟头的点：接收头输出是反相的。也就是说，遥控器发射的引导码如果是“9ms载波+4.5ms空闲”，经过接收头解调后，单片机引脚上看到的是“9ms低电平+4.5ms高电平”。很多人对照着NEC协议文档写程序，脑子里想的是“9ms高电平+4.5ms低电平”，结果一个码都解不出来。后面避坑章我会专门再讲这个反相细节。
2.2 格力空调遥控码的帧结构：NEC协议的变体与厂商自定义字段
格力空调遥控码并不是某个厂商独创的孤立协议。绝大多数格力遥控器，底层用的都是NEC那套脉冲位置调制方式：用“载波脉宽+空闲脉宽”的组合表示逻辑0和逻辑1。典型NEC定义如下：
| 信号段 | 载波宽度 | 空闲宽度 | 接收头输出电平序列 | 含义 |
|---|---|---|---|---|
| 引导码 | 9ms | 4.5ms | 低电平9ms + 高电平4.5ms | 帧起始 |
| 逻辑0 | 0.56ms | 0.56ms | 低电平0.56ms + 高电平0.56ms | 二进制0 |
| 逻辑1 | 0.56ms | 1.69ms | 低电平0.56ms + 高电平1.69ms | 二进制1 |
空调厂商为了塞进更多控制信息，经常在NEC标准帧上做扩展。电视遥控器一般只有32位数据位，一次完整帧发完就停；空调遥控器则会把开关、模式、风速、温度、扫风等一大堆状态一次性打包进一帧里，帧长常常扩大到40位、48位甚至更多。网上能找到的“格力空调遥控码接收程序”，很多就是针对这种扩展帧写的。
所以，如果你拿普通电视遥控器的解码程序去解格力空调遥控器，大概率在帧结束判断上翻车。电视遥控器数满32个位就认为一帧结束；空调遥控器必须靠“超时”来判断帧结束——连续一段时间没有新的载波脉宽进来，才认为当前帧已经完整接收。格力按键按住不放时还会连续重发同一帧，接收程序还得有能力区分“一次完整帧”和“重复帧”。
这份资源里的51单片机接收程序，核心思路正是这样：用外部中断的边沿跳变记录每次电平持续时间，再按NEC位宽把电平序列切分成引导码和数据位。它没有内置格力码表，因为码表和具体空调机型强相关。比如某些机型的温度位编码用反码，另一些机型用补码，甚至同一品牌不同批次的遥控器，按键码都可能不一样。因此接收程序的正确定位是“忠实还原每一帧原始码”，而不是“直接翻译成温度数值”。
提示：如果你拿到的一帧里出现0.4ms、1.2ms这类非标准脉宽，说明厂商可能微调过脉冲位置。解码阈值不能完全照搬NEC标准值，要留出容差区间。
2.3 为什么用外部中断加定时器：轮询测量为什么不行
51单片机主频不高，如果用12MHz晶振，一条标准指令周期就是1us。要是用while循环去轮询引脚电平，CPU不仅要忙等，测量精度还会被循环判断、变量自增等额外指令拖垮。0.56ms这种短脉冲，轮询误差轻松超过几十微秒，到了1.69ms的长脉冲上更容易误判。
正确做法是在硬件层面等信号。把外部中断INT0配置成下降沿触发，引脚电平一出现下降沿，CPU自动跳进中断服务函数；定时器0配置成16位模式，专门测量两次下降沿之间的时间间隔。为什么选下降沿而不是上升沿？因为接收头输出反相后，引导码的低电平是9ms，数据位里的低电平均在0.56ms左右，下降沿正好是每段低电平的开始。你也可以在下降沿时读取上一个高电平的宽度，两种方式都能还原电平序列，只要收发双方对“一帧从哪里开始”的定义一致就行。
我习惯用一个全局数组存时间值，长度取64左右，足够容纳40位数据帧产生的80个边沿。每次下降沿中断，先把定时器计数值抄出来存进数组，再把定时器清零重新计时。这样数组里偶数下标是低电平宽度，奇数下标是高电平宽度。解析程序只需要成对处理，看高电平宽度就能还原0和1。这个设计把中断服务函数做到极简，不容易踩多任务竞争的坑。
3. 硬件连接与最小系统：从接收头到51单片机的五个关键点
3.1 器件清单与接线表
搭建这个项目需要的硬件不多，清单如下：
- 51单片机最小系统板，典型配置是STC89C52加11.0592MHz晶振，以及两个30pF负载电容。
- 一体化红外接收头，三脚直插封装，内部自带解调功能。
- USB转TTL串口模块，用于把解码结果输出到电脑。
- 面包板、杜邦线若干。
- 一个LED或蜂鸣器，用于硬件自测。
接线表非常直接：
| 接收头引脚 | 连接目标 |
|---|---|
| VCC | 单片机板5V电源输出 |
| GND | 单片机板GND |
| OUT | P3.2（INT0外部中断0输入） |
这里要特别提醒：一体化接收头的引脚顺序不同型号不一样，常见的是“OUT、GND、VCC”排列，但有些模块是“VCC、GND、OUT”。接线前必须看一眼器件手册或丝印，把VCC和GND接反，接收头当场烧掉。这个翻车成本不高，但会浪费一整个下午。
3.2 晶振、去耦电容、上拉电阻怎么选
晶振频率直接影响定时器测量精度。如果用了11.0592MHz晶振，定时器计数周期是12除以11.0592，约1.085us，不是整数，但红外解码只要求微秒级容差，完全够用。如果换成12MHz晶振，计数周期刚好1us，心算方便，但串口波特率误差会变大。我的建议是：只做红外接收、不打印串口调试信息时，用12MHz；要同时开串口看解码结果，优先选11.0592MHz。
去耦电容是很多人忽略的一环。接收头内部解调电路对电源纹波很敏感，特别是和38kHz载波同频的纹波，会直接串到输出脚，造成误触发。我一般在接收头VCC和GND之间并联一个100uF电解电容和一个0.1uF陶瓷电容，尽量让电容紧贴接收头引脚。供电直接用单片机板的5V，不要为了省事去用USB转TTL模块的3.3V——接收头在3.3V也能工作，但接收距离会明显缩短。
接收头的OUT脚是否需要上拉电阻，取决于具体型号的输出结构。很多一体化接收头内部是集电极开路输出，需要一只10k电阻上拉到VCC才能得到稳定高电平。也有一部分推挽输出，不需要上拉。稳妥做法是加上这个10k电阻，不坏事，还能避免引脚悬空时电平漂移。
3.3 硬件自测：用LED确认接收头有输出
写复杂的解码程序之前，先做一个两分钟的硬件自测。把P3.2引脚的电平直接送到P1.0的LED上，按下遥控器任意键，如果LED能跟着按键节奏明显闪烁，说明从遥控器到接收头再到单片机引脚的物理链路是通的。
#include <REGX52.H> sbit LED = P1^0; sbit IR = P3^2; void main(void) { while (1) { LED = IR; // P3.2为低时LED亮，为高时LED灭 } }这段代码没有任何协议处理，作用就是把接收头输出电平实时透传到LED。按下遥控器按键时，接收头输出持续翻转，LED会出现肉眼可见的快速闪烁。如果LED完全不动，先检查遥控器电池、接收头供电、引脚接线顺序；如果LED一直亮或者一直灭，大概率是OUT引脚接错了位置，或者遥控器工作频率不是38kHz。
提示：不建议用手机摄像头看红外发射管来判断遥控器好坏。现在很多手机摄像头带红外滤光片，看不到原本的红紫光。最靠谱的办法是用示波器抓接收头输出，没有示波器就用上面的LED自测法。
3.4 最小系统上容易被忽略的两个点
51单片机的EA引脚必须接VCC。如果EA悬空或接低电平，单片机会从外部ROM执行程序，代码根本跑不起来，表现就是上电后程序乱跳、串口无输出、LED状态随机翻转。我在实验室见过太多人接错这个脚，一查原因就是EA没接。
复位电路也不能省。典型参数是10k电阻接VCC、10uF电容接地，复位引脚经电阻、电容组成的RC网络接到VCC。有些精简最小系统板把复位电路做在板上，买回来后要确认它确实存在。晶振的两个负载电容缺一不可，没有它们，晶振可能起振困难，程序运行会时好时坏，表现出严重的“玄学”故障。
4. 解码程序实现：状态机捕获、超时判帧和码值转换
4.1 程序框架与全局变量定义
解码程序的整体思路是：外部中断负责捕获边沿并记录电平时间，定时器负责提供时间基准，主循环负责等帧结束、解析数据、输出结果。先定义全局变量：
#include <REGX52.H> #include <string.h> #define MAX_EDGE 64 volatile unsigned int edge_time[MAX_EDGE]; volatile unsigned char edge_cnt = 0; volatile unsigned char frame_ready = 0; volatile unsigned char timeout_cnt = 0;edge_time数组保存相邻两个下降沿之间的时间间隔，用定时器0的16位计数值表示。假设晶振12MHz，定时器一个计数周期1us，最大可测量65535us，足够覆盖9ms引导码和4.5ms间隙。frame_ready是帧结束标志，主循环轮询这个标志就知道有没有完整帧可以解析。timeout_cnt是超时计数器，用于判断帧结束。
4.2 定时器与外部中断初始化
初始化代码分成两部分：定时器0配置成16位模式，只计数不产生溢出中断；外部中断0配置成下降沿触发。
void Timer0_Init(void) { TMOD &= 0xF0; // 保留定时器1的配置 TMOD |= 0x01; // 定时器0，模式1：16位不自动重装 TH0 = 0; TL0 = 0; ET0 = 0; // 不使用定时器0溢出中断 TR0 = 0; } void Int0_Init(void) { IT0 = 1; // INT0下降沿触发 EX0 = 1; // 使能INT0中断 EA = 1; // 打开总中断 }这里故意不开启定时器0溢出中断，因为测量短电平根本用不到溢出。只要在帧内没有超过65535us的空闲段，计数值就不会溢出。引导码低电平才9ms，离溢出上限远得很。这种方式比“定时器溢出+累加溢出次数”简单得多，也容易调试。
4.3 外部中断服务函数：记录每一段电平时间
中断服务函数是这份资源最核心的部分，写法如下：
void int0_isr(void) interrupt 0 { static unsigned char first = 1; unsigned int val; if (first) { first = 0; TH0 = 0; TL0 = 0; TR0 = 1; timeout_cnt = 0; // 第一个下降沿作为帧起点，清零超时计数 return; } TR0 = 0; // 先停表，避免读取过程中定时器继续跑 val = (unsigned int)(TH0 << 8) | TL0; if (edge_cnt < MAX_EDGE) { edge_time[edge_cnt++] = val; } TH0 = 0; TL0 = 0; timeout_cnt = 0; // 每来一个边沿，重置超时计数 TR0 = 1; }逻辑是这样的：第一个下降沿出现时，没有上一个电平宽度可以记录，所以只做定时器清空和启动，直接返回。之后每来一个下降沿，先把定时器停掉，读出当前计数值存入数组，再清空定时器重新计时。TR0=0停表这一步很关键，能避免在读TH0和TL0时定时器还在跑造成“高8位已进位但低8位还没读完”的错误。
4.4 帧结束判定：用定时器1做超时检测
空调遥控的帧与帧之间有空闲时间，这时不再产生下降沿。我们需要一个独立的超时检测：距离最后一个下降沿超过15ms，就认为一帧结束。选择定时器1做100us节拍。
void Timer1_Init(void) { TMOD &= 0x0F; TMOD |= 0x10; // 定时器1，模式1 TH1 = 0xDC; // 11.0592MHz下大约100us TL1 = 0x00; ET1 = 1; TR1 = 1; } void timer1_isr(void) interrupt 3 { timeout_cnt++; if (timeout_cnt > 150) { // 150 * 100us = 15ms if (edge_cnt >= 34) { // 至少要有引导码2个边沿加32个数据位边沿 frame_ready = 1; } edge_cnt = 0; // 清空边沿计数，准备接收下一帧 timeout_cnt = 0; } }注意，定时器1中断和外部中断0中断都会访问timeout_cnt。外部中断里清零，定时器1中断里累加。这个变量必须定义为全局变量，不能做成static局部变量，否则外部中断无法清零。怠慢这一点，超时判断会失效，帧结束标志永远不置位。
4.5 数据位解析：成对读取低电平和高电平
当frame_ready变为1，主循环调用解析函数。解析规则是：把edge_time数组按“低电平、高电平”成对拆开，低电平宽度大约都在0.5~0.6ms，不需要严格区分；高电平宽度用来区分逻辑0和逻辑1。
unsigned char bit_buffer[16]; unsigned char bit_len = 0; void parse_frame(void) { unsigned char i; unsigned int low, high; bit_len = 0; memset(bit_buffer, 0, sizeof(bit_buffer)); if (edge_cnt < 34) { return; } // 校验引导码：edge_time[0]应在7ms~11ms之间 if (edge_time[0] < 7000 || edge_time[0] > 11000) { return; } for (i = 2; i + 1 < edge_cnt; i += 2) { low = edge_time[i]; high = edge_time[i + 1]; // 低电平宽度不在合理范围则跳过 if (low < 300 || low > 900) { continue; } // 高电平宽度大于1.2ms判为逻辑1，否则逻辑0 if (high > 1200) { bit_buffer[bit_len >> 3] |= (1 << (7 - (bit_len & 0x07))); } bit_len++; } }bit_buffer按位存储，bit_len记录实际接收的bit数。每8个bit组成一个字节，最终得到一帧的原始码。这里没有做格力厂商的校验和验证，因为我建议先把原始码打印出来，用离线工具分析不同按键之间的规律，等你摸清校验规则后再写进单片机也不迟。
4.6 串口输出：把原始码变成人类可读的十六进制
最后通过串口把bit_buffer发送到电脑，用串口助手查看。我习惯按十六进制输出一帧的字节数组，而不是二进制位流，这样便于肉眼比对不同按键的差异。
void Uart_Init(void) { SCON = 0x50; // 模式1，8位UART TMOD &= 0x0F; TMOD |= 0x20; // 定时器1，模式2：8位自动重装 TH1 = 0xFD; // 9600波特率，晶振11.0592MHz TL1 = 0xFD; TR1 = 1; } void send_frame(void) { unsigned char i; for (i = 0; i < ((bit_len + 7) >> 3); i++) { SBUF = bit_buffer[i]; while (!TI); // 等待发送完成 TI = 0; } }主循环里一旦检测到frame_ready，就调用parse_frame，再调用send_frame输出。串口打印出的帧，就是当前遥控器按键对应的原始码。把温度加、温度减、模式切换等按键依次按一遍，记录下每个按键对应的字节序列，你就得到了一张属于自己空调的码表。
5. 避坑与常见问题排查：五条实战踩坑记录
5.1 现象一：接收距离只有几厘米，遥控器必须怼着接收头
明明电路都接对了，程序也能解出码，但遥控器稍微离远一点就没反应，接收距离不到十厘米。我排查过好几次，最典型的原因是接收头电源去耦不到位。接收头内部增益很高，电源上的纹波会直接影响解调灵敏度，尤其是手摸到单片机板或者电源线时，距离变化特别明显。
解决方法是：在接收头VCC和GND脚之间加一个100uF电解电容和0.1uF陶瓷电容，两个电容都要尽量靠近接收头。同时检查供电来源，不要让接收头和蜂鸣器、继电器共用一根电源线，那些元件启动瞬间会把电源拉出毛刺。还有一个容易被忽略的点：接收头窗口要避开强光直射，尤其是节能灯和劣质LED灯，它们的频闪会干扰接收头判断。
5.2 现象二：解码偶尔错码，帧中间多了一个异常高脉冲
同一个按键反复按，串口打印出来的码大部分时候正常，偶尔会多出几个bit，或者某个bit从0变成1。用逻辑分析仪抓接收头输出，发现波形在正常的下降沿处多了一个很窄的正脉冲毛刺。
原因是接收头输出在电平翻转瞬间存在振铃，单片机引脚检测到第二次下降沿，导致一次电平变化被记录成两次。解决分两步：硬件上，在接收头OUT与GND之间并联一个100pF电容，滤掉高频毛刺；软件上，在外部中断服务函数里加一个最小间隔判断，如果本次下降沿距上次不足100us，直接丢弃并且重置定时器。
5.3 现象三：程序跑飞或上电乱闪，LED状态完全不受控
代码没有任何问题，但上电后LED乱闪，串口也不输出，像中了邪。这个现象在51最小系统上最常见的原因有两个：一是EA引脚没有接VCC，单片机从片外ROM执行程序；二是复位电路参数不对，上电瞬间无法正常复位。
解决方法是：检查EA引脚是否被强拉到VCC；复位电路的电阻用10k、电容用10uF；晶振的两个30pF负载电容必须焊上，否则晶振起振不稳定。另外要确认P3.2引脚上电时的电平状态，如果外部电路在初始化阶段把它拉低，会在程序刚启动时制造一次假下降沿，干扰第一帧接收。我一般会在主程序初始化时先关总中断，配好定时器和外部中断配置，最后再打开EA，避免启动过程产生误触发。
5.4 现象四：长按遥控器时解码结果错乱，帧数据对不上
短按按键时解码正常，长按超过两三秒后，解码结果开始错乱。原因是我最初的实现里没有处理“重复帧”。空调遥控器在按住按键时会不断重发完整帧，每两帧之间有几十毫秒空闲。我的超时判断用15ms作为帧结束条件，导致一帧刚结束，下一帧的引导码又开始了，两帧数据被拼接在一起。
解决方法是：在超时判断中，不仅要把frame_ready置位，还要主动丢弃超时之后的所有边沿，直到检测到新的引导码。同时可以在主循环里做一个去重：如果连续两次解析出的byte数组完全一致，只保留一次输出。这个去重逻辑在后续做学习型遥控器时特别有用。
5.5 现象五：串口打印全是乱码，波特率设置怎么调都不对
解码程序逻辑正确，LED自测也正常，但串口助手显示的全是乱码。排查后发现，单片机板上焊的是12MHz晶振，而程序里按11.0592MHz晶振计算的TH1重装值。12MHz晶振下，9600波特率的误差累积很大，远超串口容错范围。
解决方法是：优先换回11.0592MHz晶振，这样TH1=0xFD对应9600波特率是标准的。如果板子上已经焊了12MHz晶振不想改，就把波特率降到2400，TH1重装值按12MHz计算，误差控制在可接受范围内。我的习惯是：拿到一块新开发板，先用万用表或示波器确认晶振频率，再决定初始化参数，避免这种低级错误。
6. 验证与进阶：用逻辑分析仪把解码过程“可视化”，再接入发射模块做闭环
解码程序写完，不能只看串口能打印数据就收工。我每次都会把逻辑分析仪的两个通道分别接在接收头OUT和单片机P3.2引脚上，然后按一次遥控器按键。如果波形显示：先是9ms低电平、4.5ms高电平，接着是成对的0.56ms低电平和两种不同宽度的高电平，并且程序串口输出与波形能一一对应，这才算真正验证通过。如果波形对不上，问题大概率在外部中断触发条件，而不是数据解析部分。
验证通过后，这份资源就可以直接扩展成一个空调遥控码学习转发器。解码得到的原始码先存到EEPROM里，然后通过另一个定时器生成38kHz载波，用红外发射管把数据重新发出去。发射端的核心思想是反向操作：发送逻辑0时，先开载波0.56ms，再关载波0.56ms；发送逻辑1时，先开载波0.56ms，再关载波1.69ms。引导码则是9ms开、4.5ms关。用51单片机模拟这个时序完全可行，唯一要注意的是开载波期间必须保持输出连续翻转，不能用普通延时函数硬撑，否则载波频率会漂移。
保存码表时我有一个坚持了很长时间的习惯：每个按键连续采集20帧，打印到PC后再做一次过滤。因为空调遥控器在按键期间会连续重发同一帧，如果不去重，20帧里可能有5帧是同一码的重复。去重后的码表再按“按键名+原始码”的格式存成文本文件，后续做协议分析时才不会手忙脚乱。从那以后，我每次写完接收程序都强制自己走一遍“逻辑分析仪验证+20帧去重”的流程，再也不凭感觉判断码对不对。希望帮到你。
本文还有配套的精品资源，点击获取
