2018年年中的时候我参与整理了一期STM32 GUI培训资料核心就是STemWin。当时市面上关于STemWin的中文资料还比较散很多人把emWin和STemWin混着说也没搞明白库的来源、授权和移植要点。这次我打算从实际使用者的角度把培训资料里最关键的东西、以及后来我在项目里反复踩过的坑一起梳理出来。这篇内容不是官方文档的复读而是基于STM32 STemWin动手验证过的经验适合刚接触嵌入式图形界面、准备把屏幕和触摸用起来的开发者。如果你已经在用STemWin但总卡在某些奇怪问题上也可以直接跳到第四节看排错思路。我尽量用“做过项目的人聊方案”的方式来写不摆一堆看起来很豪华但用不上的框架。牵涉到代码的地方我会把关键片段贴出来并解释为什么这么写毕竟搞嵌入式GUI的人最不缺的就是“能跑”的例程缺的是“知道为什么这样跑”的思路。1. 这期STemWin培训到底讲了些什么1.1 STemWin和emWin的关系不是一句话能说清SEGGER把emWin做成了一个跨平台的商用GUI库可以跑在几乎任何嵌入式处理器上。STemWin的本质就是emWin只不过是由SEGGER授权给ST再以ST定制版的形式提供给STM32用户。两者在API、控件、字体、内存管理这些核心逻辑上几乎一致但STemWin在版本跟随、库文件封装和量产授权上会走ST自己的通道。当时很多人问过我一个问题我在ST官网下载的STemWin和SEGGER官网的emWin到底能不能直接用我的回答是功能上是同一条线但工程接入方式有差别。STemWin的库文件通常会按STM32和ARMCC/IAR/GCC分别打包你如果拿SEGGER官方包里同一版本的库强行替换大多数情况下也能编过但我不建议这么做因为ST的定制版会对F103、F4、F7、H7这些内核做专门的优化配置替换后不见得能发挥出同样的性能。还有一个容易被忽略的点STemWin是带许可协议限制的。它不是开源库不能想改源码就改源码。培训资料里最前面那一页PPT就写了“本软件仅适用于意法半导体微控制器”这就是红线。如果你的产品最终要用在非STM32平台上或者想深度定制底层那这条路一开始就要换方向别等界面做完了再回头。1.2 为什么在STM32上做GUI先想到STemWin2018年那个时间节点STM32F4系列是绝对主流图形界面需求也多集中在工控屏、医疗设备、仪表盘和物联网网关这类场景。STemWin能够在那时候成为很多项目的首选原因其实很朴实稳定性好控件够用文档齐全而且ST原厂和SEGGER两边都有技术支撑。相比之下当时LVGL还没像现在这么火AWTK也还处在早期阶段很多团队不敢在生产项目里用太年轻的GUI框架。STemWin优势在于它已经不是“能跑DEMO”的水平而是能支撑实际产品的那种成熟度。窗口管理、消息回调、对话框、内存设备、多缓冲、抗锯齿字体这些功能都能直接在工程里用不需要自己造轮子。另外STemWin跟ST自家硬件配合得很自然。STM32F4/F7/H7有DMA2D、LTDC、FMC这些外设LCD数据搬运和图形填充可以交给硬件加速。STemWin的驱动层预留了底层接口针对这些硬件模块有对应的调用方式。虽然不是所有例程都写得那么完美但方向是对的省了你很多摸索时间。1.3 培训资料的结构与核心内容我把这套培训资料的内容整理成了五块STemWin基础概念什么是窗口、控件、回调机制、消息驱动和裸机画点有什么区别。LCD移植从屏的驱动IC型号入手配置GPIO和总线把显示内容刷到TFT上。触摸输入电阻屏和电容屏的接口方式坐标校准和方向修正。字库与中文显示如何生成字体C数组解决中文乱码。控件与界面设计按钮、文本、进度条、列表框、对话框以及常见交互逻辑。资料里配合的示例工程是基于STM32F407和一块2.4寸SPI接口TFT屏做的。这套组合虽然不复杂但覆盖了STemWin移植过程中绝大多数关键点SPI时序、RGB565像素格式、触摸采样、DMA缓存、GUI内存配置。看完这五块内容你基本就能把STemWin搬到自己的板子上去了。2. 动手移植前先把这三件事准备好2.1 确定屏幕型号、接口和时序很多人移植失败第一原因不是STemWin而是底层的LCD驱动根本没调通。STemWin只是一个GUI框架它最终还是要往屏幕写入像素数据。如果LCD本身不亮、花屏或者刷新错乱那再高层的GUI代码也救不了。你需要先搞清楚三件事屏幕驱动IC是什么型号接口是SPI、8080并口还是RGB接口颜色格式到底是RGB565还是RGB888。以我当时用的ILI9341为例它支持SPI、8080并口常见像素格式是RGB565。用SPI接口时关键是初始化序列和写数据时序。初始化序列一般由屏厂或者驱动IC厂家提供你把它翻译成代码上电后依次发送即可。判断底层是否通有一个简单方法在没有任何GUI代码的情况下往屏幕上填充纯色比如全部写0x001F看屏幕是不是纯蓝色。如果是说明写点和颜色格式对了然后再去接STemWin。STemWin这边的LCD底层通常会看到LCD_X_Config和LCD_X_DisplayDriver两个函数。前者告诉GUI库“屏幕有多大、什么颜色格式、用哪套驱动接口”后者处理控制器初始化、显存偏移、屏幕开关等命令。示例代码里我写的核心逻辑是void LCD_X_Config(void) { /* 接口类型和颜色格式定义 */ GUI_DEVICE_CreateAndLink(GUI_Driver, LCD_LAYER, 0); LCD_SetSizeEx(0, XSIZE_PHYS, YSIZE_PHYS); LCD_SetVSizeEx(0, XSIZE_PHYS, YSIZE_PHYS); LCD_SetColorFormatEx(0, LCD_COLORFORMAT_RGB565); }看起来很简单但这里每一条都要跟你的真实屏幕匹配。尺寸不说如果实际屏是240x320你写成320x240坐标系统会乱掉。颜色格式选错花屏偏色就会特别明显。VSizeEx在双缓冲和局部刷新时很重要先按物理尺寸写没毛病。2.2 触摸方案选择与电气连接触摸方案决定了用户能不能点按钮。常见有两种电阻触摸和电容触摸。电阻触摸常用XPT2046/ADS7846SPI接口读取的是电压值成本低但需要校准电容触摸常用GT911、FT5x06、FT6x36这类I2C接口芯片一般会直接输出触摸坐标环境适应能力好价格也高一点。如果你用的是电阻屏底层要做的事情就是通过ADC或SPI读取X、Y两个方向上的原始电压值。STemWin并不会帮你做这件事它只负责调用两个底层函数int GUI_TOUCH_X_MeasureX(void); int GUI_TOUCH_X_MeasureY(void);这两个函数返回的是当前触摸点的原始值。屏幕初始化后你先在底层把触摸坐标读出来在串口打印一下确认“按角上、值会变”再继续。否则后面所有校准都是空中楼阁。电容屏则要稍微省心一点一般通过I2C读取触摸IC的寄存器得到的是已经量化好的坐标值。但要注意坐标方向很多时候触摸IC输出的坐标原点是左上角而屏的物理方向可能不同必须在STemWin里做方向旋转。处理方式就是修改GUI_TOUCH_X_MeasureX/Y的返回逻辑让触摸坐标和显示坐标保持一致。2.3 内存分配和存储介质规划STemWin运行时会自己管理动态内存用于创建窗口、控件、字体、图片和各个对象。这个内存区域一般通过GUI_ALLOC_AssignMemory分配常见做法是在GUI_X_Config函数中给出一块静态数组或者使用RTOS的堆内存。一个很容易踩的坑是“看起来编译过了运行就死”。多半是GUI_NUMBYTES设置得太小。以320x240 RGB565屏幕为例如果打算开全屏帧缓冲需要3202402150KB这个容量对STM32F103来说基本不能接受。更实际的做法是使用多行缓冲STemWin内部只维护一个几十KB的小缓冲区显示区域被切成分块刷新牺牲一点速度换取内存空间。我一般建议先按这样估算简单界面至少给16KB带常用控件和中文按钮给32KB复杂界面单独优化不盲目追求全屏缓冲。代码可以这样写#define GUI_NUMBYTES (32 * 1024) static U32 aMemory[GUI_NUMBYTES / 4]; void GUI_X_Config(void) { GUI_ALLOC_AssignMemory(aMemory, GUI_NUMBYTES); }这块内存在stm32系统架构中就是普通的RAM不需要特殊处理但要注意放在连续区域并且不要在启动文件里把它覆盖成零。如果后续接了RTOS还想在多个任务之间共享界面资源那内存分配还要考虑任务栈和GUI任务的调度问题。3. 把STemWin跑起来从工程创建到第一个界面3.1 新建工程与STemWin库的加入2018年那会儿很多人还在用标准外设库后来HAL库逐渐成了主流。我在培训里用的既不是纯寄存器也没有依赖CubeMX自动生成的全套代码而是用HAL库为主外围设备手动初始化。这样既不会让新手觉得代码不可控也不会太原始。第一步是新建一个STM32F407工程配置好时钟、GPIO和SPI。我用的是外部8MHz晶振主频跑到168MHzAPB2上的SPI1也做了相应配置。SPI用来刷屏波特率可以先放在36MHz左右等确认稳定后再拉高。GPIO方面屏的CS、DC、RST、BLK分别接在几个普通IO上触摸用另一组SPI或者I2C。第二步是准备STemWin库文件。如果是通过STM32CubeMX和X-CUBE-STemWin扩展包的方式中间件会自动添加到工程里比较省事。如果手动添加目录一般包含inc、lib、src三个部分其中lib里按编译工具链和内核分类比如MDK-ARM、IAR、GCC以及Cortex-M3/M4/M7。别选错文件否则链接阶段会出现一堆undefined symbol或者target mismatch。加入后要在GUIConf.h里配置可选功能#define GUI_NUM_LAYERS 1 /* 单图层 */ #define GUI_OS 0 /* 暂不使用RTOS先跑裸机 */ #define GUI_SUPPORT_TOUCH 1 /* 需要触摸 */ #define GUI_SUPPORT_MEMDEV 1 /* 控件刷新防止闪烁 */这些宏直接影响STemWin的编译规模。如果暂时不需要窗口动画和透明效果可以关掉一部分减少代码量。裸机先跑起来再上RTOS是更稳的节奏。3.2 LCD底层驱动的编写与验证LCD底层是整个移植过程最绕不开的部分。STemWin不直接知道ILI9341的寄存器怎么配它只通过LCD_X_DisplayDriver里收到的命令来做事。你需要在这个函数里处理几个关键的CmdLCD_X_INITCONTROLLER表示初始化控制器LCD_X_SETORG和LCD_X_SHOWBUFFER用于多缓冲切换LCD_X_SETLUT等则用于调色板。以SPI接口的ILI9341为例LCD_X_DisplayDriver里的初始化分支可以放你自己写好的ILI9341初始化函数。初始化完成后STemWin就会回调你提供的写像素函数往缓冲区里填充颜色数据。一个最小可用的写矩形函数大概是static void _DrawRect(int x0, int y0, int x1, int y1, int *pData) { int x, y; for (y y0; y y1; y) { for (x x0; x x1; x) { _WritePixel(x, y, *pData); pData; } } }这个函数在高速刷屏时效率并不高但用来验证链路是足够的。真正优化的时候一般会利用LCD控制器的自增加模式每次只发送一个起始地址然后连续吐出整块像素数据把SPI总线利用率打满。STemWin的FLEXCOLOR驱动已经考虑过这种方案你需要做的是在GUI_DEVICE_CreateAndLink时选择对应的接口模板比如FLEXCOLOR_FS0_SPI_16BPP之类而不是自己拿去一像素一像素刷。3.3 触摸驱动的接入与坐标换算触摸驱动的接入涉及两个层面底层读取原始坐标上层做坐标映射。比如用XPT2046时SPI读取12位ADC值量程大约0到4095。屏幕物理分辨率是240x320那么理论上只需要把原始值等比缩放到这个范围。但实际因为触摸屏边缘非线性、安装偏移和电阻网络误差直接缩放往往点不准需要校准。常见做法是取屏幕四个边角。第一次进入界面时提示用户依次点击左上、右上、左下、右下四个点记录下对应的四个原始坐标值。然后利用线性映射公式计算显示坐标x_display (x_raw - x_min) * 240 / (x_max - x_min); y_display (y_raw - y_min) * 320 / (y_max - y_min);把这个映射代码放在GUI_TOUCH_X_MeasureX/Y外面或者直接放在这两个函数内部都可以。STemWin在检测到触摸事件时会轮询调用这两个函数所以你的返回值必须是已经映射到屏幕像素坐标的数值而不是原始ADC值。之前有同事直接把4095模拟值返回给STemWin结果鼠标指针永远在屏幕边缘乱飘。3.4 跑通第一个Demo并添加控件硬件底层正常后启动流程就很清爽了int main(void) { SystemInit(); BSP_Init(); /* 时钟、GPIO、SPI、触摸 */ GUI_Init(); /* 初始化STemWin */ while (1) { GUI_Exec(); /* 消息循环 */ } }GUI_Init里面会调用底层初始化LCD并创建默认窗口。跑一个最简单的显示GUI_SetFont(GUI_Font24_ASCII); GUI_DispStringAt(Hello STemWin, 10, 10);能看到文字就说明整条链路通了。接下来添加控件典型方式是创建一个自定义窗口和按钮。STemWin的控件都是窗口对象通过回调处理消息static void _cbMainWindow(WM_MESSAGE *pMsg) { switch (pMsg-MsgId) { case WM_PAINT: GUI_SetBkColor(GUI_WHITE); GUI_Clear(); break; case WM_NOTIFY_PARENT: break; default: WM_DefaultProc(pMsg); } }再用WM_CreateWindowAsChild创建主窗口WM_CreateWindowAsChild的返回句柄用来挂按钮hWin WM_CreateWindowAsChild(0, 0, 240, 320, hParent, WM_CF_SHOW | WM_CF_MEMDEV, _cbMainWindow, 0); hButton BUTTON_CreateEx(20, 30, 100, 40, hWin, 0, WM_CF_SHOW | WM_CF_MEMDEV, 0, BUTTON_CF_LEFT);这样你的GUI界面就能响应点击了。过程中你会发现STemWin的核心思路其实就是“创建窗口、设置回调、处理消息”跟PC端GUI有点像但资源更紧、需要更谨慎地规划内存。4. 避坑指南STemWin开发中你一定会遇到的几个问题4.1 一运行GUI函数就进入HardFault先查栈和内存移植初期最常见的现象是编译没问题下载后程序跑到GUI_Init或者创建控件就进HardFault。第一批要查的是启动文件里的栈空间。STemWin的某些底层函数会使用比较大的局部数组尤其是读字体、生成内存设备副本时。默认栈大小0x400对一般裸机程序勉强够GUI场景下极易爆栈。我习惯把栈大小调到0x1000也就是4KB先跑通再说。如果你用RTOS任务栈也要注意专门跑GUI的任务建议给8KB甚至更大。另一个排查点是前面说的GUI_NUMBYTES如果GUI_ALLOC内存不够创建控件会返回NULL句柄但有些代码没判断NULL后续调用操作空句柄就会触发HardFault。排查时可以先用CMSIS-DAP或ST-Link连上在HardFault_Handler里打断点读一下LR和堆栈指针看看是从哪个函数跳进来的。绝大多数时候不是“STemWin有bug”而是资源或参数问题。4.2 花屏或者颜色发紫是像素格式问题STemWin默认情况下以RGB565处理颜色但很多廉价屏的驱动IC出厂配置可能工作在BGR顺序或者你的LCD初始化代码把颜色格式设成了RGB666。结果就是界面看起来整体发蓝、发紫或者红色和蓝色对调。处理办法是先在底层画几个已知颜色的色块确认屏幕实际显示的是否正确。比如用GUI_DrawRect填充纯红色0xF800如果屏幕显示变成了蓝绿色说明颜色通道顺序不对。然后在驱动的初始化序列里修改像素格式寄存器比如ILI9341的0x3A命令把RGB接口顺序改成RGB或者BGR让屏的接收格式和STemWin输出一致。不要试图强行修改STemWin全局颜色这类问题在底层解决最干净。另外如果你用DMA2D做显存搬运还要注意DMA2D的像素格式配置。很多H7系列例程用的是ARGB8888逐行填充你在STemWin里却把颜色深度定义成16bpp也会出现一条条花线。4.3 触摸点击位置和控件位置对不上坐标对不上属于“看着小问题搞起来很绝望”的类型。触摸能响应但按A按钮触发的是B按钮而且在不同屏幕区域偏差还不同。第一步先确认是否只有一个方向反了。如果是那直接调整GUI_TOUCH_X_MeasureX/Y返回值就行。比如显示区域左上角是(0,0)但触摸返回的X从右往左增加那就用LCD宽度减去当前值x LCD_WIDTH - 1 - x_raw。第二步是处理比例不一致。有些屏是320x240横向触摸IC输出范围却是4095x4095直接除以固定系数不对因为触摸屏的有效区域和LCD的有效区域往往不是完全重合。你需要做极值校准也就是前面说的四角采样。如果你已经做了校准但还是偏差那就要检查采样点是不是没落在显示屏有效区边缘。很多时候触摸屏玻璃边缘外面还有一小圈可感应区域采样时要提示用户点击显示区域内侧的边角而不是玻璃最边缘。4.4 中文显示乱码问题出在字体转换默认的STemWin字体只有ASCII直接用GUI_DispString(你好)大概率显示成一条横线或者乱码。原因是字库里没有对应的中文点阵。最直接的办法是使用SEGGER的FontCvt工具把Windows或其他来源的TTF字体转换成STemWin支持的C文件。转换时有几个关键选项字体名称、字体高度、抗锯齿级别和字符范围。中文显示一般要选“Unicode”或“GB2312”范围不要只选Basic Latin否则中文根本不会被打进字库。生成出来的C文件会定义一个字体结构比如extern GUI_CONST_STORAGE GUI_FONT GUI_FontHZ_24;然后在代码里调用GUI_SetFont(GUI_FontHZ_24); GUI_DispString(你好STemWin);如果仍然乱码通常是源文件编码和转换编码不一致。工程源码用UTF-8转换字体时却按GBK生成那字符串和字库索引就两边对不上。统一成UTF-8或者一致用GB2312问题都会消失。4.5 界面刷新慢、闪烁怎么优化在没有硬件加速的情况下STM32F407刷一个240x320的全屏纯色如果通过SPI一像素一像素发送耗时会非常难看。闪烁的主要原因是清屏和绘制分开进行用户先看到清空后的空白再看到重绘内容。解决办法有两个方向一是用内存设备把“可见区域”和“绘制过程”隔离二是启用多缓冲。STemWin里最常用的设置是WM_SetCreateFlags(WM_CF_MEMDEV); WM_MULTIBUF_Enable(1);WM_CF_MEMDEV会让控件在回调整齐绘制时先在内存设备里画好再一次性拷贝到显存区域这样中间过程不可见。WM_MULTIBUF_Enable则需要在LCD底层支持多缓冲的前提下使用否则会有函数无法实现的问题。性能方面如果只是局部按钮、进度条变化没必要全屏刷新。STemWin默认会做窗口失效区域管理但你也要尽量让控件之间不要重叠过多更不要在WM_PAINT里做太多复杂计算。SPI屏如果想要更高刷新率可以把SPI频率往上拉但要保证PCB走线质量否则数据错帧会出现点状雪花。还有一种做法是把屏幕数据写在另一个RAM区域等一帧搭好了再用DMA传输到LCD虽然消耗RAM但效果立竿见影。5. 从STemWin出发聊聊嵌入式GUI的选型这件事5.1 STemWin、LVGL、AWTK的横向对比做完这套培训之后有不少同学问我现在学的是STemWin以后是不是落伍了其实不会。GUI框架虽然有新旧之分底层原理却高度相通。我用表格把当时主流的几个方案拉出来对比了一下方案许可证资源占用控件与生态学习门槛适用场景STemWinST授权商用非开源可高可低RAM优化空间大SEGGER/ST提供大量控件和工具中偏高文档成熟STM32产品线要求稳定的工控/医疗设备LVGL开源免费中等偏高功能越全越吃内存社区活跃控件丰富样式灵活低资料多上手快中低端到中高端MCU产品迭代频繁AWTK开源免费中等控件较全支持跨平台中等文档偏开发方向需要跨平台或多端复用的项目这表不是“谁好谁坏”而是想让大家看清楚STemWin的门槛在授权和商业环境LVGL和AWTK的门槛在硬件资源。如果你只是做一次课程设计完全可以用LVGL几分钟就能刷一个漂亮界面。但如果是量产医疗设备界面要稳定跑七八年那我反而会倾向STemWin因为它在小型MCU上的内存控制更细腻窗口逻辑也更成熟。5.2 什么时候继续用STemWin什么时候换方案分两种情况说。如果团队已经在STM32上用STemWin做出过产品内部积累了不少显示层和触摸层的代码那没有必要为了“追新”而换GUI。STemWin的控件虽然看起来不如LVGL精致但核心需求永远是状态显示、参数设置、数据曲线这些它完全能扛得住。如果硬件资源很充裕屏幕分辨率到了480x800甚至更高界面有丰富动画、皮肤、触摸手势需求STemWin做起来会明显吃力。这时候LVGL更合适。它的样式系统让控件看起来更“现代”社区也有大量现成组件。至于AWTK如果你需要同时跑在RTOS、Linux和Windows上复用同一套逻辑它是不错的选项。我还想提一句不要因为某个GUI框架在论坛上热度高就盲目切换。选型之前先把你产品里最难的那个模块列出来比如“开机动画多国语言实时曲线U盘升级”然后拿主流方案各跑一次原型自然就有答案了。5.3 一点个人操作体会这套STemWin培训资料其实只是我GUI开发生涯里的一个起点。真正让我觉得“会用了”的不是能跑通官方Demo而是后来在一台内存只有64KB的STM32F103上亲手把一个界面从150KB优化到40KB以内并且刷新率还能接受。那时候我才明白STemWin的关键不是“它会画控件”而是“它给了你一大堆内存策略和显示策略你必须清楚自己在用哪一套”。我个人的习惯是先在底层验证像素链路再开GUI_Init先跑一行文字再加控件先不用RTOS跑通了再上操作系统先不开MemDev等出现闪烁再针对性优化。每一步都尽量小步快跑出了错也好定位。希望这些经验和踩坑记录能帮你少走一点弯路。不管最后你选了STemWin、LVGL还是其他GUI方案底层那些关于LCD、触摸、内存和刷新的思路都是相通的。拿这套基本功去打底后面切换框架会比你想象的快很多。