企业官网建设流程全解析

做智能恒温热水器控制系统，可以说是STM32入门阶段最有代表性的综合性练手项目了。它把GPIO操作、单总线协议、定时器PWM、外部中断、LCD显示驱动和基础闭环控制全部串在一起，做完一个项目，等于把单片机的大部分核心外设都过了一遍。我最早带学生做毕设时，就经常推荐用这个题目来入门，因为难度适中、可展示性强，而且Proteus仿真环境下就能完整跑通，不需要真实硬件也能把整个系统的逻辑理解透彻。今天这篇就把这个项目的完整拆解写出来，从方案设计到仿真搭建再到代码实现，最后附上我实际调试中踩过的坑。

1. 项目整体设计与思路拆解

1.1 这个项目到底在解决什么问题

智能恒温热水器，核心需求就一句话：让水温稳定保持在你设定的温度附近。听起来简单，但落实到具体系统上，牵扯到的细节并不少。水温会随着散热和进水自然下降，加热器件又有热惯性，如果控制逻辑太粗暴，水温会在设定值附近来回震荡，忽冷忽热，体验很差。

所以这个项目的本质，是一个典型的单输入单输出闭环温度控制系统。输入是当前温度和目标温度的偏差，输出是加热器的通断控制。要实现这个闭环，系统必须包含四个基本环节：温度采集、逻辑判断、加热驱动和人机交互。

在Proteus仿真环境里做这个项目，正好可以把这四个环节一一对应到具体模块上。温度采集用DS18B20数字温度传感器，逻辑判断由STM32F103C8T6完成，加热驱动用继电器控制加热丝模型，人机交互则通过LCD1602显示屏和独立按键来实现。

我遇到过不少同学拿到这个题目后第一反应是去淘宝买套件，其实大可不必。仿真环境里先把电路和逻辑跑通，理解每一步的工作原理，后面再做实物，就是水到渠成的事情。而且Proteus仿真有个实物比不了的优势——可以随意修改参数、人为制造故障，调试效率高得多。

1.2 为什么选STM32F103C8T6而不是其他芯片

先说芯片选型。STM32F103C8T6是Cortex-M3内核，主频72MHz，Flash 64KB，RAM 20KB，在这个项目里可以说是杀鸡用牛刀。但选它有两个现实原因。

第一是资料极其丰富。不管是正点原子还是野火的教程，还是网上乱七八糟的例程，绝大多数都是基于F103系列的。遇到问题随便搜一下就能找到解决方案，这对新手来说太重要了。

第二是Proteus仿真库支持完善。Proteus 8.x版本对STM32F103系列的支持已经很成熟了，DS18B20、LCD1602这些外设模型也都有现成的，不需要额外去搞第三方库文件，连虚拟终端都能直接用。这点对仿真党来说非常友好。

当然，如果后面要做实物低功耗版本，可以考虑换STM32L系列或者用国产的GD32替代，但那是后话。做学习和课程设计，F103C8T6是最稳的选择，没有之一。

1.3 系统模块划分与信号流向

整个系统的信号流是单向为主的，从传感器到处理器再到执行器和显示器，逻辑非常清晰。我习惯把系统拆成五个功能模块来理解和调试：

• 电源模块：仿真中直接用虚拟电源，实物中需要降压电路给芯片和传感器供电。
• 温度采集模块：DS18B20通过单总线协议将温度数据传给STM32。
• 控制核心模块：STM32运行控制逻辑，输出控制信号。
• 加热执行模块：继电器根据控制信号通断加热丝。
• 人机交互模块：LCD1602显示当前温度、设定温度和系统状态，按键用来调整设定值。

模块化设计的最大好处是调试时可以分步验证，不用在一大坨代码里翻找问题。我先保证温度采集正常、显示正常，再写控制逻辑，这样每一步出问题都能立刻定位到具体环节。

2. 仿真环境搭建与硬件模型选型

2.1 Proteus版本选择与工程配置

Proteus仿真是这个项目能脱离实物运行的关键。版本上建议直接用Proteus 8.15以上版本，因为对STM32的调试支持更完整，支持Co-Simulation方式。如果电脑配置差一些，8.9或8.11也能跑，但有些新元件模型没有。

新建工程时有几个关键选项容易忽略。第一是PCB布局选项，纯仿真项目不需要勾选。第二是BOM清单，如果只是仿真验证，可以不启用。我在最初使用时，经常多勾了一些选项，导致工程文件结构复杂，后面找文件都费劲。

还有一个很多人不知道的技巧：Proteus工程的默认元件库并不包含所有型号，搜索STM32F103C8T6时，关键词不要输入全称，输入STM32F103C8就能出结果，因为Proteus的搜索匹配机制对部分关键字符支持更友好。同理，搜索DS18B20直接输入18B20也能找到。

2.2 LCD1602引脚连接与显示原理

LCD1602是市面上最常见的字符液晶模块，16个引脚，能显示两行每行16个字符。很多人一看到16个引脚就头大，其实真正需要接的没几个。数据线DB0-DB7占8个，加上RS、RW、E三个控制线，如果只做写入操作，RW直接接地固定为写模式。这样算下来只需要接11根线。

Proteus里LCD1602的仿真模型引脚顺序和实物略有差异，这个一定要以模型为准，不能想当然。关键是RS和E两个引脚的位置，接反了屏幕什么都不显示，但程序又不会报错，属于那种怎么看都找不到问题在哪的经典故障。

LCD1602的初始化时序是固定的：先等待40ms以上让模块上电稳定，然后连续写三次0x30设置为8位接口，再进入功能设置、开关显示、清屏等指令。这一串时序代码网上到处都是，但真正重要的是每条指令之后都要检测忙标志或者延时等待，否则后续指令会被忽略。

在实际项目中，我建议把LCD驱动封装成独立文件，提供LCD_Init()、LCD_SetCursor()、LCD_WriteString()这几个接口函数即可。这样主程序逻辑清晰，LCD相关改动也不需要牵涉其他模块。

2.3 DS18B20温度传感器仿真模型关键点

DS18B20是Dallas公司生产的单总线数字温度传感器，测量范围-55℃到+125℃，12位分辨率下精度可以达到0.0625℃。单总线的意思就是数据线和电源线可以共用一根线，但实际使用中还是建议数据线上加4.7k上拉电阻，保证信号稳定性。

在Proteus仿真中有一个容易踩坑的地方：模型对时序的要求比实物更严格。实物的DS18B20时序容错范围比较宽，但仿真模型在某些版本中非常敏感，延迟参数稍微不对就返回85℃或者直接通信失败。所以在写DS18B20驱动时，延时函数的精度非常重要，尽量使用定时器或SysTick延时，不要用简单嵌套循环。这也是很多同学在仿真中温度读取失败的最常见原因。

DS18B20的操作流程分三步：复位、ROM命令、功能命令。因为系统只有一个传感器，ROM命令可以直接使用跳过ROM（0xCC），省去搜索ROM的复杂逻辑。功能命令分两步走：先发转换命令（0x44）启动温度转换，等待转换完成后发读暂存器命令（0xBE）读取两个字节的温度数据。数据的高字节和低字节组合成16位有符号数，再除以16就是实际的温度值。

2.4 继电器驱动与加热模型

加热执行机构在实物中通常是大功率电热管，控制端用继电器或者固态继电器来做通断切换。在Proteus仿真里没有真实的大功率器件模型，可以用一个简单的灯泡或电阻网络来模拟加热丝，通过观察继电器触点的状态来判断加热是否开启。

仿真电路里我习惯用“继电器+指示灯”的组合。继电器线圈由STM32的GPIO通过ULN2003达林顿管驱动，这更贴近实际电路。这样做的好处是，不管最终做不做实物，至少电路原理层面是正确的。有些同学图省事，直接用GPIO接继电器线圈的模型，这在仿真里能跑，但拿到实物上就会烧GPIO口，属于典型的仿真和实物脱节。

GPIO驱动继电器时，还要注意输出电平的逻辑。STM32的GPIO默认是推挽输出，上电瞬间输出低电平比较安全。所以继电器的控制逻辑应该是低电平有效——给低电平继电器吸合、高电平断开。如果默认是高电平，STM32上电瞬间可能触发一次误动作，热水器“啪”一下开始加热，这是绝对不允许的。

3. 核心控制逻辑与代码实现

3.1 恒温控制策略：滞回控制为主，PID为辅

温度控制最容易犯的错误是“拼命精确”。很多人一上来就写PID，非要让温度精确到0.1℃，结果在仿真里反复震荡，数据曲线跟心电图似的。其实对于水温控制这种大惯性、低响应频率的系统，滞回控制才是简单可靠的选择，这也是实物智能热水器最常用的控制方式。

滞回控制的核心思想是设置上下限阈值。例如目标温度设定为45℃，滞回区间设为2℃，那么当水温低于43℃时启动加热，当水温升高到47℃时停止加热。这样加热器不会频繁通断，系统稳定性和机械寿命都更好。

切换逻辑怎么写呢：

if (current_temp < target_temp - HYSTERESIS_HALF) { HAL_GPIO_WritePin(HEAT_RELAY_GPIO_Port, HEAT_RELAY_Pin, GPIO_PIN_RESET); // 开启加热 } else if (current_temp >= target_temp + HYSTERESIS_HALF) { HAL_GPIO_WritePin(HEAT_RELAY_GPIO_Port, HEAT_RELAY_Pin, GPIO_PIN_SET); // 停止加热 }

滞回区间的设置与实际应用场景强相关。洗澡用水一般要求37℃到45℃，温差感知约±1℃，所以滞回区间设2℃左右比较合理。鱼缸恒温要求精度高一些，可以考虑把滞回区间缩小到1℃，甚至直接用简化版PID控制。

如果想让项目更有技术含量，可以在滞回控制的基础上增加一个“预判”逻辑。当检测到温度下降速率较快时（比如打开进水阀），提前启动加热，这就是前馈控制的雏形。这种优化在论文或项目报告里是非常加分的创新点。

3.2 定时器与PWM在加热控制中的应用

滞回控制决定了加热器的通断，但如果要更精确地控制加热速率，就可以引入PWM控制。STM32F103的定时器输出PWM信号，通过改变占空比来控制继电器在单位时间内的导通比例，间接控制加热功率。

举个例子，如果温度已经接近目标值，还差0.5℃，直接全功率加热很容易超调。这时可以把PWM占空比设为30%，继电器在1秒周期内导通0.3秒、断开0.7秒，加热功率就只有全功率的三成，温度爬升速率明显变缓。

在Proteus仿真里验证PWM控制，可以用一个电压表监测加热丝两端的有效电压值。占空比不同，电压表的读数会不同，这样就能直观看到PWM的效果。

PWM初始化代码用STM32的硬件定时器很简洁：

// 初始化TIM2通道1输出PWM，频率1kHz void PWM_Init(void) { GPIO_InitTypeDef gpio_init = {0}; TIM_HandleTypeDef htim2 = {0}; TIM_OC_InitTypeDef oc_config = {0}; __HAL_RCC_TIM2_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); gpio_init.Pin = GPIO_PIN_0; gpio_init.Mode = GPIO_MODE_AF_PP; gpio_init.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, &gpio_init); htim2.Instance = TIM2; htim2.Init.Prescaler = 72 - 1; htim2.Init.Period = 1000 - 1; htim2.Init.CounterMode = TIM_COUNTERMODE_UP; HAL_TIM_PWM_Init(&htim2); oc_config.OCMode = TIM_OCMODE_PWM1; oc_config.Pulse = 0; oc_config.OCPolarity = TIM_OCPOLARITY_HIGH; HAL_TIM_PWM_ConfigChannel(&htim2, &oc_config, TIM_CHANNEL_1); HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1); }

PWM频率的选择也值得细说。继电器控制的PWM频率不能太高，普通继电器机械响应时间在5ms到15ms左右，PWM频率超过50Hz继电器就可能来不及响应，线圈一直处于吸合或释放的中间状态，发热严重甚至烧毁。所以我实际项目中PWM频率都设得很低，比如5Hz到10Hz。如果是控制固态继电器或者MOSFET，频率可以提高到几百赫兹甚至几千赫兹，那就是另一套方案了。

3.3 按键扫描与参数设置实现

恒温热水器必须有温度调节功能。我用三个独立按键来实现：加键、减键和模式切换键。按键的扫描方式有两种选择：在主循环里轮询，或者用外部中断。考虑到按键数量少且对实时性要求不高，主循环轮询扫描加软件消抖就够用了。

软件消抖的原理很简单：检测到按键按下后，延时20ms再次检测，如果仍然是按下状态，就认定有效。这个20ms是根据机械按键弹跳时间来的，大多数按键的弹跳时间在5ms到10ms之间，留出两倍余量即可。

按键设置温度时需要注意取值范围限定。热水器的安全温度上限一般设为60℃，下限设为20℃。超过这个范围就忽略操作。代码实现时用条件判断即可，但注意要处理好数值溢出问题。有些同学在写加键逻辑时直接把设定值加1，没判断上限，结果设定值变成61℃甚至更高，这在仿真实物中都是安全隐患。

按键还有一个用户体验优化：长按连续加。按下加键超过1秒后，每隔100ms自动加一次。实现逻辑不复杂，记录按键按下的时间戳，在轮询中判断当前时间与按下时间差是否超过阈值。这个功能在实物中非常实用，避免用户从20℃调到45℃要按25次按键。

3.4 LCD数据显示与状态提醒

LCD显示的内容布局也需要花心思设计。我习惯第一行显示当前温度和设定温度，格式为T:25.5C S:45C，第二行显示加热状态和工作模式。如果想显示中文提示，LCD1602的字符库覆盖不到那么多汉字，可以自定义字库字符，或者直接换LCD12864。但对于热水器控制场景，英文缩写提示完全够用，没必要增加成本和复杂度。

LCD显示的刷新频率也有讲究。DS18B20完成一次温度转换最长需要750ms（12位分辨率下），所以LCD不需要也不应该高频刷新。我在主循环里每500ms刷新一次LCD数据，这样既能看到温度变化趋势，又不会因为刷新过于频繁导致显示闪烁。

温度数据是浮点数，LCD显示时要转换成字符串。这里建议避免直接使用sprintf，因为标准库的格式化函数会占用大量Flash和RAM空间，在小内存单片机上不太划算。我一般自己写一个简单的浮点转字符串函数，或者把温度值乘以10转成整数，分别取十位、个位和小数位，这样可以避免庞大的库依赖。

void DisplayTemperature(float temp) { int temp_int = (int)(temp * 10); // 转换为整数，如25.5 -> 255 char temp_str[5]; temp_str[0] = '0' + (temp_int / 100) % 10; temp_str[1] = '0' + (temp_int / 10) % 10; temp_str[2] = '.'; temp_str[3] = '0' + temp_int % 10; temp_str[4] = '\0'; LCD_WriteString(0, 2, temp_str); // 第一行第二列开始显示 }

这种写法的好处是完全没有依赖任何库函数，代码体积小，而且不容易出现浮点格式化的意外问题。代价是要自己处理负温度和各种边界情况。对于热水器这种应用场景，温度基本在0℃以上，所以逻辑可以简化。

4. Proteus仿真实操流程与联调

4.1 新建Proteus工程与元件放置

Proteus仿真电路图的搭建步骤我按实际操作顺序来写。

打开Proteus后，选择新建工程，工程名称建议取拼音或英文，比如Smart_Heater，不要用中文名，否则后面有些版本会出编码问题。原理图名称同样用英文。

接下来从左侧工具栏的元件模式（Component Mode）下点击“P”，进入元件搜索。依次添加以下元件：

• STM32F103C8T6：搜索 STM32F103C8
• DS18B20：搜索 DS18B20
• LCD1602：搜索 LM016L（这个型号在Proteus里更常用，就是两行16列字符屏）
• 继电器：搜索 RELAY，选一个单刀双掷型号
• ULN2003：搜索 ULN2003
• 电阻、按键、LED等基础元件在库中直接都有

需要特别注意，Proteus里LM016L模型和常见的LCD1602虽然功能一致，但引脚编号排列不一样，连接前要仔细核对模型引脚名称。我自己第一次画电路时，就照着网上教程里的LCD1602引脚定义接了，结果在Proteus里显示的引脚编号对不上，查了半天才发现型号不对。

4.2 电路连接与实物布局逻辑

元件放置好之后，按照信号流向连接电路。连接时我习惯用不同颜色的线来区分信号类别：红色接电源，黑色接地，蓝色连数据信号，绿色连控制信号。这样做的好处是后期检查电路时一目了然，不用反复追踪线的走向。

具体接线逻辑如下：

STM32的PA0-PA7接LCD的数据DB0-DB7，PA8接RS，PA9接E。RW直接接地。DS18B20接PB0口，数据线加上拉电阻。继电器驱动信号从PC0输出到ULN2003的输入1，ULN2003的输出1接继电器线圈。按键分别接PB1、PB2、PB3，另一端接地。每个按键并一个10k上拉电阻。

电源部分在仿真里直接接VCC/GND符号即可，不需要额外的稳压电路。但要注意STM32模型默认有多个VDD和VSS引脚，每个都要接上，漏接一个会导致仿真跑不起来或者运行异常。

连接完成后，建议做一次基础检查。点击仿真运行按钮，如果弹出警告窗口，根据警告信息逐个排查。最常见的警告是“Net not connected”（网络未连接）和“Pin not driven”（引脚未被驱动），前者多半是线没接上，后者通常是有引脚悬空。

4.3 Keil工程配置与代码烧录

STM32的代码用Keil MDK编写，先建立Keil工程。芯片型号选择STM32F103C8，在Device页面输入关键词C8即可找到。

工程配置有几个关键点。Debug页面选择“Use Simulator”或者“Use”下拉中选择Proteus VSM Simulator。如果选择后者，Keil可以和Proteus联调，在Keil里打断点、单步调试，Proteus会同步响应，这是非常强大的调试功能。实现方式是在Proteus的Debug菜单中启用“Remote Debug Monitor”，然后在Keil的Options for Target的Debug页面中选择Proteus VSM Simulator，两个软件就可以联动。

很多人不知道，Keil的仿真器选择和代码下载没有直接关系。如果只是把编译好的HEX文件手动加载到Proteus的STM32芯片里，那Keil里选择哪一款调试器都无所谓。要看懂的是HEX文件生成路径。在Options for Target的Output页面勾选“Create HEX File”，编译后就会在工程目录的Objects或Listings文件夹下生成HEX文件。

加载HEX文件的方法是：双击Proteus中的STM32芯片，在Program File一栏选择生成的HEX文件。然后点击运行，程序就开始执行。

我推荐使用联调模式，因为可以在Keil里直接设置断点，观察变量的实时值。比如在温度读取函数返回后打断点，查看温度变量是否正确，这样能极大提升排错效率。

4.4 仪表与交互调试技巧

Proteus仿真的一大优势是可以在电路上挂各种虚拟仪表。调试加热控制时，用一个电压表并联在加热丝两端，可以观察加热过程电压情况；调试DS18B20时，可以在器件模型上直接修改环境温度参数，观察程序是否响应。

在Proteus中模拟环境温度变化有几种笨但有效的办法。一是直接双击DS18B20模型，调整它的温度值。但这样是瞬变，不能模拟温度缓慢变化过程。

实际操作中，我穿插了一种更接近真实系统的做法——在电路中增加一个模拟温度变化的信号源？这个比较麻烦，因为DS18B20是数字传感器，不能直接接受模拟信号。为了验证滞回控制的动态响应，最好的方式是修改DS18B20的模型温度参数，观察LCD上温度值和加热器状态的变化是否符合预期。

比如初始温度25℃，设定目标45℃。运行时先把DS18B20模型温度降低到20℃，看继电器是否吸合加热。然后每次手动上调模型温度1℃，观察继电器会不会在温度到达47℃时释放。这样一帧一帧地手动改变温度，就能完整验证整个控制逻辑。

5. 常见问题与排查技巧实录

5.1 温度显示85℃或无法通信

这是DS18B20相关项目里最常见的问题，仿真和实物中都频繁出现。85℃在DS18B20的数据手册里有一个特殊含义：当芯片上电时暂存器中的温度数据默认值就是85℃。如果程序复位后没有发出转换命令就直接读取，就会一直读到85℃。

排查方向有三个：第一，检查GPIO配置是否正确，是否配置为开漏模式且外部挂了上拉电阻；第二，检查延时函数是否准确，单总线时序对微秒级延时要求比较高；第三，检查是否在转换完成后才去读温度数据。

我实际调试中最常发现的问题是延时不对。有人用HAL_Delay()来提供微秒延时，但HAL库的HAL_Delay()最小单位是1毫秒，根本无法实现DS18B20需要的几微秒的延时。解决方案是使用DWT->CYCCNT或者直接写空循环计算时钟周期。这里建议自写微秒延时函数：

void delay_us(uint32_t us) { uint32_t ticks = us * (SystemCoreClock / 1000000); DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; while (DWT->CYCCNT < ticks); }

在Proteus仿真中，如果仿真速度很慢，也需要考虑延时是否被拉长。Proteus的仿真模式默认是“实时”的，但一旦电路复杂或者配置了动画，仿真速度就会低于真实时间，这会导致DS18B20的时序错乱。解决方法是进入菜单“System -> Animation Options”，在“Frames per second”选项处适当调高帧率，或者关闭部分动画效果。

5.2 LCD1602显示乱码或白屏

LCD1602显示乱码的原因大致几类。一类是数据线接错顺序，DB0和DB7两根线接反了，或者RS和E接反了，都会导致显示异常。另一类是初始化时序不对，特别是上电后等待时间不够。LCD1602上电稳定需要40ms以上，如果等待时间不够就发指令，模块可能没有完成内部复位，后续指令全被忽略。

还有一个非常隐蔽的问题：Proteus里LM016L模型的数据方向。LCD1602的DB0-DB7是双向数据总线，虽然我们只写不读，但模块在接收到某些指令后会把数据线设为输出状态，如果STM32的GPIO也配置为推挽输出，两条强驱动信号就会互相冲突。在Proteus模型里虽然没有物理损坏的问题，但会造成电平不确定，表现就是显示乱码。解决方案是LCD数据线方向不需要特殊处理，仿真模型一般会自动处理，但如果是实物，就要在读写方向上交替配置GPIO方向寄存器。

在Proteus中，LCD白屏还有一种可能：VSS和VDD接反了，或者对比度调节引脚V0悬空。实物中V0需要接电位器调整对比度，仿真模型虽然不需要，但部分版本如果V0悬空也可能显示空白。解决方法是直接给V0接一个10k电位器，动一下就能看到显示效果变化。

5.3 Proteus仿真运行缓慢或卡死

电路仿真发生缓慢的根源通常是CPU占用过高。STM32模型在仿真中模拟CPU执行指令本身就需要大量计算，如果代码里还有长时间空转的延时循环，仿真速度会变得更慢。尤其是在使用while空循环的延时时，Proteus要逐条模拟这些空指令，这比真实运行速度慢了几十倍。

优化方法有几个。

第一，在程序设计中使用SysTick中断来实现延时和定时任务，避免大量空循环。SysTick是Cortex-M内核自带的定时器，用中断方式实现多任务时间片调度，效率比主循环里不断查询高得多。

第二，在Proteus仿真设置中，把仿真速度从“实时”改为“最大速度”。在菜单“Debug -> Enable Remote Debug Monitor”下方的“Run Simulation”设置里，选择“Max Speed”，这样Proteus会尽量快地跑完仿真而不是受到实时时间限制。

第三，合理使用条件编译，在仿真版本代码中减少冗余外设操作。比如LCD显示刷新不需要每帧都更新时，降低刷新率会明显提升仿真性能。

如果还需要进一步提速，可以考虑使用Proteus的“32-bit”模式。点击菜单“System -> Simulation Options”，把“Simulation”下拉选为“32-bit”，部分版本切换到这个模式后，STM32的仿真速度会有明显提升。不过要注意，这个选项在某些版本中不可用，取决于安装的是多少位的Proteus。

5.4 加热逻辑不响应或控制反转

仿真电路搭好后，最常见的问题是继电器不动作，或者动作状态相反。先用虚拟万用表量STM32控制引脚的电平变化，再反过来检查继电器的驱动电流方向。

如果程序里设定为输出低电平时继电器吸合，但实际行为是高电平吸合，需要先检查ULN2003的驱动极性。ULN2003是反相驱动器，输入高电平输出低电平，输入低电平输出高电平。所以经过ULN2003后继电器的控制逻辑是反相的。要么程序里做取反操作，要么把继电器接到ULN2003的输出和电源之间而不是输出和地之间。

控制逻辑不响应的另一个可能是GPIO端口时钟未使能。STM32的所有GPIO外设使用前，必须先在RCC寄存器中使能对应端口的时钟。漏掉这一步，代码里写GPIO操作寄存器不会报错，但实际引脚电平完全不会变化。在HAL库中表现为：

__HAL_RCC_GPIOC_CLK_ENABLE();

每次新建工程我都推荐按这一个清单顺序检查：是否使能GPIO时钟、是否配置GPIO模式、是否设置了正确的电平逻辑。这三步都对了，控制逻辑基本不会出问题。

6. 从仿真到实物移植的关键差异

6.1 引脚分配与硬件差异

仿真通过之后做实物时，有几个差异必须提前了解。Proteus里STM32的引脚排列和实际芯片封装有区别，仿真中使用的引脚号不是物理引脚序号，而是GPIO端口号。比如PA0在Proteus模型中的引脚编号可能和LQFP48封装的第11脚不同，但GPIO对应关系完全一致。

做实物时，下载程序需要ST-Link或J-Link调试器。如果手头有STM32最小系统板，上面通常自带ST-Link接口，用四根线（SWDIO、SWCLK、GND、3.3V）就能完成下载和调试。如果没有调试器，串口ISP也能下载，但STM32F103系列需要先把BOOT0引脚拉高复位进入系统存储器引导模式，下载完再把BOOT0拉低复位运行用户程序。

6.2 电源设计与安全考量

实物和仿真最大的区别在于电源和安全。仿真里可以随时随地给电路供电、改电压、断连接，但实物中电源设计一旦出错，轻则芯片烧毁，重则引发安全问题。

热水器是强电设备，做实物控制系统时，控制板与加热器之间必须有隔离。最常见的设计方案是用继电器隔离控制和强电回路，控制侧和加热侧不共地。或者用光耦加双向可控硅来实现无触点通断，这样控制板与强电完全隔离，安全性更高。我强烈建议在实物阶段不要直接用手触碰高压电路，测试时使用隔离变压器或低压加热模型来验证控制逻辑即可。

温度传感器的封装选择也有讲究。防水型DS18B20用不锈钢管封装，可以直接投入水中测温；普通TO-92封装只能测空气温度，不能防水。热水器系统中温度传感器必须接触水体，所以选型时务必选防水型探头。

6.3 系统扩展方向建议

如果学有余力，这个系统还有几个很好的扩展方向。

增加WiFi或蓝牙模块，实现手机App远程控制热水器。STM32F103C8T6的资源可以承受通过串口连接ESP8266模块，在ESP8266上跑AT指令和MQTT协议，将温度和状态上报到云平台或手机App。

增加水位检测和自动进水功能。用液位传感器检测水箱水位，低水位时自动打开电磁阀进水，防止干烧。这是实物热水器很实用的功能扩展。

用OLED屏替代LCD1602。OLED显示更清晰，还能显示简单图形，配合中文字库能做出更友好的交互界面。缺点是I2C接口对时序要求更高，且有些OLED模块用模拟I2C时容易出现通信失败。

这三个方向每一种都能做成一篇独立的项目文章。如果时间充裕，建议至少选一个方向做扩展，不管在毕设还是找工作时都是加分项。

我自己做这类项目时有个习惯：每个功能模块单独验证通过后，再逐步集成。先调LCD显示，把“Hello World”显示出来；再调DS18B20温度读取，在LCD上显示实时温度；然后加按键，能调节设定值；最后才写加热控制逻辑。每一步都是站在上一步验证通过的基础上，这样出问题最多只会在当前这一步找原因，不会出现全系统都有问题时不知道从哪里下手的窘境。

仿真环境里可能还有一个小坑——Proteus在运行过程中如果修改原理图或代码，仿真会自动停止。每次修改后重新运行，都需要检查HEX文件是否已更新。Keil默认会增量编译，但如果代码没改，HEX文件时间戳不会更新，Proteus加载的是旧文件，表现就是功能没变化。排查这种问题时，直接重新编译强制生成HEX，或者检查文件生成时间。

最后再分享一个调试习惯：在代码的关键路径上加调试标志位。比如加热器启动和停止时，分别置位一个变量。在Keil调试器中观察这个变量的变化，就能立刻知道控制逻辑有没有走到那一步。仿真调试的“眼睛”就是这些变量，多设几个标志位，比在界面里反复看现象高效得多。