简介面向51单片机学习者和红外遥控解码开发者这套格力空调遥控码接收程序采用中断方式完成信号采集并在1602液晶上实时显示解码结果适合用于智能家电控制、红外协议分析或毕业设计参考。压缩包共56个文件总大小5.17MB文件类型以C源码、Keil工程文件uv2、plg、opt、头文件以及编译生成的lst、obj、hex烧录文件为主另有PDF说明、JPEG效果图和格力遥控码分析文档便于对照查看原理与实际运行状态。已有1176人学习下载。程序模块划分清晰从遥控码接收、中断处理到液晶显示均有对应实现同时附带多个调试阶段的版本包可对比不同修改对解码效果的影响帮助读者快速掌握空调遥控码的解析思路与移植方法。 前阵子收拾东西翻出一个旧格力空调遥控器想着把它的按键码抓下来做成一个用51单片机识别的遥控码接收程序。说干就干我直接用STC89C52加一个一体化红外接收头把遥控器发出来的红外信号解调成电平变化再通过外部中断和定时器把每一段脉冲宽度记录下来最后从时序里还原出按键码。这个项目很适合正在学51单片机的人上手它不涉及复杂算法但能把中断、定时器、电平时序分析这几个关键知识点全部串在一起。做完之后想扩展成红外发射、自学习遥控器也顺理成章。这篇文章把整个思路、硬件连接、NEC协议拆解、参考代码和调试踩坑都写出来。不管你用的是普中、江科大还是其他开发板原理都一样照着接好线就能跑起来。1. 项目思路拆解51单片机做遥控码接收到底在接什么1.1 核心需求解析这个项目的本质是把空调遥控器发出的红外光信号转成单片机能够处理的电平变化序列。一体化红外接收头已经完成了光电转换、放大、解调这几步输出引脚上直接就是高低电平。单片机要做的只有一件事测量每一段电平持续的时间长度再按照协议规则还原成0和1。可能有人会问为什么不买现成的红外解码模块或者直接用带红外库的开发板对于学习目的来说自己用51写接收程序才能真正搞懂红外遥控的工作机制。而且STC89C52这种几块钱的单片机处理红外码完全够用。空调遥控器虽然按键多但协议层面并不复杂主要是一个帧结构解析的问题。应用场景也很明确自学习遥控器、智能家居控制面板、空调码采集。最实用的方向是把接收到的码保存下来配合红外发射管做回放变成万能空调遥控器。这一步只要接收端做稳定了后面就是水到渠成的事。1.2 方案选型为什么用51单片机可能有人觉得STC32、STM32或者Arduino性能更强为什么非要用经典的51我的答案很简单够用而且学习价值最高。红外接收头解调后的信号频率非常低单次脉冲宽度在微秒到毫秒级51单片机完全能处理过来。51的定时器和外部中断是学习嵌入式绕不开的基础模块。用这个项目练手比单纯点灯有意思多了。我用的是STC89C52晶振12MHz这样定时器计数值可以直接和微秒对应省去换算的麻烦。如果你用普中开发板或者江科大视频里那套板子原理完全相同只要把红外接收头接到P3.2引脚就能复用这套代码。2. 硬件准备与连接别在接线这一步翻车2.1 器件清单与红外接收头选型硬件方面需要的器件非常少基本上一个51最小系统加一个接收头就能开工。我用的是一体化红外接收头VS1838B这种接收头内置了光敏二极管、AGC放大器和带通滤波器中心频率38kHz正好匹配格力遥控器发射端用的载波频率。市面上常见的HS0038B也可以参数基本一致。接收头通常有三个引脚不同厂家的引脚顺序不完全一样。以VS1838B为例从接收面的左侧看引脚顺序是OUT、GND、VCC。接之前最好对着器件手册确认或者用万用表量一下输出引脚的对地电压。空闲时输出应该接近高电平有红外信号时会被拉低找到这个规律就不会接错。除了接收头还需要51单片机、12MHz晶振、两个30pF负载电容、10k电阻若干、面包板和杜邦线。如果想用串口把解析结果打印到电脑上还需要一个USB转TTL模块。建议再准备一个逻辑分析仪哪怕是十几块钱的简易版本对调试帮助非常大。2.2 接线方式与供电细节接线其实非常简单核心就几条线。接收头的OUT接单片机的P3.2引脚也就是INT0外部中断输入口。VCC接5VGND接GND。重要的是接收头的输出引脚是开漏结构还是推挽结构不同模块表现不一样。如果是裸接收头最好在OUT和VCC之间加一个10k上拉电阻保证输出高电平的驱动能力。很多开发板上的红外接收模块已经集成了上拉电阻和滤波电容直接插上去就能用但面包板搭电路时别省这一步。供电滤波是我实际踩过的一个坑。如果用USB转TTL模块供电电流余量不是很大红外接收头对电源纹波又比较敏感工作频率一高就容易误触发。我的做法是在接收头VCC和GND之间并一个10uF电解电容再并一个0.1uF瓷片电容实测能明显减少随机误码。另外晶振一定要用12MHz这样定时器每个计数单位正好是1微秒。如果顺手抓了11.0592MHz的晶振也能做只是计数值换算成微秒要乘以1.085调试起来多一道转换工序没必要。3. 红外通信基础NEC协议和格力变体的关键差异3.1 NEC协议帧结构绝大多数格力老款空调遥控器使用的是NEC协议准确说是NEC协议的扩展变体。标准NEC协议一帧数据由引导码、32位数据位和结束位三部分组成。引导码是9ms低电平加4.5ms高电平数据位紧跟在引导码后面共32位顺序是8位地址码、8位地址反码、8位命令码、8位命令反码。每个数据位本身也很有特点。不管发送的是0还是1每一位都会先输出一段560us的低电平然后用高电平的长度区分数值。高电平持续1.69ms左右代表1高电平持续560us左右代表0。结束位是最后560us的低电平之后信号线回到高电平空闲状态。发送完一帧后如果按键没有松开遥控器会每隔108ms左右发送一个重复帧。重复帧没有数据位只有9ms低电平加2.25ms高电平加560us低电平作用是告诉接收端“按键还在按住”。3.2 为什么用下降沿周期测量法接收程序最核心的问题是如何准确测量脉冲宽度。我选择的是下降沿周期测量法而不是分别测量高低电平。原理很简单外部中断设置为下降沿触发每次信号从高到低跳变时进入中断在中断里读取定时器的计数值就能得到从上一次下降沿到本次下降沿之间经过的总时间。这个总时间等于一段低电平加一段高电平的周期长度。引导码的周期是9ms加4.5ms约13.5ms。数据位1的周期是560us加1.69ms约2.25ms。数据位0的周期是560us加560us约1.12ms。这三个数值差距明显非常容易区分。如果把触发方式改成上升沿再去单独测高低电平程序复杂度会高很多而且51单片机在短时间中断响应上容易出问题新手不推荐。3.3 格力空调码的实际情况格力空调的编码在NEC框架下做了一些变化。很多格力老机型的地址码固定为0x00也有部分型号使用0xFD之类的值命令码则对应着电源、模式、温度、风量等按键。不同批次、不同型号的遥控器码值可能完全不同网上虽然能查到一些格力遥控码表但直接抄过来大概率对不上。最可靠的方法就是自己用接收头抓取自己手里遥控器的码。只要帧结构符合NEC协议这套接收程序就能正常工作。万一遇到新机型使用其他协议也不用慌脉宽捕获这一步是通用的只需要调整后续的解析逻辑就行。4. 核心代码实现中断定时器的脉宽测量方案4.1 代码设计思路程序整体结构围绕外部中断0和定时器0展开。定时器0配置为模式1也就是16位定时器。每次外部中断进入时先读取TH0和TL0得到从上一次清零到本次下降沿之间的计数值然后立刻清零重新开始计时。因为晶振是12MHz51单片机又是12T模式机器周期正好是1us所以定时器读到的原始计数值就是微秒数不需要任何转换。读取时要注意先后顺序必须先读TH0再读TL0因为16位定时器在运行中如果先读TL0TH0可能刚好进位读出来的值就是错的。数据接收采用简单状态机空闲状态下等待引导码检测到10ms到16ms之间的脉宽就认为收到引导码进入数据接收状态。随后每来一个下降沿就根据脉宽判断当前位是1还是0移位存入缓冲区。收集满32位后置帧完成标志回到空闲状态等待下一帧。4.2 参考源码下面是我验证过的核心代码可以直接在STC89C52上编译运行。主函数里只留了最简单的反码校验和LED翻转方便你确认程序是否收到有效数据帧。#include reg52.h #define uchar unsigned char #define uint unsigned int sbit IR_IN P3^2; // 红外接收头OUT接INT0(P3.2) sbit LED P1^0; // 调试LED收到完整帧后翻转 #define STATE_IDLE 0 #define STATE_DATA 1 volatile unsigned long g_code; // 完整32位码 volatile unsigned char g_frame_ready; // 置1表示收到一帧 // 定时器0初始化模式116位定时器 void Timer0_Init(void) { TMOD 0xF0; // 只改低4位 TMOD | 0x01; TH0 0; TL0 0; TR0 1; // 启动定时 } // 外部中断0初始化下降沿触发 void Ext0_Init(void) { IT0 1; // INT0下降沿触发 EX0 1; // 开INT0中断 EA 1; // 开总中断 } // INT0中断服务函数测量脉宽并还原数据 void Ext0_ISR(void) interrupt 0 { static uchar state STATE_IDLE; static uchar bit_cnt 0; static unsigned long code_buf 0; uint cnt; // 读取定时器计数值单位us cnt TH0; cnt (cnt 8) | TL0; TH0 0; TL0 0; // 10ms到16ms之间引导码或重复帧引导 if (cnt 10000 cnt 16000) { state STATE_DATA; bit_cnt 0; code_buf 0; return; } // 超过16ms干扰或异常复位状态机 if (cnt 16000) { state STATE_IDLE; return; } if (state STATE_DATA) { if (cnt 1800) // 高电平较长 - 1 { code_buf (code_buf 1) | 0x01; } else if (cnt 900) // 高电平较短 - 0 { code_buf (code_buf 1) | 0x00; } else { state STATE_IDLE; // 毛刺忽略 return; } bit_cnt; if (bit_cnt 32) // 收满32位帧完成 { g_code code_buf; g_frame_ready 1; state STATE_IDLE; } } } void main(void) { uchar addr, addr_inv, cmd, cmd_inv; Timer0_Init(); Ext0_Init(); while (1) { if (g_frame_ready) { g_frame_ready 0; // 收到的顺序地址、地址反码、命令、命令反码 addr (g_code 24) 0xFF; addr_inv (g_code 16) 0xFF; cmd (g_code 8) 0xFF; cmd_inv g_code 0xFF; // 反码校验 if (addr (uchar)~addr_inv cmd (uchar)~cmd_inv) { LED ~LED; // 实际项目中可在这里用串口打印addr/cmd } } } }4.3 代码讲解与注意事项这套代码的核心在中断服务函数但我建议你重点关注几个设计细节。首先是阈值的选取我把引导码范围定为10000到16000us而不是精确的13500us附近。原因是红外接收头在不同距离、不同供电环境下脉宽会有一定漂移留出20%到30%的余量是必要的。数据位的判定阈值放在1800us和900us同样是为了适应漂移。其次是中断服务函数一定要短。接收头的下降沿是连续不断的一次中断处理太久就会错过下一次下降沿直接导致数据错乱。我的代码里中断函数只做计数和移位不涉及串口发送这类耗时操作。验证数据是否有效、打印结果这些事情全部放到主循环里处理这样中断才能保证实时性。代码里还隐藏了一个细节收到重复帧时11.25ms的脉宽同样落在引导码判断范围内程序会重新进入DATA状态但因为重复帧后面没有完整数据位bit_cnt不会达到32也就不会产生错误的帧完成标志。这个设计保证了长按遥控器时不会反复触发。5. 常见问题与排查技巧实录5.1 问题速查表做这个项目最容易遇到的问题我整理成了一张速查表。很多问题看起来像是程序bug实际查到最后都是硬件层面的小毛病。现象可能原因排查手段完全没反应接线错误、接收头损坏、晶振没起振万用表量VCC示波器看OUT波形换接收头接收距离短供电不足、缺少上拉、接收头朝向不对VCC加10uF电容OUT加上拉避开阳光直射数据校验失败阈值不合适、协议不是NEC、数据位序理解错先打印原始脉宽对照协议确认帧结构按住按键收到很多帧正常现象遥控器会发送重复帧程序只取首帧或加时间间隔过滤串口打印乱码波特率不匹配、晶振频率不同导致波特率偏差统一两端波特率和晶振频率设置5.2 调试利器串口打印原始脉宽如果你遇到数据解析不出来我强烈建议先把“解析”这一步放一放直接把中断里测到的脉宽值用串口发到电脑上看。正常的NEC帧打印出来应该能观察到一组这样的数据先是13500us左右的引导码脉宽后面跟着32个数值每个都在1120us或2250us附近徘徊。如果能看到这组数说明硬件链路完全正常问题只出在软件判断逻辑上。打印脉宽的方法很简单在中断服务函数里只做一件事把脉宽值按顺序存进一个全局数组然后置一个标志位。主循环检测到标志位后用串口把所有数组元素发送出去一次发完再把标志位清零。这个方法特别适合初次接触红外解码的同学能让你直观看到时序波形而不是对着解析结果瞎猜。5.3 收尾小技巧有一次我长时间测试后发现接收到的数据偶尔会错位排查了半天最后发现是USB转TTL模块共地没接牢电源地线松动导致接收头电平漂移。从那以后我养成了一个习惯所有外设先共地再想别的。另外补充一个扩展方向。接收程序跑通之后只需要在另一个引脚接一个红外发射管配合38kHz载波调制就能把接收到的码值回放出去。接收和发射共地程序里注意不要同时收发一个简单的自学习遥控器就完成了。做空调遥控码接收程序的乐趣就在这里前期把接收做扎实后面能玩出的花样远比想象的要多。本文还有配套的精品资源点击获取