简介：本资源是面向嵌入式初学者与华大半导体HC32L136开发者的全套实战例程包，聚焦低功耗MCU核心外设驱动与系统级应用开发，解决学习过程中缺乏完整工程参考、调试环境配置困难及典型功能实现无从下手等痛点。压缩包共2000个文件，总计3.99MB，涵盖266个头文件（h）、230个汇编启动文件（s）、148个C源码（c）及大量IDE工程配置文件（如uvprojx、ewp、icf、board等），全面支持Keil、IAR等主流开发环境；其中board文件达116个，体现多硬件平台适配能力，flash与DMA相关代码亦高度结构化，便于理解存储管理与高效数据传输机制。已有2508人下载学习，资源内容紧扣定时器配置、SPI通信、LCD驱动（ST7565/SSD1306）、Flash在线编程及DMA外设联动等六大核心模块，所有例程均基于真实硬件验证，可直接编译运行，显著降低入门门槛并加速项目原型开发。 做低功耗 MCU 选型的时候，华大 HC32L136 这颗料的出镜率一直不低。水表、燃气表、传感器采集、手持设备，凡是讲究电池寿命又要带段码屏的项目，基本都会拿它来对比一下。好芯片也得有好工具链，华大这套 HC32L136 全套例程，就是那种能直接落到工程里的开发素材，不是零散几个 demo 凑数，而是把 GPIO、UART、DMA、ADC、定时器、RTC、低功耗、LCD 这些常用外设都覆盖到了，项目里要什么基本都能翻到对应参考。
这篇文章不打算做教程复读机，我按自己实际调试时的思路，把这套例程的构成逻辑、环境搭建、几个典型外设的代码套路，以及移植到自己项目里容易踩的坑，从头到尾捋一遍。无论你是第一次接触华大这颗低功耗芯片，还是已经在用但被某个外设卡住，按这个顺序走下来，都能少走不少弯路。
1. 这套例程到底值得看在哪：芯片定位与资源包逻辑
1.1 HC32L136 这颗料是什么定位
HC32L136 是华大小华半导体旗下的一款超低功耗 MCU，内核是 Cortex-M0+，主频最高能跑到 48MHz，Flash 做到 64KB，SRAM 有 8KB。单看性能指标不算激进，但这颗料的强项在低功耗和模拟外设这两块：有多达 4 种低功耗模式，DeepSleep 模式下电流可以做到微安级别，内部还集成了 LCD 驱动、12 位 ADC、DAC、运放、比较器、RTC 这些模块。
用一句话概括它的典型画像：一颗电池供电、带段码液晶屏、需要长时间待机、偶尔醒来采样发送数据的 MCU。所以你去看官方例程包的构成，会发现低功耗和 LCD 相关的例程数量占比非常高，这跟芯片本身的定位是完全匹配的。选型阶段拿它跟 STM32L0 系列、新唐 M0 系列对比的时候，HC32L136 在 LCD 驱动集成度和外设性价比上往往能占到优势。
1.2 全套例程包的结构逻辑
华大这套例程的组织方式，跟 ST 的标准外设库思路接近，底层是一套 DDL 驱动库，上层按外设模块拆成一个个独立工程。打开压缩包后，里面有 ddl 驱动源码、project 例程工程、doc 文档说明这几个核心目录。ddl 目录里是各外设的驱动源码和头文件，相当于一个“外设操作函数库”；project 目录下每个子文件夹对应一个外设例程，比如 gpio、uart、dma_uart、adc、timer、rtc、lcd、lowpower 等。
这种结构的好处是：你想用哪个外设，直接打开对应工程研究它的初始化流程就行，不用整个工程从头读。比如我第一次调 DMA 串口，不用去翻几百页的参考手册，直接在 dma_uart 例程里看它怎么配置 DMA 通道、怎么跟 UART 触发绑定，把核心代码搬到自己的工程里改改引脚就能跑通。对刚接触这颗芯片的人来说，这种方式比啃寄存器手册友好太多了。
1.3 例程包对开发效率的真实影响
很多人觉得例程不就是官方给的“标准答案”嘛，照着抄就行。但实际做项目时你会发现，例程的价值更多在于帮你理解这家芯片厂商的“习惯写法”。华大的 DDL 库函数命名风格、初始化结构体、状态标志位的操作方式，跟 STM32 的 HAL 库有明显差异，如果没人指点，光看手册容易在 API 的调用顺序上卡住。有了全套例程，等于有人把每个外设从“上电”到“正常干活”的最小代码路径都给你走了一遍。
我自己的体会是，拿到一块新 MCU，先不急着看手册，把官方例程包里的工程挨个编译、下载、跑一遍，比看三遍数据手册都管用。跑例程的过程能让你快速建立对外设寄存器、时钟树、中断系统的整体感知，后面再深入看手册时，很多原本抽象的描述都能跟实际现象对上号。
2. 上手之前先搞定这几件事：环境、工程结构、时钟树
2.1 Keil 和 IAR 的环境准备
HC32L136 的例程工程主要支持 Keil MDK 和 IAR 两个工具链。我平时用 Keil 比较多，这里以 MDK 为例说一下环境准备的关键点。首先 MDK 版本建议用 5.20 以上，太老的版本对 DDL 库里的部分 C99 语法支持不好，编译时会报一些莫名其妙的错误。其次需要安装华大 HC32L13x 系列的器件支持包，也就是 DFP（Device Family Pack），装好之后在 Keil 的器件列表里才能找到 HC32L136 对应的型号。
这个 DFP 安装包通常在华大官网的 HC32L136 资料下载页能找到，也可能直接打包在 SDK 里。装的时候注意版本号和芯片型号要匹配，装错型号可能导致工程打开后器件不识别。另外，调试器部分推荐使用华大的 HC-LINK 或者 J-Link，如果用 J-Link，需要在 Keil 的 Debug 设置里把 Flash Download 算法选对，否则下载时会提示找不到算法，这属于新手最容易卡壳的地方之一。
2.2 工程目录与启动文件解读
打开一个 HC32L136 例程工程后，你会发现它跟 STM32 的工程结构很像：有启动文件、系统初始化文件、外设驱动库、用户 main 文件这几层。启动文件里定义了中断向量表、堆栈大小，系统初始化部分负责把内部高速 RC 振荡器配置到合适的系统时钟。用户代码部分，例程通常都会在 main 函数开头调用一个系统时钟配置函数，然后才是外设初始化和主循环逻辑。
这里有个跟 STM32 很不一样的习惯：华大的例程喜欢用 DDL_ZERO_STRUCT 这个宏来清零配置结构体。很多外设的初始化参数都是一个结构体，如果某个成员没被赋值，最好用这个宏先整体清零，再按需配置，否则残留的随机值可能导致外设行为不可控。这个细节在移植例程到自己项目时同样适用。
2.3 系统时钟与外设时钟的关系
HC32L136 的时钟树需要重点理解一下。芯片内部有高速 RC 振荡器（HRC）和外部晶振输入接口，系统时钟可以从内部 HRC 分频得到，也可以使用外部晶振。内部 HRC 的频率档位比较多，例程里通常默认配置为 8MHz 或者 22.12MHz 等固定档位，分频后作为系统时钟。外设总线时钟 PCLK0、PCLK1 等由系统时钟分频而来，不同外设挂在不同的总线时钟下。
这就带来一个实战中的坑：初始化外设时钟的时候，必须搞清楚这个外设挂在哪个 PCLK 上，因为 UART 的波特率、定时器的计数频率、ADC 的采样时钟，都是从对应的 PCLK 分频得来的。如果 PCLK 配置不对，波特率算出来就是错的，串口收到的全是乱码。华大例程里通常会在 system_hc32l136.c 里给出完整的时钟配置，我建议你先不要乱改这个文件，保持例程默认的时钟配置，等外设都跑通了，再根据功耗需求去调整频率档位。
3. 四个最常用例程的拆解与实战
3.1 GPIO：从点灯开始建立开发手感
GPIO 是最基础的外设，也是我拿到任何一块新板子第一个要跑通的例程。HC32L136 的 DDL 库中，GPIO 操作逻辑是：先调用 Gpio_SetFunc 设置引脚功能（普通 GPIO 还是复用为 UART/SPI 等），再调用 Gpio_SetDir 配置输入输出方向，最后用 Gpio_SetIO 或 Gpio_ClearIO 拉高拉低电平。
stc_gpio_cfg_t stcGpioCfg; DDL_ZERO_STRUCT(stcGpioCfg); // 将 PB0 配置为普通 GPIO 输出 Gpio_SetFunc(GpioPortB, GpioPin0, GpioFunc1); stcGpioCfg.enDir = GpioDirOut; stcGpioCfg.enOD = GpioOdDisable; stcGpioCfg.enPu = GpioPuDisable; stcGpioCfg.enPd = GpioPdDisable; Gpio_Init(GpioPortB, GpioPin0, &stcGpioCfg); // 点亮 LED，PB0 拉低 Gpio_ClearIO(GpioPortB, GpioPin0);这里要提醒一下：HC32L136 的引脚复用关系跟 STM32 类似，一个引脚可能有好几个复用功能，Gpio_SetFunc 的第二个参数到底填 GpioFunc1 还是 GpioFunc2，需要查数据手册的引脚复用表，不能靠猜。GPIO 例程里通常用的是 GpioFunc1，这个值对应的是引脚最基础的 GPIO 功能。
另外一个容易忽略的点是引脚上下拉配置。很多低功耗项目里，按键引脚需要启用内部上拉，传感器中断引脚可能需要配置成输入且带上拉。如果例程里引脚的上下拉是关闭的，而你在实际电路中有外部上拉电阻，那没问题；但如果你的板子没外加电阻，就一定要在 Gpio_Init 的配置结构体里把 enPu 打开，否则按键按下和松开的状态可能读不对。
3.2 UART：串口调试的标配姿势
UART 例程的价值在于它不只是演示收发，更重要的是给你一套“能用 printf 打印调试信息”的标准姿势。嵌入式开发没有串口打印，调试效率至少要掉一半。HC32L136 的 UART 初始化有点繁琐，涉及时钟选择、波特率配置、数据位校验位停止位配置、中断使能等多个步骤。
stc_uart_cfg_t stcUartCfg; DDL_ZERO_STRUCT(stcUartCfg); // 配置 UART2 时钟源、波特率等关键参数 stcUartCfg.enClk = UartClkPclk0; stcUartCfg.enIRQ = UartIrqEnRx; stcUartCfg.stcBaud.u32Baud = 115200UL; Uart_Init(M0_UART2, &stcUartCfg, &stcUartM0Pclk0Cfg);这里要注意 Uart_Init 的第三个参数，它是一个跟时钟频率相关的配置结构体，里面存的是 PCLK0 的频率。如果 PCLK0 的实际频率跟这里填的不一致，波特率就会出现偏差，串口通信在 115200 这种高速率下会明显出错，如果是 9600 这种低速率可能还不容易发现。所以改 UART 之前，一定要确认这个结构体里的数值跟实际时钟配置完全一致。
printf 重定向部分，例程一般会重写 fputc 函数，把它转成 UART 发送一个字节。这样你就可以直接用 printf 打印调试信息了。但用这个功能的时候要注意：不要在中断服务函数里调用 printf，因为 printf 内部会等待串口发送完成，这个等待过程在中断上下文中可能引出死锁，特别是波特率很低的时候，打印一条信息要占很长时间，容易把其他中断卡住。
3.3 DMA 串口：不定长收发的正确处理思路
DMA 串口是 HC32L136 例程包里的一个亮点，也是我实际项目里用得最多的外设组合。为什么需要 DMA 串口？因为如果用普通中断接收，每来一个字节就进一次中断，CPU 频繁被打扰，在低功耗 MCU 上这种模式既不高效也容易丢数据。DMA 可以帮你把串口收到的一整串数据直接搬到内存缓冲区，CPU 可以在缓冲区积累了一定数据后才去处理。
HC32L136 的 DMA 支持外设到内存的搬运，UART 的接收数据寄存器可以触发 DMA 请求。例程里的典型做法是：把 DMA 配置成循环模式，数据会不停搬到接收缓冲区；同时配合一个定时器或者串口超时机制，当判断一帧数据接收完成后，再对缓冲区里的数据做解析。
// 以下为核心配置思路，具体寄存器参数以例程为准 DMA_SetChannelTransferCnt(DMA_CH0, BUFFER_SIZE); DMA_SetTransferAddr(DMA_CH0, (uint32_t)&M0_UART2->RDR, DMA_ADDR_INC_NONE, (uint32_t)uartRxBuffer, DMA_ADDR_INC_16BIT); DMA_EnableChannel(DMA_CH0);这里有一个很关键的问题：怎么判断一帧数据收完了？HC32L136 本身有串口空闲中断功能，如果例程包支持，优先用它来判断帧结束，这是最干净的方案。如果芯片不支持空闲中断，退而求其次的做法是配合一个定时器，收到首个字节后启动超时计时，超过设定时间没有新数据进来，就认为一帧结束。这个超时时间的设定需要根据你的业务帧长和波特率来算，比如 9600 波特率下，1 个字节大约 1ms，如果最长帧是 20 字节，超时时间设置在 3-5ms 会比较合适。
DMA 串口例程的另一个价值在于，它给你展示了一个低功耗场景下的数据接收样板：CPU 大部分时间可以睡大觉，DMA 默默把数据收进缓冲区，等一帧数据完整到达后再唤醒 CPU 处理。这种设计思路在电池供电的采集终端里非常实用。
3.4 ADC：传感器采集场景的常用组合
ADC 是传感器类项目的核心外设。HC32L136 内部集成了 12 位逐次逼近型 ADC，支持多通道采样，也支持单次转换和连续转换模式。例程里通常会有 ADC 单通道采样和 DMA 配合连续采样的两种写法。我自己比较喜欢用“ADC 单次转换 + 定时器周期触发”的组合，这样采样节奏可控，也不会一直占着 CPU。
stc_adc_cfg_t stcAdcCfg; DDL_ZERO_STRUCT(stcAdcCfg); ADC_Init(M0_ADC, &stcAdcCfg); ADC_EnableChannel(M0_ADC, AdcM0Channel5); ADC_Start(M0_ADC); while(ADC_GetIrqFlag(M0_ADC, AdcM0IrqFlagEoc) == RESET); u16Value = ADC_GetResult(M0_ADC);用 ADC 之前有几个细节必须确认：采样通道对应的引脚是哪个，引脚复用有没有配置对；内部参考电压选的是 1.5V 还是 2.5V 还是外部参考，这直接决定 ADC 满量程对应的电压值；采样时间设置够不够长，如果信号源内阻很大，采样时间太短会导致采样结果不准确。
ADC 例程还有一个容易踩坑的地方：不同通道的转换结果排序。如果同时开启多个通道，读取结果时要搞清楚结果寄存器里的数据对应的是哪一路通道。例程里一般会给出通道与结果寄存器的对应关系，我建议刚开始用的时候只开一个通道，跑通了再增加通道，避免结果交错的问题。
4. 把例程改到自己项目里：移植的思路与取舍
4.1 模块裁剪与资源评估
全套例程是“全都要”的思路，但实际项目讲究的是“够用就好”。一个 HC32L136 芯片 Flash 只有 64KB，如果把例程库里所有外设都搬进去，很快资源就不够了。我拿到例程后，第一步一定是评估自己项目真正需要哪些外设，然后用例程作为参考，从零开始建立自己的最小工程，而不是在例程的基础上删代码。
为什么我强烈建议从零搭建？因为删除代码永远比添加代码更容易出错。例程里可能有一些你根本用不到的全局变量、中断处理函数和初始化调用，删不干净的时候编译器也能过，但程序行为会变得不可预测。从零建工程的好处是，所有代码都是你亲手加的，每个外设的初始化你都知道它怎么来的，出了问题排查起来思路会很清晰。
具体操作上，我会把例程里的 ddl 库源码完整复制到自己的工程里，然后在 main 函数里只调用需要的初始化函数。编译器在链接时会自动丢弃没被引用的函数，所以 ddl 库全部放进来不会导致 Flash 占用变多。真正需要留意的是启动文件和系统初始化文件，这两个文件不能乱删，别的地方出问题好排查，这里出问题往往连启动都启动不了。
4.2 低功耗例程里最值得借鉴的设计
HC32L136 的低功耗例程，我觉得是整套例程包里含金量最高的部分，因为它不只是告诉你“调用某个函数进入睡眠”，而是给出了一个完整的低功耗应用框架：进入低功耗前关闭不用的外设时钟、配置唤醒源、设置唤醒后的时钟恢复流程。
这里有一个我踩过的坑：唤醒后时钟没有恢复，导致 UART 波特率全部错乱。HC32L136 从低功耗模式唤醒后，有些外设时钟需要重新使能，外设寄存器也需要重新初始化。如果唤醒后直接使用 UART，收到的数据大概率是乱码。低功耗例程里的处理方式是：唤醒后先调用系统时钟恢复函数，再根据唤醒标志位判断是否需要重新初始化外设。
这个思路在项目里非常重要。如果你的设备是电池供电，大部分时间在休眠，偶尔被定时器唤醒去采集数据、发数据，那么“唤醒后重新初始化外设”这个动作必须做成一个固定流程。否则就会出现“刚上电的时候一切正常，跑一段时间后串口乱码”这种让人抓狂的问题。
4.3 从例程到产品的测试顺序
我自己在项目中遵循一个固定的测试顺序：先点亮 LED 确认最小系统能跑，再用 UART 打印确认调试通道通畅，然后逐个添加传感器、无线模块等外设，每加一个外设就验证一次，绝不一次性把所有外设都加上再联调。这种做法的好处是，一旦出问题，你只需要怀疑刚加上的那个外设，排查范围小很多。
有一段时间我把这个顺序忽略了，直接把 ADC、LCD、UART、无线模块一次性全部初始化，结果上电后发现 LCD 显示乱跳，我排查了半天，最后发现是 ADC 的引脚和 LCD 的某个段复用冲突了。如果当时按顺序来，先不初始化 LCD，这个问题在上一步就能暴露出来。例程包里的每个外设例程就是一个独立的验证单元，正好可以配合这个测试顺序使用。
5. 实战中最容易踩的坑：问题排查与调试心得
5.1 环境编译类问题：路径、版本、C99 语法
编译报错是新手最容易卡住的环节，但大部分编译问题其实可以提前避免。第一个是工程路径问题：HC32L136 例程在 Windows 下如果放在中文路径或者带空格的目录里，编译时常常报找不到头文件的错误。这不是代码问题，是 Keil 对中文路径的支持不好。把整个例程目录放在纯英文路径下，问题就解决了。
第二个是 MDK 版本问题：老版本 MDK（比如 5.20 以下）对 C99 语法支持不完整，DDL 库中一些声明在 for 循环内部的变量可能编译不过。建议直接用较新的 MDK 5.3x 以上版本，同时打开 C99 模式，Compile 选项里的“C99 Mode”勾选上。我之前帮一个同事看问题，他用的 MDK 4.74 打开例程，几百个报错，换了 MDK5 后直接零报错，这种事不是个例。
第三个是器件包缺失的问题：工程打开后如果芯片型号显示不出来，或者编译时提示找不到芯片定义的相关文件，大概率是 DFP 没装或者版本不对。去官网下载对应 HC32L13x 系列的 DFP，一键安装后重启 Keil 就能解决。
5.2 下载调试类问题：烧录失败与芯片锁死
下载程序失败是另一个高频问题。第一次烧录时，如果 Keil 提示找不到目标器件或者 Flash Download 失败，先检查调试器驱动是否安装、Debug 设置里选择的调试器型号是否正确、Flash Download 算法有没有添加。J-Link 用户要注意，HC32L136 的下载算法需要选择对的 FLM 文件，选错的话下载时会提示算法无法加载。
还有一个很经典的坑：代码里如果复用了 SWD 调试引脚（比如把 SWDIO 引脚配成了普通 GPIO 输出），第二次烧录时调试器就连接不上芯片了，因为调试口已经被应用程序占用。解决方法是用 HC-LINK 的“连接复位”功能，或者按住板子上的复位键，在点击下载的瞬间松开复位，趁程序还没跑到引脚复用的代码前把新程序烧进去。实在不行，用串口 ISP 下载方式恢复。
芯片“锁死”了这个概念有点吓人，但大多数情况下不是真的损坏，只是 Flash 里的程序把调试口占用了。用上面的方法多试几次，还是能恢复的。我建议在调试阶段，尽量把 SWD 引脚留作调试功能，别过早复用成 GPIO。
5.3 外设初始化与低功耗模式中的隐藏坑
外设初始化顺序也是一个经常出问题的地方。HC32L136 的例程里，各个外设初始化一般都在主函数里先后调用，看起来没什么顺序要求，但实际并非如此。比如，如果你先初始化了 UART，再去修改系统时钟配置，UART 的波特率就等于重新计算了，这时候串口输出的数据就会乱掉。所以系统时钟配置最好在最前面完成，之后所有外设初始化都基于这个时钟配置来。
在低功耗模式下还有一类问题特别隐蔽：进入低功耗前没有关闭 ADC 或者比较器这类模拟外设，导致漏电流偏大，续航达不到预期。如果遇到低功耗电流比手册标称大很多的情况，优先怀疑是不是某个外设没有进入关闭状态。低功耗例程里有完整的“先把外设全关，再进低功耗”的示范流程，这个思路要养成习惯。
5.4 问题速查表
我把平时用得比较多的排查经验整理成一张表，遇到问题可以对着查：
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 编译报几百个错误 | MDK 版本太老 / 没开 C99 | 换 MDK5.3x+，开启 C99 Mode |
| 找不到头文件 | 工程路径含中文或空格 | 把工程移到纯英文路径 |
| 烧录时找不到目标器件 | DFP 未装或版本不对 | 安装匹配 HC32L13x 系列的 DFP |
| 第二次烧录连接不上 | SWD 引脚被复用成 GPIO | 按住复位键点击下载，或使用串口 ISP |
| 串口输出乱码 | PCLK 频率与波特率配置不匹配 | 核对 Uart_Init 中的时钟配置结构体 |
| 低功耗电流偏大 | 模拟外设未关闭 | 进入休眠前关闭 ADC、比较器、LCD 等外设 |
| 唤醒后串口乱码 | 唤醒后时钟未恢复 | 添加时钟恢复和外设重新初始化流程 |
| LCD 显示异常 | ADC 引脚与 LCD 段引脚复用冲突 | 查引脚复用表，调整 ADC 通道或 LCD 段分配 |
这张表里提到的不少问题，都是我在不同项目里真实碰到过的。例程包给你的是“正确路径”，但实际调试时往往是在“错误路径”上花的时间更多。把这些错误路径提前了解清楚，比多写几行代码更有价值。
按这套思路走下来，HC32L136 这套例程基本就能被你吃透了。我个人的习惯是，拿到例程包的第一周，先把每个例程都编译、下载、跑一遍，同时把每个工程的 main 函数拷贝到一个总笔记里，标注上外设初始化的关键顺序和参数。这样后面做新项目的时候，不用再重新翻例程，直接翻我的笔记就够了。这个习惯很值得保留，因为华大后续会出不同系列的新芯片，很多 API 风格和移植技巧都是通用的，积累下来就是自己的技术资产。
本文还有配套的精品资源，点击获取
