基于STM32F103的智能台灯控制方案设计与复盘

做这类台灯项目之前，我其实走过一段弯路。最开始我拿洞洞板搭了一版纯硬件方案：用一颗单稳态触发器加 RC 做延时关灯，光敏电阻直接控制三极管来切换亮度。做完第一天确实能用，但在连续用了三个晚上之后，问题全出来了——RC 延时时间漂移严重，低温环境下明明没人也会触发；亮度切换伴随明显可见的闪烁；想增加一个“夜间小夜灯模式”完全无从下手。后来我把主控换成 STM32F103，把控制逻辑全部做了软件化重构，才真正体会到为什么这类“简单”的智能台灯，用一颗 Cortex-M3 来做反而才是性价比最高的选择。

这篇内容就是把那个版本的 STM32F103 智能台灯控制系统设计过程完整复盘一遍，从方案选型、硬件电路、固件架构到传感器数据处理和调试踩坑都会说到。无论你是正在准备课程设计的在校生，还是想把桌面台灯改造得更顺手一点的嵌入式爱好者，这套思路可以直接照着做，也可以按需砍掉一部分功能。

1. 方案选型：为什么是 STM32F103 而不是 51 或 ESP32

需求看起来确实不复杂：按键调光、环境光检测、人体感应自动开关灯、OLED 显示当前状态。很多人的第一反应是“这玩意儿用 51 都算大题小做”。但真正把需求列出来逐条核对资源，结论并不是那么理所当然。

1.1 隐藏在需求里的约束条件

智能台灯表面上是“灯”，本质上是“一个带多路输入的嵌入式控制系统”。它的核心工作量在于同时处理几路异步信号：

• 环境光传感器输出的是模拟量，需要 ADC 连续采样并做滤波；
• 人体红外传感器输出的是有宽度的脉冲信号，软件要做去抖和延时判断；
• 亮度控制需要至少一路可调 PWM，而且频率要足够高，不能让肉眼看到频闪；
• OLED 屏需要 I2C 或 SPI 接口，这个看似不起眼，但在 51 上纯 GPIO 模拟 I2C 配合 PWM 和 ADC 同时运转时，中断和轮询很容易打架；
• 如果后续还要加色温调节，那就是两路 PWM 加一路 RGB，甚至四路。

这些需求叠加之后，51 的处境就很尴尬了：定时器资源偏少，ADC 精度和速度不够，而且基于寄存器编程的开发方式在功能逻辑稍复杂时会明显拖慢节奏。我当然理解不少课程设计用 STM32F103 做台灯显得“用力过猛”，但足够多的定时器、独立 ADC、硬件 I2C 和成熟的 HAL 库，让你省下来的调试时间远超多出来的那点 BOM 成本。

1.2 三条技术路线的真实对比

就这套台灯系统而言，没有联网需求，传感器和执行器都是本地的，选择 ESP32 就像为了一个用不到的远程功能多买一张网卡。而 STM32F103 的硬件外设几乎完全覆盖了需求，并且因为 Cortex-M3 内核的性能余量很大，随便在主循环里跑状态机、滤波算法都不会出现实时性焦虑。简言之，选它是因为“每一分钱都花在了必要功能上”，同时给后续扩展留足了余地。

1.3 系统架构总览

整个系统可以拆成四个层：电源层、主控层、感知层、执行显示层。主控用 STM32F103C8T6，负责统合所有逻辑；感知层包括环境光采样、人体红外存在检测、以及三个物理按键操作；执行显示层通过 PWM 输出控制 LED 灯珠亮度，同时在 0.96 寸 OLED 上显示当前模式、亮度百分比和时钟状态。电源层则由外部 5V 适配器输入，经 LDO 降到 3.3V 给主控和传感器供电。

这个分层不是炫技，而是为了让我在调试的时候能分清“硬件故障”和“软件故障”的边界。电源或者驱动电路出问题，测电压电流就能锁定；OLED 不显示，先查 I2C 总线和初始化；按键失灵，优先怀疑 GPIO 配置以及是否漏了上拉。每一层内部又是相对独立的，改动算法不会影响驱动电路设计，这就是可维护性。

2. 硬件电路设计的三条主线：电源、调光、传感交互

硬件设计是整个项目里最不能“差不多得了”的部分。芯片选型错了可以换，布局没做好很容易引起一堆莫名其妙的软件问题。我按电源、LED 驱动、传感交互三条主线来讲，这是我调试时亲测效率最高的拆解方式。

2.1 电源系统：5V 适配器加 LDO，可靠且可复现

电源方案我直接放弃了阻容降压或变压器方案，原因是安全性和体积都不占优势。最终采用的是外接 5V/2A USB 适配器，板上用一个 1117 系列的 3.3V LDO 做两级转换。

这里有一个非常容易忽略的细节：LED 灯珠的驱动电压并不需要经过 LDO，而是直接使用 5V 供电，只有主控、传感器、OLED 这些低压逻辑器件才使用 3.3V。很多初版设计图把 LED 驱动也挂在 LDO 后面，结果负载电流一大，3.3V 被拉下去，OLED 就开始花屏，ADC 采样值也跟着飘。把功率回路和控制回路彻底分开，是这套硬件最关键的设计决策之一。

在 PCB 或洞洞板布局上，LDO 输入端和输出端各放一个 10uF 钽电容加 0.1uF 陶瓷电容作去耦，芯片手册都会写，但我见过太多人忽略陶瓷电容的位置，导致高频噪声没法就近泄放，OLED 和按键在启动瞬间出现异常。如果条件有限，至少保证电源入口处有一个容量足够的电解电容，稳住瞬间电流冲击。

2.2 LED 驱动：PWM 加 MOS 管，不用线性调光的根本原因

LED 亮度控制有两条路线：线性调光和 PWM 调光。

线性调光就是把电位器或者 DAC 输出的电压直接加在 MOS 管的栅极，让 MOS 管工作在线性区，通过改变导通程度来调节流过 LED 的电流。这个方案看似简单，实际坑非常多：MOS 管线性区功耗很大，低亮度时管子上几乎要吃掉一大半能量，发热严重；而且人对亮度的感知是非线性的，你很难通过一个电位器实现平滑的、从 1% 到 100% 的过渡。

所以我用的是低边 N-MOS 管做 PWM 开关，让 LED 灯珠以很快的速度进行通断切换，通过调整占空比来控制平均电流。N-MOS 管选的是 AO3400 这一类常用的低压小信号管子，栅极由 STM32 的 PWM 输出直接驱动，导通电阻在 RDS(on) 的量级上只有几十毫欧，几乎不发热。

具体电路拓扑上，5V 电源进来，经过限流电阻后串接 LED 灯珠，再接到 MOS 管的漏极，源极接地，栅极接 PWM 输出。这种低边驱动是初学者的首选，因为 N-MOS 管型号多、便宜、驱动逻辑简单，3.3V 的 PWM 高电平就可以把管子完全打开。如果未来想用共阳高边驱动，需要 P-MOS 管加电平转换，那是另一套玩法，不是这个项目所需的复杂度。

PWM 频率我设在了 20kHz 左右。低于 1kHz 时，摄像头或高速移动的物体下能看到明显频闪；高于 20kHz 时，虽然频闪消失，但 MOS 管开关损耗会略微增加，同时如果使用某些非隔离驱动器还会带来电磁干扰问题。20kHz 是视觉安全和效率之间的平衡点，也是大多数 LED 驱动方案默认采用的频率，我实测在这个频点上用手机慢动作拍摄，灯面稳定得就像恒定发光一样。

2.3 传感器与交互：光敏分压、人体红外、OLED 的接线与参数坑

环境光检测我用的是一颗 GL5528 光敏电阻。它的原理很简单：光线越强，阻值越低。实际电路把它和一个固定电阻串联，形成一个分压点，分压点电压接入 STM32 的 ADC 引脚。

关键问题是固定电阻的取值。理想状态下，应该在目标光照范围内让分压点电压尽量横跨 ADC 参考电压的中段，这样分辨率最高。以 GL5528 为例，它在明亮环境下阻值约 5-10k 欧姆，暗环境下约 200k 欧姆到数兆欧姆。取个经验值，串联 10-20k 欧姆的固定电阻就能得到跨度合理的电压变化范围。我用的是两个 10k 欧姆电阻并联成 5k 欧姆，实测在台灯亮度 0% 到 100% 的跨度里，ADC 采样值大约能从 600 跳到 2800 左右（12 位采样），动态范围足够做阈值判断了。

人体红外传感器选了 HC-SR501，这是市面上最常见的被动红外模组之一。它有三个接线脚（VCC、OUT、GND），输出的是 3.3V 电平的数字信号，可以直接接 GPIO 输入。两个调电位器分别调节灵敏度和触发延时，调试时我通常会先把延时调到最小（约 5 秒），方便快速验证逻辑，确认无误后再扩大。

OLED 显示模块则是标准的 0.96 寸 I2C 接口版本，SCL 和 SDA 分别接 PB6、PB7，再接 4.7k 上拉电阻。I2C 不上拉会直接导致屏幕无响应或显示随机花屏，这是新手最容易漏的一个地方。接线完整之后，所有传感器和按键接口都用 2.54mm 排针引出，方便调试时重新分配引脚，不用焊接飞线满天飞。

3. 固件实现：状态机、调光曲线与代码组织

硬件只是骨架，真正让台灯有“智能感”的是固件逻辑。这一章我不打算逐行粘贴整个工程，而是讲清楚最关键的三个结构：外设初始化时怎么配置不踩坑、主循环里的状态机怎么设计、以及 PWM 亮度曲线为什么不能用线性映射。

3.1 CubeMX 外设初始化清单与引脚分配

我用 STM32CubeMX 生成工程框架，时钟树配置为外部 8MHz 晶振，PLL 倍频到 72MHz 主频。这个主频对于本项目绰绰有余，给未来扩展红外遥控解码或者更复杂的滤波算法留了余量。

下面是最终使用的引脚分配，抄作业的时候可以直接对照：

CubeMX 里有三个地方容易出错：一是 I2C 速率我选了 400kHz，在长线连接 OLED 时，如果布线过差可能会拉不上，建议调试时先降到 100kHz，跑通后再提速；二是 ADC 连续采样模式要打开，不然每次都要手动触发会比较折腾；三是 PWM 的模式要选 PWM Generation Channel 1，而不是 Output Compare，两者代码生成结构和中断行为差异很大。

3.2 主循环加状态机：手动、自动、休眠的流转

台灯的软件核心是一个有限状态机，定义了三个主状态：

• 手动模式：用户通过按键直接控制亮度百分比，OLED 显示当前亮度值。
• 自动模式：根据环境光传感器采样值，自动调整 PWM 占空比，并叠加人体红外感应开关。
• 休眠待机模式：人离开超过设定时间（默认 60 秒）后自动进入，LED 熄灭，系统以低功耗状态运行，仅靠人体感应唤醒。

主循环里做的事情非常朴素：每 10 毫秒扫描一次按键，每 200 毫秒读取一次 ADC 光敏值并做滤波，每 500 毫秒刷新 OLED。状态机根据当前状态、外部事件和定时器计数决定是否切换。

代码核心结构大致是：

typedef enum { STATE_MANUAL, STATE_AUTO, STATE_SLEEP } SystemState; SystemState currentState = STATE_MANUAL; uint32_t lastPIRTriggerMs = 0; uint8_t manualBrightness = 50; void systemTick(void) { readAndFilterLux(); scanKeys(); updateStateMachine(); updatePwmOutput(); } static void updateStateMachine(void) { switch (currentState) { case STATE_MANUAL: if (keyAutoPressed()) { currentState = STATE_AUTO; } break; case STATE_AUTO: if (keyManualPressed()) { manualBrightness = currentPwmDuty; currentState = STATE_MANUAL; } if (infraredSensorActive()) { lastPIRTriggerMs = HAL_GetTick(); } if (HAL_GetTick() - lastPIRTriggerMs > AUTO_OFF_MS) { setPwmDuty(0); currentState = STATE_SLEEP; } break; case STATE_SLEEP: if (infraredSensorActive()) { currentState = STATE_AUTO; lastPIRTriggerMs = HAL_GetTick(); } break; default: currentState = STATE_MANUAL; break; } }

状态机的好处是逻辑清晰、容易扩展。比如加一个“夜灯模式”，只需要新增一个状态和对应的转移条件，而不需要去改主循环里层层嵌套的 if。我在这个项目里对状态跃迁额外加了一层“防误触”机制：任何模式切换必须持续按下按键 500 毫秒以上才算有效，避免用户只是轻轻碰到按键就导致亮度跳变。

3.3 PWM 调光曲线：人眼感知的非线性与伽马补偿

这是整个项目里最容易被忽略，但实际使用感受影响最大的一点。如果直接把占空比从 1 到 100 线性映射，你会觉得台灯“前面 10 级增益巨大，后面 90 级几乎看不清变化”。原因是人眼对亮度的感知遵循近似对数的斯蒂文斯幂律，即低亮度区对占空比变化极其敏感，高亮度区则相对迟钝。

解决办法是建立一个非线性的映射表，让占空比的变化速率在低亮度区更平缓，在高亮度区更陡峭。常见做法是用指数函数生成查找表：

const uint8_t gammaTable[101] = {0,1,1,1,2,3,4,6,9,12,16,21,27,34,43,54,67,82,100}; // 用指数曲线压缩低端，使视觉感受接近线性

实际实现时，我会直接把 LED 亮度等级定义为 0-100 级，gamma 表的生成公式是：

duty = (uint8_t)(100 * pow(brightnessLevel / 100.0, 2.2) + 0.5f);

系数 2.2 是常用的显示伽马参考值，但 LED 台灯使用中我发现 2.0-2.5 之间按个人喜好调整都合理。编译之前用 Excel 或脚本生成整表，烧录之后在最低亮度区间做几个点位的实测对比，眼睛舒服了再定稿。很多成品调光台灯之所以显得“高档”，本质上就是用了类似的曲线，而不是驱动多么玄乎。

3.4 代码文件结构：拒绝一坨 main.c

这个项目的总代码量不大，但如果不组织，很快就会变成“改一个功能牵一动一发”的局面。我把代码分成了硬件抽象层、业务逻辑层、用户界面层：

• hal_light.c：封装 TIM PWM 输出，提供 setBrightness(uint8_t level) 接口。
• hal_sensor.c：封装 ADC 光敏采样和 PIR 输入，对外返回滤波后的光照等级和人是否存在。
• app_state.c：状态机主体，管理模式迁移和定时器事件。
• ui_display.c：OLED 绘制逻辑，包括模式图标、亮度条、字符刷新。

这样分层最大的好处是：如果以后换了一颗主控，只需要替换 hal 层，app 和 ui 层基本不用动。如果只调 UI 界面，也不会影响传感器采集逻辑。课程设计答辩或者展示阶段，你甚至可以单独把你的业务逻辑层代码拿出来给别人讲解，结构一目了然。

4. 传感器数据的工程处理：滤波、迟滞与联动逻辑

单片机世界里最不缺的就是“看起来能跑、实际体验稀烂”的教训。传感器裸数据直接拿来用，通常等于给自己挖坑。智能台灯对环境光和人体感应的处理，是决定成品体验感的另一个分水岭。

4.1 环境光采样：用滑动平均还是防脉冲干扰

ADC 读到的光敏电压并非稳定值，它可能受到灯珠 PWM 噪声的耦合干扰，也可能因为日光灯或屏幕的低频波动出现跳变。直接把单次采样值拿来做阈值判断，结果就是亮度在临界点附近反复横跳，台灯在自动模式下闪个不停。

我的处理方式比较简单实用：采用 8 次滑动平均滤波，每次采样间隔 20 毫秒，也就是说滤波窗口覆盖 160 毫秒。这个窗口尺寸可以滤掉大部分的瞬时毛刺，同时比均值滤波更能保持对真实光照变化的响应速度，不会让人在台灯前站了半天，亮度才慢吞吞地跟上。

uint16_t filteredADC = adcSamples[ (sampleIndex++) & 0x07 ]; uint32_t sum = 0; for (int i=0; i<8; i++) { sum += adcSamples[i]; } uint16_t avg = sum / 8;

代码层面没有精致到用环形缓冲，直接用固定数组和取模索引循环覆盖，够用且易读。如果采样频率更高或者传感器更敏感，我会再引入中值滤波先剔除异常值再做平均，但当前项目在这个处理上已经足够。

处理完滤波之后，再把 ADC 值映射成 0-100 的“环境光等级”，我用了线性映射加高低限幅。因为在室内环境，ADC 读数不会跑到 0 或 4095 的全范围，所以把下限值校准到暗室读数、上限值校准到台灯下近距离读数，才能让映射曲线覆盖到真实工作区间。

4.2 迟滞阈值：避免临界点自动模式闪跳

如果说滤波解决的是“数据毛刺”，那么阈值卡在边缘的问题必须靠迟滞比较来解决。自动模式的逻辑是：当环境光偏暗时，自动开启台灯并调整到一个基础亮度；环境光充足时，自动降低亮度或关灯。

如果只设一个阈值，环境光略微波动时系统就会频繁开关灯。我的做法是设定两个阈值点：开启阈值和关闭阈值。只有光照等级高于关闭阈值（例如 65 时）才允许关灯，只有光照等级低于开启阈值（例如 35 时）才触发开灯。中间的 35-65 区间是一个滞回带，系统保持原状态不变。

if (lightLevel < OPEN_THRESHOLD && currentState == STATE_AUTO) { targetDuty = autoBaseDuty; } if (lightLevel > CLOSE_THRESHOLD && currentState == STATE_AUTO) { targetDuty = 0; }

这个设计借鉴了模拟电路里施密特触发器的思想。聪明的读者会发现，我在这里还加了一个“超时接管”判断：环境光变亮导致自动关灯不会立即执行，而是先做一个 10 秒的观察窗口，连续 10 秒都超过关闭阈值才真正关灯。这样可以规避有人一会儿把手伸到传感器上方挡住光线、一会儿又拿开造成的闪烁。

4.3 人体红外感应去抖与自动关灯计时

HC-SR501 的输出是数字电平，但这不代表它不会误触发。常见误触发来源包括：热空气流动、空调风口、窗外驶过的车辆灯照到透镜等。硬件上虽然有灵敏度电位器可以调，但软件层面的去抖必不可少。

我的方案是在状态机里额外维护了一个“触发确认计时器”：PIR 输出高电平时不会立即改变任何状态，而是连续保持高电平 300 毫秒以上才认为现场有人。这样做的代价是响应延迟 300 毫秒，在台灯场景里完全不可感知，却能把大部分瞬态误触发挡在门外。

自动关灯的延时逻辑也放在状态机中。任何人最后一次触发的时刻都会被记录，当它距当前时间达到设定的延时值（默认 60 秒）时，系统进入休眠模式。这不是简单的“收到低电平就关灯”，而是需要软件持续跟踪最后一次触发时间，因为我们用的是 PIR 的有信号触发模式，人坐着不动时，PIR 不会持续输出高电平，但设备不应该因此立刻关灯。

4.4 模式协同：手动模式不覆盖自动模式，两者不打架

自动模式有一个常见边界问题：如果用户不想被自动调节打扰，比如正在台灯下看书，头顶阳光正好处在临界阈值附近，手动干预应该具有最高优先级，但后续环境变化时，系统又应该能平滑地回到自动策略。

我在状态机里做了一个折衷设计：用户长按亮度按键进入手动模式后，手动亮度会写入全局变量，同时自动侦测仍然在后台运行，但自动侦测的结果不会立即生效，而是做成“建议值”，仅在 UI 上显示一个小小的图标提示“环境光变化，建议进入自动模式”。直到用户自己再次切回自动模式，自动控制才恢复。这种方式比直接抢占 PWM 输出更符合实际生活习惯，也是我用了之后觉得最舒服的一套交互逻辑。

5. 调试实录：三个高频坑位的排查链路

做硬件项目，必然要面对“明明代码看起来没问题，怎么实际跑起来就是不对”的时刻。下面这三个问题是我在这套系统上实际踩过并解决的，也是嵌入式新手最容易卡住的地方。

5.1 台灯低亮度下的“水波纹”和摄像头频闪

第一版固件里我把 PWM 频率设置为 1kHz，想着这个频率人眼应该看不见闪烁了。结果用手机慢动作拍摄，灯面纹波特别明显；还在一个偶然的场合发现，台灯旁边用普通摄像头录像，画面上会出现横向滚动条纹。

这一步锁定了问题方向：PWM 频率和摄像头曝光行频之间产生了差频干扰。解决办法并不复杂，一是把 PWM 频率提高到 20kHz，彻底跳出普通摄像头采样频率的谐波范围；二是我在 LED 驱动回路里增加了一个小容量的滤波电容，串接在灯珠两端，稍微减缓开关转换瞬间的电流尖峰。两招下去，手机慢动作画面里的灯面彻底干净了。

调试时注意，不能盲目地一味提升 PWM 频率。频率过高时，驱动 MOS 管的栅极寄生电容充放电损耗会上升，20kHz 在这个项目中是安全和效率的最佳折中。

5.2 人体红外传感器阳光直射下的误触发

有一次我把台灯放在窗边测试，白天阳光直射到 PIR 传感器的透镜上，结果明明没有人，台灯每隔几十秒就会自动亮起来。起初我还以为是传感器硬件损坏，换了一个新的依旧如此。

花了很长时间才排查清楚：PIR 传感器内部的探头对红外辐射敏感，阳光直射会在传感器表面产生显著的热梯度变化，而这和人体红外信号在电气特性上非常接近。解决办法不是在软件上做更复杂的滤波器——硬件物理遮挡才是最有效的手段。我把传感器做了一点角度调整，使其不直接面对窗户，同时把灵敏度电位器调小一档。此后误触发率大幅下降。

这个问题反映出嵌入式调试的重要原则：某些软件层面的缺陷，根源却是硬件环境或布局问题，不要试图用更复杂算法掩盖物理现象。

5.3 ADC 采样值大幅跳变：电源纹波与采样时序分离

自动模式调试过程中，我发现环境光 ADC 读数会周期性跳变，每次跳变约 200 个数，灯也会随之轻微波动。用万用表量 LDO 输出，3.3V 电压纹波看着正常，但用示波器抓细节才发现，当 PWM 从 20% 切换到 80% 占空比时，5V 供电轨上会有一个明显的毛刺尖峰，这个尖峰通过地线耦合回了 ADC 参考电压。

我当时做了两件事：一是 ADC 采样时刻避开 PWM 电平变化瞬间，在硬件定时器里精确控制采样窗口，让它在 PWM 周期内固定相位点触发；二是 ADC 的地线走线从主控电源线路独立出来，减少干扰耦合路径。改完代码重新测，ADC 跳动从 200 降到 5 个 LSB 量级，灯面完全稳定。电源和采样时序分离，是这套系统稳定性的第二根支柱。

6. 实测效果与可扩展方向

这台台灯系统整体搭完并连续运行了一周之后，实际表现很符合我的预期。手动模式下亮度从 1% 到 100% 的调节曲线很顺滑，没有低端突变；自动模式下从窗前换到室内暗处，3-4 秒内能平滑跟随；人离开 60 秒后灯自动熄灭，回来后只需 0.5 秒左右就能重新亮起。

如果后续继续迭代，三个方向我认为最值得考虑。一是低功耗模式，虽然 STM32F103 的 STOP 模式可以进一步降低待机功耗，但人体感应器和 LDO 自身的静态电流仍不可小觑，需要专门设计分路供电策略才能真正实现“长时间待机”；二是双路 PWM 色温调节，只需改用四路 LED 灯珠阵列并加一颗双通道 MOS 管，代码里增加一个 colorTemp 目标变量即可；三是把传感器数据汇总到上位机校准，在 PC 端可视化观察不同光照条件下的 ADC 值和占空比，这对调试自动模式的主观感受极有帮助。

最后分享一个我个人的使用心得：这套系统的核心并不是某个惊艳的算法，而是“状态机把所有模块的协作关系理得清清楚楚”，再加上“调光曲线和滤波逻辑让体验细节经得起推敲”。做智能台灯这类产品级小项目，功能不难，难在把这些微不足道的小事逐一做好。希望这篇复盘能帮你少走几段弯路，直接抄到一个舒服的起点上。