基于STM32的智能家居控制系统设计：红外遥控空调实现详解

简介：这是一套面向嵌入式开发初学者与物联网实践者的STM32智能家居控制系统完整工程资源，聚焦红外遥控空调控制这一特色功能，解决环境感知、本地自动决策与多模态远程交互的典型应用问题。压缩包含448个文件，总大小82.36MB，涵盖95个编译中间文件（.o/.d）、92个Keil工程配置与调试相关文件（.crf/.axf/.map/.uvprojx等）、43个头文件（.h）与42个C源码文件，以及设计文档PDF、固件HEX、网页前端HTML和语音识别相关资源，结构完整、模块清晰，便于逐层理解与复刻。已有814人学习下载，资源配套博客详细解析温湿度/光照采集、OneNet平台对接、光控/温控逻辑实现、红外载波发射协议适配及离线语音指令识别流程。读者可直接烧录运行，快速掌握STM32外设驱动、RTOS任务调度、MQTT通信及人机交互系统集成等核心技能。 前两天整理资料时翻到一个老项目，标题写着“基于STM32的智能家居控制系统设计与实现(特色红外遥控空调)”，一眼就想起来当初做毕设时熬的那几周。很多同学拿到类似题目不知道从哪下手，网上模板又千篇一律，不是单纯点灯就是只做温湿度显示，毫无亮点。今天把这个项目的完整设计思路和实现细节重新捋一遍，重点拆解“红外遥控空调”这个技术点，顺带把硬件选型、软件架构、调试踩坑这些过程也都讲清楚，希望给准备做STM32智能家居方向的朋友一个可以直接参考的完整方案。

先说结论：这个项目最适合两类人。一类是正在做嵌入式课程设计或毕业设计的学生，需要有一个功能完整、有技术亮点、答辩能讲得出原理的系统；另一类是自己想动手搞一套家庭智能控制原型、但又不想一上来就碰路由器固件、MQTT服务器那种复杂架构的嵌入式爱好者。你不需要会写上位机，不需要有云服务器，只要手里有一块STM32开发板，再花几十块钱买几个传感器和红外模块，就能把一套能用的系统搭出来。

1. 项目整体设计与需求拆解

1.1 核心需求解析

这个项目的标题很典型，关键词拆开就是三部分：STM32、智能家居控制系统、红外遥控空调。前两个是绝大多数同类项目的共性部分，而最后的“特色红外遥控空调”才是真正的技术与答辩亮点。先明确一点：市面上大多数智能家居课题做的都是“手机App控制LED灯”、“温湿度监测”、“风扇调速”这类入门功能，虽然完整，但技术深度一眼见底。而空调控制之所以有特色，是因为空调遥控器不走普通红外按键码那套简单协议，它涉及码值学习、载波调制、长帧发送、甚至品牌差异化处理，难度明显上了一个台阶。

从需求功能上看，一套合格的系统至少包含几个层面：环境数据采集（温湿度、光照）、本地自动化控制（根据环境自动开关设备）、红外控制空调（学习并复现遥控指令）、人机交互（屏幕显示状态、按键或手机端控制）。如果还有余力，可以加语音识别、WiFi远程查看、定时策略等扩展功能，但核心框架不变。

1.2 系统总体架构与功能模块划分

按照嵌入式系统的常规分层，整个系统可以拆成四层：感知层、控制层、执行层和人机交互层。

感知层负责采集环境信息，最常用的是DHT11或DHT22温湿度传感器，以及光敏电阻或BH1750数字光照传感器。控制层就是STM32主控，负责跑逻辑、处理数据、调度外设。执行层则是各种执行机构：继电器控制灯光/插座、风扇/加热设备，红外发射管负责把空调控制码发出去。人机交互层包含OLED显示屏、独立按键、蓝牙/WiFi模块（如果要做手机控制的话）。

模块之间通过GPIO、I2C、UART、定时器PWM等片上外设连接。建议一开始就用模块化的思路画系统框图，把每个模块标注清楚。这样写代码的时候一个模块对应一组.c/.h文件，后面调试也能快速定位问题。

1.3 方案选型：为什么是STM32，为什么用红外

主控选择上，STM32F103C8T6是这类项目最常见的选型。原因很实际：它便宜、资料多、引脚够用，而且即使是最小系统板，也内置了足够的定时器、ADC、UART、I2C这些外设。对于智能家居这种外设种类多、但单个外设任务不重的场景，一颗72MHz的Cortex-M3内核绰绰有余。当然也可以选STM32F407这类更高端的芯片，性能冗余但没必要，而且对新手来说Keil工程配置和引脚复用反而更容易出问题。

控制空调为什么用红外而不是用WiFi协议直连？这里有一个很核心的行业现实：家用空调（尤其不是智能空调的老款）没有开放网络接口，想接入智能家居系统，最通用的方式就是模拟遥控器，也就是红外发射。而普通红外遥控器发射的是经过38kHz载波调制、按NEC等协议编码的信号，STM32完全可以通过定时器PWM产生载波、通过GPIO控制发射管，从而复现任意遥控指令。这个方案不依赖空调品牌，甚至不需要拆机，只需要学习一次码，就能把遥控器变成模块里的数据文件，这是它成为项目亮点的主要原因。

2. 硬件电路设计与元器件选型

2.1 主控最小系统与引脚分配

用STM32F103C8T6最小系统板的时候，硬件设计最轻松，USB转串口、复位电路、晶振和启动配置都帮你做完了。你要做的就是把外设模块的引脚接对。但引脚分配这一步千万别随意，我见过太多人把I2C引脚和UART复用冲突，最后只能飞线改版。

这里给出一组我实测没问题的引脚规划，功能清晰且避开冲突：

注意OLED和BH1750共用I2C总线没问题，它们的I2C地址不同（OLED通常是0x3C或0x3D，BH1750是0x23或0x5C）。如果你不想共用也可以给BH1750换一组引脚，但共用能省出更多GPIO，这在项目答辩时也能说成“总线复用”设计亮点。

2.2 传感器与执行器选型细节

DHT11和DHT22的选择上，学术上建议DHT22，精度更高、采样周期短，但实际用下来DHT11在智能家居场景也够用，因为它便宜到几乎可以忽略成本。如果真要测数据质量，就用DHT22，注意它的时序时序和DHT11有细微差异，代码要区分。

继电器模块建议选5V低电平触发的光耦隔离版，不是那种三极管直接驱动的劣质模块。低电平触发意味着MCU引脚默认高电平，继电器默认断开，只有输出低电平时才吸合，这样上电瞬间不会误动作，避免插上电源那一刻灯突然亮起吓人一跳。光耦隔离还能保护STM32引脚不被继电器线圈反峰电压冲击，长期运行稳定得多。

红外部分最关键。接收端用一体化红外接收头HS0038B或VS1838B，它的输出引脚直接连STM32的GPIO，空闲时输出高电平，接收到38kHz载波时输出低电平，所以只需在GPIO上做下降沿中断和电平计时就能解码。发射端不能直接把MCU引脚接红外发射管，因为发射管瞬间电流需求能达到100mA，GPIO根本带不动。要用一个NPN三极管（比如S8050）做开关驱动，基极接STM32的PWM引脚，集电极串联一个22欧姆限流电阻接红外发射管。这个电路很简单，但很多人忽略，导致发射距离不到半米。

2.3 红外发射驱动电路原理

这里展开说一说发射端驱动。红外发射管不是简单地一通电就能发红外光，它需要在38kHz的频率下快速通断，形成载波调制信号，接收端才能解调出数据。STM32的TIM1或TIM2可以输出PWM波，把PWM频率设为38kHz、占空比设为1/3（即高电平时间约8.8us，周期约26.3us），然后用另一个定时器或延时函数控制PWM的开启和关闭，这样就能模拟出遥控器的发射时序。

具体电路连接上：PA8输出38kHz PWM，经过1kΩ电阻接S8050基极，发射极接地，集电极通过一个22Ω电阻接红外发射管正极，发射管负极接3.3V和GND之间要注意方向。之所以用22Ω，是因为3.3V供电时，发射管正向压降约1.2V，加上三极管饱和压降0.2V，限流电阻压降约为1.9V，电流约86mA。需要说明的是，86mA对短时发射来说是OK的，只要不是长时间连续发射就行。如果你直接用5V给发射管供电，限流电阻要改成47Ω左右，把电流控制在80mA上下。

2.4 电源系统设计

这个系统里涉及3.3V和5V两种电压：STM32、OLED、BH1750用3.3V，DHT11、继电器模块、红外接收头一般用5V（部分模块兼容3.3V，最好看模块数据手册）。最稳妥的供电方案是：USB 5V进入系统后，分成两路，一路直接给5V外设供电，另一路通过AMS1117-3.3稳压给MCU和3.3V外设供电。注意DHT11如果接5V，其数据引脚输出的是5V电平，需要串联一个1kΩ电阻再接到STM32的PA6，避免5V电平直接灌进MCU引脚造成损坏。

还有一点很关键：继电器动作瞬间电流突变可能造成电源电压跌落，导致MCU复位。解决方法是继电器电源尽量从主5V母线上单独取，并且并一个100uF电解电容和0.1uF陶瓷电容滤波；如果条件允许，用独立电源给继电器供电，或使用MOSFET输出的固态继电器模块。

3. 红外遥控空调：核心功能的原理与实现

3.1 空调红外协议的基本认知

如果说普通电视遥控器的NEC协议是“一个按键一个码值”的简单结构，那么空调遥控器就要复杂得多。一台空调的遥控器每次按键发出的不是一个固定键码，而是一整帧包含温度、模式、风速、扫风、开关机状态等所有信息的编码，通常长度在几十到上百位不等，而且不同品牌编码格式差异很大（NEC、Sony SIRC、Toshiba、Sharp、Mitsubishi等都有不同）。

这带来一个关键设计决策：是做“预设码库”还是做“学习型码库”？预设码库就是提前内置某几个品牌的空调码，优点是用户拿来就能用，缺点是空调品牌和型号太多，不可能覆盖全，而且有些新机型码值还会变。学习型码库则是让STM32自己解码空调遥控器发出的信号，把整个帧存下来，之后再用相同格式发送出去。这个方案通用性极强，任何品牌的遥控器只要电平时序能被捕获，就能学习并复现。

我的建议是选择学习型，这也是这个项目的特色所在。因为“学习”这个功能本身就能体现你对单片机定时器、外部中断和信号处理的理解，答辩时能讲的东西多得多。

3.2 红外解码：外部中断+定时器计时

实现学习功能的基础是精准测量遥控器红外信号的每一个高低电平持续时间。一个典型的NEC协议信号，引导码一般是9ms高电平+4.5ms低电平，逻辑1是560us高+1690us低，逻辑0是560us高+560us低。空调帧的时序虽然不同，但原理是一样的：我们需要测量一串高/低电平的宽度序列。

STM32上实现时间测量有两种常见思路。一种是外部中断配合定时器：将红外接收头输出引脚设为下降沿和上升沿都触发的外部中断，并在定时器里维护一个微秒级计数值，每次中断进入时读取当前计数值，与上次的差值就是这一段的电平持续时间。另一种是定时器输入捕获模式，把红外引脚接到定时器的CHx通道，硬件自动记录边沿时刻，更精准更占用CPU少。

第一次做这个功能时，我建议先用套路最直接的外部中断方式，因为逻辑清晰、出错容易定位。核心流程：

1. 初始化一个1us计数的基础定时器（比如TIM4），自由运行不清零；
2. 开启GPIO外部中断，上升沿和下降沿都触发；
3. 在中断回调函数里读取TIM4->CNT，记录到缓冲区数组，并记录当前电平状态；
4. 连续记录数组长度达到预定值或检测到引导码后，判定一帧接收结束；
5. 分析电平数组，按目标协议格式解析出0/1码流，存入Flash或外部EEPROM。

实际调试中会发现，红外接收头输出的是低电平有效的反相信号，也就是说对应遥控器发射的高电平，接收头输出低电平；代码里做状态记录时要注意逻辑取反，不然解析出来的码流正好翻转，发送出去空调无法识别。

3.3 红外发射：38kHz载波与脉冲时序控制

发射端相对解码要简单一些，关键就两点：把38kHz载波打开/关断，以及严格控制每个电平的持续时间。

具体做法：用一个定时器（比如TIM1）输出38kHz PWM，默认关闭PWM输出。要发红外信号时，按解析好的码流遍历每一个电平周期，周期内如果是高电平，就使能PWM输出；如果是低电平，就关闭PWM输出，同时用另一个忙等待延时函数保证电平宽度准确。

有人问为什么不用定时器中断去做发射时序，答案是用中断的话精度会受到其他中断的干扰，尤其和OLED刷新、继电器动作之类的任务混在一起时，容易产生几百微秒的抖动，而红外解码对这种抖动比较敏感。实际项目里更推荐关中断的忙等待方式，或者在RTOS里把发射任务设为最高优先级并关调度器。虽然忙等待浪费了一点CPU资源，但发射一帧最多百毫秒级，对系统整体毫无影响。

注意每个空调码帧之间要有一定的间隔（通常是50ms以上的低电平空闲时间），否则空调可能认为是同一个帧而忽略。这点在存入码库时也要一并保存帧间隔参数。

3.4 码库存储：用内部Flash保存学习结果

学习到的空调遥控码需要断电保存，不然每次重启都要重学一遍，实用性大打折扣。STM32F103C8T6自带64KB Flash，其中内置Bootloader占掉一部分，但你仍然有几十KB的Flash可用。把学习到的码帧（一般不超过200字节）存到内部Flash的最后几页即可，掉电不丢失，也不用额外接EEPROM或者Flash芯片。

不过要小心：内部Flash在写操作前必须先擦除整个扇区，而擦除操作可能导致MCU暂停执行代码。对一个不需要频繁写入的场景来说没问题。另外写Flash时最好关闭全局中断，防止写入过程中被中断打断。我的做法是：定义两个用户扇区，一个存空调码A，一个空调码B（可以学两台不同的空调），用一个标识字节判断是否已学习过。系统启动时读取这些区域，如果有效就直接加载到内存。

至于代码实现，官方提供了FLASH_ProgramWord/FLASH_ErasePage这类标准库函数，HAL库则对应HAL_FLASH_Program和HAL_FLASH_Erase，函数名不同但思路一致。这里不展开代码，但要提醒：写Flash前解锁、写完后加锁这个步骤不要漏掉。

4. 系统软件架构与功能实现

4.1 裸机状态机还是RTOS

很多新手一听到多个功能就想着上FreeRTOS，其实这个项目完全可以用裸机状态机跑得非常好。系统的实时任务只有红外解码和发射，发射是一次性的，解码是事件触发的，温湿度采集、OLED显示、按键扫描这些任务对实时性要求很低。用状态机配合定时器中断做1ms或10ms时基调度，比上RTOS更简单、更稳定，代码也更容易理解和答辩讲解。

我的代码组织方式是：主循环里放一个10ms定时器时基，通过标志位轮询执行非实时任务：温湿度采集（每2秒一次）、光照采集（每500ms一次）、OLED刷新（每200ms一次）、按键扫描（每20ms一次）。红外解码放在外部中断里，只负责填充缓冲区；解码完成后设置一个“帧完成”标志，主循环再去做协议解析和逻辑处理。这样中断里只做时间测量，不做事关业务的逻辑，响应性和稳定性都很好。

4.2 温湿度采集与数据处理流程

DHT11是单总线协议，时序要求比较严格：主机先拉低总线至少18ms然后释放，DHT11应答后输出一个40bit数据帧，包含湿度整数、湿度小数、温度整数、温度小数和校验和。数据位的判断依据是高电平持续时间：26~28us代表0，70us代表1。

这里有一个常见的坑：DHT11采样间隔要求大于1秒，连续读取容易导致读不到数据，返回值全为0。所以在状态机里要加一个“冷却时间”，比如每2秒才发起一次采样，读取失败就沿用上一次的有效值，并在日志里输出提示。另外DHT11对供电电压波动敏感，如果调试时数据时不时跳变，先量一下模块供电，波动大就要在供电端加滤波电容。

4.3 OLED显示与按键交互设计

OLED选0.96寸I2C接口的SSD1306方案，性价比高、驱动成熟。屏幕内容建议分几个页面：首页显示日期时间和温湿度、光照值；第二页显示空调控制参数（目标温度、模式、开关机状态）；第三页显示红外学习提示。通过三个按键切换页面和调节参数：按键1短按翻页/返回，按键2短按减，按键3短按加。

这部分的逻辑不多，但有一个体验细节：OLED刷新不要整屏全刷，可以只用局部更新区域，减少I2C通信量，避免和BH1750共用总线时互相拖慢。写显示驱动时把OLED_ShowString、OLED_ShowNum这些基础函数封装好，业务逻辑就清爽很多。

4.4 上位机控制：串口/蓝牙/WiFi三种方案

如果做的是毕业设计，强烈建议把“手机App控制”这个亮点加上。最简单的实现是使用HC-05/HC-06蓝牙模块，AT指令配置好后，STM32通过UART接收手机蓝牙调试助手发来的指令字符串，比如#ON开灯、#AC_ON开空调、#SET_TEMP_26设置26度，判断后执行对应动作并回复状态。

再进一步可以用ESP8266连接WiFi，通过AT指令访问OneNet或巴法云这类物联网平台。好处是远程可控，但坏处是需要额外写设备接入云的流程，涉及HTTP/MQTT协议，工作量明显增加。如果时间充裕建议做，做不出来也不影响项目完整性。

我这里要提醒一句：蓝牙串口调试时，最高频的坑就是波特率不匹配和回车换行符处理。STM32收到字符串后用strstr做子串匹配，而不是用strcmp做全串匹配，这样即使手机端多发了\r\n也能正常匹配。

5. 调试过程与常见问题排查实录

5.1 调试工具与手段

调试这个项目，示波器不是必需品，逻辑分析仪才是真正的效率神器。一个十几块钱的24MHz 8通道逻辑分析仪，配合PC软件，可以同时观察红外接收头的输出波形、PWM载波、串口数据，一眼就能看出时序问题。没有逻辑分析仪的话，退而求其次用GPIO翻转法：在关键代码段前后翻转一个空闲GPIO引脚，再用示波器或逻辑分析仪测这个引脚的波形宽度，也能分析程序执行耗时。

另外printf重定向到串口也是必备技能。STM32上把fputc重定向到UART，然后用串口助手打印调试信息，协议解析结果、传感器数据、错误状态一目了然。注意重定向时要加#include <stdio.h>，同时在Keil里勾选“Use MicroLIB”，否则printf可能不工作。

5.2 红外接收不到信号的排查步骤

这是我收到咨询最多的一类问题。接收不到信号，先不要怀疑程序，按下面顺序排查：

1. 检查红外接收头供电电压。HS0038B一般是5V供电，你用3.3V供电虽然也能工作，但接收灵敏度会明显下降；
2. 用手机摄像头对准遥控器发射管按按键，能看到紫色光点说明遥控器是好的；
3. 把红外接收头输出引脚接到逻辑分析仪，直接按遥控器，看有没有波形。没有波形，问题在硬件连接；有波形但程序解析不对，问题在软件时序；
4. 检查外部中断代码是否重复进入。GPIO抖动可能导致同一电平被中断多次，可以在中断里加一个“边沿锁存”标志，或者用输入捕获模式。

一个容易被忽视的坑：红外接收头的输出在无信号时是高电平，但有些模块板上带有反相器，输出可能是低电平空闲，读出的数据会全部反向。遇到解析结果和预期完全相反的情况，先拿逻辑分析仪看一下波形有没有反相。

5.3 学习成功但空调不响应，怎么办

能学习成功说明解码没问题，但不响应通常出在发射环节。第一步用逻辑分析仪看PA8输出的波形，确认38kHz载波频率是否正确。载波频率偏了太多（比如偏到36kHz或40kHz）会导致一些空调不识别，这是最常见的发射失败原因。STM32定时器产生38kHz PWM，需要根据时钟频率精确计算预分频和重载值，比如72MHz主频下，Prescaler=0，Period=1894，得到频率约38.016kHz，属于正常范围。

第二步检查发射距离和角度。红外发射管必须对准空调接收窗，且最好不要隔着玻璃。如果距离只有1米内还是不行，多半是三极管驱动电流不足，检查限流电阻是不是选得太大了。如果所有条件都正常仍不行，尝试增加发射帧的重复次数，有些空调要求同一个帧连续发送2~3次才能可靠接收，间隔100ms左右。

还有一个特别容易犯的错误：学习时把遥控器离接收头太近，导致信号过强饱和，波形变形；或者太远，波形边沿抖动。建议距离控制在3~10cm，保持垂直对准。

5.4 系统整体稳定性问题

智能家居系统是要长期运行的，稳定性必须重视。采集数据偶尔出错可以容忍，但系统无故死机、自动复位就很麻烦。常见原因和解决办法：

• 继电器动作导致复位：给继电器独立供电路，或者在电源端加续流二极管和滤波电容；
• OLED长期刷屏导致I2C死锁：在I2C通信超时后执行总线复位，或降低刷新频率；
• 长时间运行后DHT11响应超时：每次采样前复位总线状态，采样失败时静默跳过而不阻塞主循环；
• 红外解码缓冲区被覆盖：接收新帧前先判断上一帧是否已被处理，没处理完就丢弃新帧。

我最终跑通的版本，连续运行一星期没有出现需要手动复位的现象，电源稳定性是最大功臣。

6. 做这类项目的一些经验总结与扩展思路

6.1 我认为这个项目的价值所在

回看整个项目，最大的收获是它把“单片机裸机开发”和“实际使用场景”结合得很好。它不是纯粹的LED流水灯那种“为做而做”，而是解决了一个真实问题：给老空调加智能控制。学习型红外遥控这个功能拆解下来包含了信号测量、时序分析、PWM载波控制、Flash掉电存储等多个嵌入式核心技术点，任何一个点拿出来都能展开讲。而且它的难度曲线是循序渐进的，做出来以后对STM32定时器、中断、I2C、UART等外设的理解会有质的提升。

对于答辩或面试来讲，你可以从项目架构、代码组织、电源设计、信号完整性、低功耗考虑等多个角度谈，不会出现“只会抄代码说不清原理”的尴尬。

6.2 从实验室到入户的扩展方向

如果想把系统做得更接近产品，有几个方向可以继续深入。一是把上位机从蓝牙升级为真正的物联网平台，用ESP8266接入MQTT服务器，搭配手机App或微信小程序做定时控制、场景联动。二是加一个语音入口，比如接入离线语音识别模块（例如SU-03T），这样直接说“打开空调”就能触发。三是把控制策略从简单的阈值判断升级成模糊控制，比如根据温度和湿度综合决策空调目标温度，体感更舒适。

这些扩展点的技术路径都相对清晰，而且每一块都能作为新一轮项目的核心，适合持续迭代。

6.3 给后来人的实用建议

如果正在准备做这个题目，我给几条实操建议。第一，先把红外解码的硬件验证通过，再开始写其他功能，因为红外是最大的技术风险点，放到最后容易来不及。第二，传感器选型和接线以模块到手后实际测量为准，不要完全相信淘宝页面的引脚定义，尤其注意3.3V/5V二选一的传感器模块的跳线帽。第三，代码管理上养成用Git的习惯，哪怕只是本地仓库。这个项目会有大量“改一版试一下”的时刻，有版本回退能省很多时间。

具体到文档和代码风格上，每个模块的驱动用独立文件编写，函数命名统一，注释写明参数含义，时间久了连自己都会感谢当时的自觉。项目报告里把系统框图、硬件连接表、状态机图、测试数据这些梳理清楚，答辩和质量评审时基本就是按图说话，完全没有压力。

最后再分享一个小技巧：红外学习部分，不一定要把解析和存储做得非常复杂，可以先通过串口把解码后的电平时间打印到串口助手，对照逻辑分析仪的波形图，确认无误后再放到Flash。整个流程走通一次，后面的复制粘贴式移植就能快速交付。这套思路不仅适用空调遥控，所有基于红外的家电控制都能复用，本质掌握了，换什么设备都一样。

本文还有配套的精品资源，点击获取