简介面向中微 BAT32G135 32 位单片机的演示代码库以 zip 压缩包形式发布版本为 V1.0.0主要供嵌入式开发者、电子工程师以及单片机初学者在项目开发和学习中参考。包内提供可直接编译的例程与底层驱动覆盖 GPIO、定时器、串口、ADC、PWM、中断等常见外设用法便于快速了解中微 BAT32G135 的初始化配置和基本工作流程。压缩包共包含 780 个文件以 C 源文件293 个、头文件180 个和汇编文件47 个为主配有 40 个 Keil 工程文件uvprojx/uvoptx以及 readme、txt 等说明文档工程结构清晰可帮助使用者按模块快速定位代码整体大小约 2.16MB。目前已有 869 人学习浏览适合需要评估或入门 BAT32G135 的开发者直接下载参考。通过研读其中的示例和中断服务、低功耗及调试相关代码开发者可以缩短前期驱动调试时间并在此基础上扩展自己的应用逻辑。1. 一个例程压缩包为什么能决定你三天的工作量拿到BAT32G135_DemoCode_V1.0.0.zip这类压缩包大多数人的第一反应是解压、打开工程、点编译。但实际上BAT32G135 作为国产 Cortex-M0 超低功耗 MCU它和 STM32 最大的不同在于外设寄存器布局、低功耗模式命名、时钟树设计都遵循厂商自己的约定手册虽然有但对着手册从零建立工程少说也要折腾三天。DemoCode 的价值不是给你现成的灯而是把「芯片上电后时钟从哪里来、中断表怎么排、低功耗模式怎么进怎么出」这些最容易被手册藏起来的信息用工程文件直接摊在你面前。这篇内容围绕的就是这套 DemoCode 的读法和改法先讲解压后怎么快速定位最小工程再讲从里面抽取时钟、串口、低功耗三个最常用模板最后落到我自己在实际项目里踩过的三个坑。适合刚接手 BAT32G135 的嵌入式工程师也适合从别的 M0 平台转过来、想用最短时间评估这颗料的人。2. 解压后先做三件事确认目录、配器件型号、跑通编译2.1 先看目录结构别急着双击工程绝大多数厂商 DemoCode 的目录组织是有默契的BAT32G135 这套也不例外。解压之后第一件事不是开工程而是先花两分钟把目录认一遍。常见的结构大致是下面这样BAT32G135_DemoCode_V1.0.0/ ├── Docs/ # 数据手册摘要、勘误、例程说明 ├── Libraries/ │ ├── BAT32G135_CoreLib/ # 内核相关CMSIS、启动文件、系统时钟 │ ├── BAT32G135_PeripheralLib/ # 外设驱动库GPIO/USART/ADC/定时器等 │ └── BAT32G135_LowPowerLib/ # 低功耗相关封装 └── Projects/ ├── Keil5_Project/ # UV5 工程目录按外设分子文件夹 ├── IAR_Project/ └── GCC_Project/这里有个容易被忽略的点Keil5_Project 下往往不是只有一个工程而是按外设分成了几十个小工程每个对应一个独立例程。比如GPIO_LED、USART_Printf、ADC_Temperature、Timer_PWM、PowerDown_Wakeup这些目录。你需要找的「最小可运行工程」通常是带有SystemClock、GPIO或Startup字样的那一个。如果整个解压后找不到工程文件先看看 Docs 目录里有没有版本说明。厂商偶尔会把裸机寄存器版和标准库版放在不同压缩包里或者把 Keil 工程放到/Projects/Keil5_Project更深的层级里。用系统搜索搜*.uvprojx是最快的办法。2.2 用 Keil 打开工程并锁定 BAT32G135 器件型号打开工程文件后第一件事是检查 Device 选择是否正确。BAT32G135 系列内部有不同 Flash/RAM 容量的型号如 BAT32G135Gxxx 之类如果 DemoCode 里默认选的型号和你手头的物料不一致编译能过但下载后跑起来可能异常。在 Keil 中操作为Project→Manage→Device搜索BAT32G135选中你实际使用的型号。这一步会同步切换对应的 SVD 文件和启动文件。接下来检查下载器配置。在Options for Target→Debug里确认调试器是 J-Link 还是 DAP然后在Settings里把 Flash 下载算法选对。如果下载时报No Algorithm found多半是 Flash 算法和器件型号不匹配重新选择电池厂商提供的 FLM 文件即可。还有一处经常被忽略的是 C/C 选项卡里的宏定义。打开工程后在Target里会看到一个类似USE_STDPERIPH_DRIVER, BAT32G135的宏列表。前一个宏决定是否包含库函数封装后一个宏决定使用哪个器件型号的条件编译分支。两个都不要随意删除否则编译时会报出大量undefined identifier错误。2.3 第一次编译要检查的三件事工程能编译通过不等于能跑起来。第一次编译后我会依次确认三件事。第一是编译输出里的 ROM 和 RAM 占用是否合理如果默认例程 Flash 占用超过 80%说明工程里可能有未裁剪的调试信息这种情况下要先优化再继续。第二是链接器 warning 里有没有提示L6286E类型的分散加载问题BAT32G135 的 RAM 不大默认栈和堆如果占太多后面加功能时容易内存不足。第三是确认启动文件startup_bat32g135.s的 Reset_Handler 里是否调用了SystemInit和__main。提示如果你的 Keil 版本低于 5.30建议先升级否则工程里的某些__attribute__((section(...)))写法会被当成警告或错误处理干扰你对真正问题的判断。BAT32G135_DemoCode里值得留意的参数我一般会在工程建立后随手记成一张表方便后续做功耗和外设配置时查参数项默认值修改位置影响系统主频内部 RC / 外部晶振可选SystemClock例程串口波特率、定时器周期全部受影响Flash 下载算法按型号自动选择Options → Debug → Flash选错下载后芯片无响应Stack/Heap 大小通常 0x400/0x200启动文件任务层级多时容易溢出外设时钟开关例程一般默认全开库初始化函数全开时低功耗电流可能高几十倍跑通第一块板子的标志不是灯亮而是Debug模式下暂停后定位到main()且不死在HardFault_Handler。3. 从 DemoCode 里剥出三个可复用模板时钟、串口、低功耗3.1 时钟初始化识别 HSI、HSE 与系统主频的配置链路BAT32G135 的时钟树并不复杂但顺序比 STM32 更敏感。绝大多数例程在SystemInit()阶段只会把时钟切换到内部高速 RCHSI真正把主频拉起来是在System_Clock_Init()这类应用层函数里完成的。从 DemoCode 里抽取时钟初始化代码时先认准几个关键对象。外部高速晶振是 BAT32G135 在需要高精度串口波特率时才会用到的如果板子没贴晶振直接走 HSI 分支即可。其次HSI 本身存在出厂校准值但不是自动生效的需要手动从 Flash 的某段信息区读出校准值写入 RC 校准寄存器。很多新手抄例程时漏掉这一步结果就是串口波特率整体偏移。下面是我通常会在工程里写的最小时钟配置结构上参考了 DemoCode 的分步逻辑但把判断条件写得更明确void Clock_SystemInit(void) { /* 1. 先把系统时钟切回 HSI确保后面切换外部晶振失败时仍有可用时钟 */ Clock_SetSysClockSource(CLOCK_SRC_HSI); /* 2. 尝试启动外部高速晶振启动超时则回退到 HSI */ if (Clock_HSE_Start() STATUS_OK) { /* 外部晶振起振成功作为 PLL 输入目标主频拉到 64MHz */ Clock_SetPLLSource(CLOCK_PLLSRC_HSE); Clock_SetPLLDiv(CLOCK_PLL_DIV_4); Clock_SetSysClockSource(CLOCK_SRC_PLL); Clock_SetSysClockFreq(CLOCK_SYSCLK_64M); } else { /* 无外部晶振读出厂校准值到 HSI主频定为 48MHz */ uint32_t hsi_cal Clock_ReadHSICalValue(); /* 从信息区读出 */ Clock_HSI_SetCalibrationValue(hsi_cal); Clock_SetSysClockSource(CLOCK_SRC_HSI); Clock_SetSysClockFreq(CLOCK_SYSCLK_48M); } /* 3. 更新全局时钟频率变量串口波特率、定时器计数周期都靠它 */ SystemCoreClock_Update(); }这段代码的核心逻辑是「先保底、再提速」。第一步切到 HSI 是为了防止 HSE 起振失败时系统进入无时钟状态第二步的Clock_ReadHSICalValue是必须的BAT32G135 的 HSI 精度依赖这一字节的校准值漏掉后 115200 波特率的误差会从 0.2% 恶化到 2% 以上第三步更新SystemCoreClock否则后面调用USART_BaudRate_Set时计算出的分频系数是错的。提示CLOCK_SYSCLK_64M这个枚举名是库函数内部的惯用写法不同版本的 DemoCode 可能叫CLOCK_FREQ_64MHZ关键是找到系统时钟频率设置函数和它对应的枚举值以你手头工程头文件里定义的符号为准。3.2 串口作为调试后门的三个参数波特率、时钟源、重定向BAT32G135 的串口调试几乎是每个项目的刚需但很多人把 DemoCode 里的串口例程搬过来后发现printf不工作或输出乱码。问题基本都出在三个参数上波特率计算使用的时钟源、重定向输出函数、以及串口引脚复用。先确认串口挂在哪个时钟源上。如果系统主频从 64MHz 切成 48MHz而串口初始化代码里的分频计算还是按 64MHz 展开波特率就偏了。这类问题在 DemoCode 的例程里不会出现因为例程不会中途改主频但在你自己的工程里极易发生。重定向这一步需要你自己在工程里加一个fputc函数。DemoCode 的串口例程往往只提供底层发送函数而没有把printf完全接好。常见做法是补一段标准输出重定向/* 串口底层发送单字节阻塞直到发送完毕 */ void USART_SendByte(USART_TypeDef *USARTx, uint8_t data) { USARTx-DATA data; while ((USARTx-STAT USART_STAT_TXFLG) 0); /* 等待移位寄存器空闲 */ } /* printf 重定向到串口1 */ int fputc(int ch, FILE *f) { USART_SendByte(USART1, (uint8_t)ch); return ch; }while循环里的状态标志位是发送缓冲区空标志不同 SDK 版本里有叫TXFLG也有叫TXDONE的作用相同。这段代码有个隐含问题阻塞发送会卡住 CPU如果串口打印量大且系统有实时性要求需要改成中断或 DMA 发送而不是逐字节等待。作为调试输出阻塞方式完全够用。引脚复用参数方面确认 DemoCode 的Board_Init里把TXD/RXD对应的 GPIO 模式复用推挽/开漏和复用功能号选对即可。3.3 低功耗例程的三个必调参数功耗档位、唤醒源、唤醒后处理BAT32G135 做低功耗设计时低功耗例程是整个 DemoCode 里含金量最高的部分。它向你展示了进入深度睡眠之前要关哪些外设、保留哪些引脚状态、唤醒后时钟是否需要重新初始化。把例程抄到自己工程时三类参数必须改明白。第一类参数是功耗档位。BAT32G135 在库封装里通常暴露了 Sleep、DeepSleep(PD)、PowerDown 等模式它们之间的差别是时钟是否停止、RAM 是否保电以及唤醒延迟。DemoCode 里的示例默认用中断唤醒的方式进入 PowerDown这是功耗最低、但唤醒时间最长的模式。进入低功耗之前的准备动作可以从例程里抽成如下模式void App_EnterPowerDown(void) { /* 1. 关停未使用外设时钟必要外设保留 */ RCC_PeriphClockCmd(RCC_PERIPH_USART1 | RCC_PERIPH_ADC1, DISABLE); /* 2. 配置唤醒源PA0 下降沿触发 */ GPIO_SetPinMode(GPIOA, GPIO_PIN_0, GPIO_MODE_INPUT_PULLUP); EXTI_SetTrigger(EXTI_PORT_A, EXTI_PIN_0, EXTI_TRIGGER_FALLING); NVIC_EnableIRQ(EXTI0_IRQn); /* 3. 进入低功耗前关闭 SysTick防止中断频繁唤醒 */ SysTick-CTRL ~SysTick_CTRL_ENABLE_Msk; /* 4. 进入 PowerDown 模式 */ SYS_EnterPowerDownMode(); }第二类参数是唤醒源。例程里常用外部 GPIO 中断和 RTC 定时唤醒两种。外部中断唤醒要注意引脚内部上拉的配置下拉电阻漏电在低温下会放大导致你的静态电流多出几十微安RTC 唤醒则要确认 RTC 的时钟源用的是外部 32.768kHz 还是内部低频 RC前者的时间精度高但多一颗晶振的静态功耗。第三类参数是唤醒后的处理。BAT32G135 从 PowerDown 唤醒后系统时钟默认回到复位状态不会自动恢复到 64MHz。如果直接继续执行主循环外设像是时钟分频未更新串口波特率就会错乱。所以在唤醒中断或主循环的开头需要重新调用时钟初始化并且把上文提到的SystemCoreClock_Update()一并执行。DemoCode 的例程里会带着这一段但很多工程师抄的时候以为中断唤醒只是__WFI那么简单结果就是唤醒后功能不正常。4. 抄完例程后最容易踩的三个 BAT32G135 专属陷阱4.1 外设库版本与启动文件不匹配先对宏再动手在把 DemoCode 往外设驱动移植时最容易遇到的是库函数版本不一致。解压BAT32G135_DemoCode_V1.0.0.zip后需要先检查 Libraries 目录里是否同时包含了旧版和新版的外设库有些压缩包会保留两个分支侧重点不同。启动文件里SystemInit的调用行为如果与外设库的实现不同步SystemCoreClock变量就可能在启动时没有被正确赋值结果是定时器周期全面偏差。在开发自己的项目之前建议把 DemoCode 里的 Libraries 整体拷贝到新工程。不要单独挑几个.c文件出来组合使用除非你确实知道底层 API 的变化点。这个拷贝动作虽然笨重但能最大程度避坑。4.2 低功耗电流验的是边界不是典型值用 DemoCode 的低功耗例程测电流时要注意你的测量方式。万用表的电流挡在微安级别下响应很慢测到的往往是平均电流而不是休眠时的基座电流。正确做法是用一个 10Ω 采样电阻串联在供电回路中用示波器测电阻两端电压来观察电流波形。这样能同时看到两个值休眠时的稳定电流水平和唤醒瞬间的电流尖峰宽度。提示如果测量结果比数据手册典型值高出一倍最先排查的不是模式配置而是板载调试器的供电回路。很多评估板上调试器芯片本身就消耗额外电流必须用跳线断开调试器后再测。4.3 保留 RTC 与掉电检测参数避免唤醒后状态初始化这里有一个常常被忽略但非常重要的技巧DemoCode 中的低功耗例程默认会把所有外设都放进复位状态再进入休眠。如果项目中需要用到 RTC 计时这会导致唤醒后 RTC 寄存器被复位时间变成初始值。正确的方式是在进入 PowerDown 前把 RTC 的配置重载一遍并且只关掉非必要外设时钟保持 RTC 外设的电源域供电。同理电压检测模块的阈值参数也应当在休眠前重新写入防止唤醒瞬间电压跌落产生误触发。本文还有配套的精品资源点击获取