简介：本资源为Segger官方emWin 5.16嵌入式GUI开发套件的完整Windows仿真版源码包，面向嵌入式GUI初学者、MCU应用开发者及需要快速验证界面逻辑的工程师，解决在无硬件目标板条件下开展emWin学习、调试与原型开发的核心需求。压缩包共353个文件，含243个C源码（GUI核心实现与Demo逻辑）、88个头文件（API定义与配置宏）、5个预编译仿真可执行程序（含Win32平台GUI演示）、以及适配MSVC/MinGW/Code::Blocks等主流IDE的项目工程文件（.vcxproj/.sln/.cbp等），另有CleanUp.bat清理脚本与ReadMe.html使用指南，整体体积仅6.9MB，轻量易部署。目前已有107人下载学习。用户可直接编译运行SimulationTrial系列工程，快速体验窗口管理、控件渲染、触控模拟及动画效果；深入GUI/与Sample/目录可掌握内存设备、缩放旋转（MEMDEV_ZoomAndRotate.c）、图标滑动（MOTION_IconSlide.c）等高级特性，并基于源码进行裁剪、移植与性能调优，是理解emWin底层机制与构建定制化嵌入式UI的高价值起点。 搞嵌入式GUI的朋友，对这个压缩包应该不陌生：SeggerEval_WIN32_MSVC_MinGW_GUI_V516.zip。名字很长，但信息量很足——SEGGER官方的emWin评估工程，针对Windows 32位平台，同时照顾到MSVC和MinGW两条编译器路线，版本号V5.16，里面带的是GUI图形界面演示和emWin 5.x的ANSI C源码。这个包最大的价值在于，让你在没有开发板、没有屏幕的情况下，先把emWin的界面逻辑、窗口机制、控件行为在电脑上完整跑起来。
我最早接触这个包，是想评估自家产品用emWin做界面靠不靠谱。当时手头STM32的板子还没画好，又着急验证交互逻辑，就在Windows上把模拟器跑通了。这篇文章我会从文件名开始拆解，把这包到底能干什么、目录怎么组织、MSVC和MinGW怎么选、模拟器怎么编译运行、源码里哪些地方值得细读、实际开发中哪些坑我踩过，全部捋一遍。适合刚接触emWin准备做GUI选型和预研的嵌入式工程师，也适合想在Windows上先验证交互逻辑、再移植到MCU项目的朋友。
1. 项目整体认识：SeggerEval包到底是干什么的
1.1 从文件名拆解核心信息
这个压缩包名字直接说明了“这是给谁用的、怎么用”。我把文件名拆成几段看，每段都是关键配置信息：
- SeggerEval：SEGGER官方评估包。SEGGER是emWin的原作者，Eval代表这是用于评估和学习的版本，不是某个论坛网友随便打包的残缺工程。
- WIN32：目标是Windows 32位环境。这个非常关键，后面编译时选平台、选工具链都受它约束。
- MSVC / MinGW：同时支持微软的MSVC编译器和GNU的MinGW编译器。说明SEGGER官方把两条工具链的工程都准备好了，或者说源码层面已经兼容两种编译环境。
- GUI：包含图形用户界面演示程序，不是纯库文件。
- V516：emWin版本5.16。这个版本相对早一些，但模拟器框架和窗口管理模型到现在变化不大。
- EMWIN5源码：包内带的是emWin 5.x的ANSI C源码，不是只有编译好的库。这意味着你可以直接阅读甚至修改GUI内部实现。
所以这个包本质上是一套“官方仿真开发工具包”，核心就是emWin的PC模拟器。模拟器底层用Windows GDI模拟屏幕像素操作，上层跑的是完整的emWin源码，你写的界面代码在模拟器里跑一遍，后续几乎可以平移到嵌入式平台。
1.2 emWin与SeggerEval是什么关系
emWin是SEGGER公司推出的嵌入式图形库，专门为资源受限的MCU设计，纯C编写，可裁剪性强。很多MCU厂商的SDK里会带emWin的定制版，比如ST的STemWin。SEGGER官方为了降低开发门槛，提供了一个不需要硬件就能跑的评估环境，也就是SeggerEval。它的思路很简单：Windows本身有完善的GDI绘图能力，把LCD驱动层换成GDI模拟，GUI上层代码原封不动地跑。
SeggerEval包里除了模拟器工程，还会带上Sample示例和Doc文档。示例代码覆盖了控件、窗口、字体、位图、存储设备等常用功能。你不需要先买开发板，也不需要先点亮一块LCD，直接在电脑上就能验证“这个GUI库适不适合我的产品”。等界面逻辑验证完，再把代码往真实平台移植，省掉大量前期试错成本。
1.3 这个评估包解决了什么问题
先说结论：这个包能解决“GUI方案选型难”和“界面开发起步慢”两个问题。我自己用过之后感受很深，它至少带来三方面价值：
- 零硬件快速验证：产品还没画板子，界面交互可以先在模拟器上跑给同事和客户看，需求确认效率高很多。
- 源码级学习：包里给出的是完整emWin源码，窗口消息机制、控件绘制、字体渲染都可以直接读代码理解，遇到奇怪问题不再是黑盒猜。
- 跨工具链适配：同一套代码既能用MSVC在Visual Studio里调试，也能用MinGW走命令行/GCC路线，遇到开发环境限制时可以灵活切换。
还有一点很实际：模拟器里调试界面用的就是普通PC调试器，断点、变量监视、内存查看这些操作比在嵌入式IDE里舒服得多。你可以在Windows上把回调逻辑、状态机、数据刷新这些“硬骨头”全部啃完，再到板子上做驱动层适配。
2. 依赖环境准备：MSVC与MinGW两条路线怎么选
2.1 MSVC工具链：Visual Studio下的使用方式
MSVC是微软官方的C/C++编译器，集成在Visual Studio里。用这条路线跑emWin模拟器，步骤非常标准：装Visual Studio，打开包内SimulationTrial目录下的解决方案文件，直接编译运行。
需要注意几点。第一，安装VS时记得勾选“使用C++的桌面开发”工作负载，否则没有Windows SDK和MSVC编译器组件。第二，模拟器目标是WIN32，所以解决方案平台要选x86，不要选x64。第三，如果你不想装完整VS，可以装Visual Studio Build Tools，用命令行工具链编译，但配置过程比GUI方式麻烦一些。
命令行方式需要先初始化环境：打开“x86 Native Tools Command Prompt for VS”，或者手动执行vcvarsall.bat x86，然后进入模拟器源码目录，用cl命令编译。这种方式适合CI构建或习惯命令行的开发者。整体下来，MSVC路线的优势是调试体验好，VS的图形化断点、内存窗口、调用栈分析对排查GUI问题非常有帮助。
2.2 MinGW工具链：免安装VS的轻量方案
MinGW是GCC编译器在Windows上的移植版本。用这条路线不需要安装几十个G的Visual Studio，只需要下载mingw-w64压缩包解压，配置PATH环境变量，然后在命令行里用gcc或g++编译。
MinGW的安装细节单独说一下。网上有很多MinGW下载和安装教程，但容易踩坑的是版本选择。emWin模拟器是32位目标，所以优先选i686版本的mingw-w64，或者用x86_64版本的gcc加-m32参数编译。注意-m32需要32位运行库支持，如果环境里缺少，链接阶段会报一堆找不到库的错，这种情况下直接装i686整套工具链更省事。
线程模型建议选posix，异常处理模型选seh或sjlj都行。此外要记得把编译器所在目录加到系统PATH里，最好再装一个MSYS2或Git Bash，编译时排除一些路径中文和空格问题。配合VSCode的话，需要配置c_cpp_properties.json指定编译器路径，tasks.json写编译命令，launch.json配调试器。这套组合轻量、免费、不占空间，适合习惯命令行和开源工具链的开发者。
2.3 两条路线的本质区别与选型建议
MSVC和MinGW的区别，很多人在搜索“msvc和mingw区别”时都在问。放到emWin模拟器场景下，核心差异体现在四个方面：
| 对比项 | MSVC | MinGW |
|---|---|---|
| 编译器来源 | 微软官方 | GCC移植 |
| 标准库 | MSVC标准库 | GNU libstdc++ |
| 调试器 | Visual Studio调试器 | GDB |
| 体积与安装 | 大，通常几个G | 小，几百M |
| 开源命令行支持 | 一般，需要额外配置 | 天然友好 |
| 与嵌入式工具链一致性 | 差异较大 | 更接近嵌入式GCC |
选型方面我给一个朴素建议：如果你平时开发主要用Visual Studio，直接走MSVC路线，调试最顺手；如果你习惯GCC命令行列编译，或者团队嵌入式工具链就是GCC体系，那选MinGW路线，模拟器代码和真实MCU代码的编译行为更接近。两种方案我都在实际项目里跑过，同一套emWin示例代码，两边编译出来的程序功能上基本一致，没有谁明显更好，取决于你的工作流。
这也就解释了为什么网上会有“qt msvc”、“qt mingw”的区别问题——Qt官方包也分MSVC版和MinGW版，两者ABI不互通，不能混用。emWin模拟器同时提供两种支持，省掉了自己折腾工具链兼容性的功夫。相比之下，OpenCV官方预编译包通常只发布MSVC版，MinGW版要自己用CMake重新构建，这更衬托出SEGGER官方双工具链支持的可贵。
3. 包内结构与源码初探
3.1 解压后的目录结构解析
解压后建议先整体浏览一遍目录，别急着点开工程文件。典型的结构会包含这几个核心部分：
- SimulationTrial：模拟器工程主目录，包含GUI源码、示例程序和编译器工程文件。
- Sample：示例代码目录，按功能分类，如Widget演示、对话框、存储设备、字体等。
- Doc：文档目录，里面有emWin的用户手册和各个模块说明，这是最值得看的资料。
- Inc：公共头文件目录，GUI.h、WM.h等核心头文件在这里。
SimulationTrial目录内部通常还会细分：GUI源码目录（包含WM、Widget、Font、JPEG、PNG等子目录）、LCD模拟驱动文件、Application相关源文件（MainTask.c等）、以及面向不同编译器的工程文件。不同版本的组织方式会有差异，但整体思路一致。
建议刚开始不用把每个文件都看一遍，先摸清三条线索：入口在哪里、源码怎么组织、配置在哪里改。入口看MainTask.c，源码组织看GUI目录，配置看GUIConf.c和LCDConf.c。把这三条线索理清，整个包的结构就清楚了。
3.2 跑模拟器的两种姿势
跑模拟器有两种常见方式，对应刚说的两条工具链路线。
用MSVC路线时，到SimulationTrial目录下找.sln后缀的解决方案文件，或者找.vcxproj工程文件，用Visual Studio打开。如果包内带的工程版本比较旧，VS会提示升级，一般直接确认升级就行。打开后把平台选成x86，按F5编译运行。首次编译会花几分钟，因为emWin源码文件比较多，之后增量编译就快了。
用MinGW路线时，包内不一定自带Makefile，可能需要自己写一个，或者用Code::Blocks、CLion这类支持GCC的IDE新建工程，把源码目录加入编译范围。也有版本会附带Makefile或批处理脚本，具体看解压后的文件。如果都没找到，就只能手写编译命令或Makefile了，这个过程不复杂，后面第5章我会给出详细步骤。
不管哪条路线，程序启动后都会弹出一个窗口，显示emWin运行画面，并带一个鼠标模拟触摸的交互环境。你可以像操作手机一样点击界面上的按钮和控件，验证交互逻辑。
3.3 值得精读的几个关键源文件
模拟器代码里有一批文件是理解整个系统的钥匙，值得逐个精读。
第一个是GUIConf.c，这是全局配置核心。里面有宏定义控制GUI_NUMBYTES动态内存大小、是否启用存储设备GUI_SUPPORT_MEMDEV、是否支持操作系统接口GUI_OS等。模拟器默认配置通常很宽松，真实MCU移植时这个文件必须按内存情况重新调整。
第二个是LCDConf.c，模拟LCD驱动。在这里设置屏幕分辨率、色深、缓冲模式。模拟器里它把像素绘制转发到Windows GDI，真实板卡移植时就需要换成真实的LCD面板驱动。对比着看，能清晰理解emWin的LCD驱动抽象层是怎么设计的。
第三个是MainTask.c，程序入口主任务。模拟器环境里MainTask就是启动点，它负责调用GUI_Init初始化，创建窗口和控件，然后进入消息循环或者用GUI_Delay/GUI_Exec驱动刷新。真实嵌入式项目里，这个任务通常会放到RTOS的线程里运行，但逻辑结构完全一致。
第四个是GUI.h，所有emWin API的声明都在这里。遇到不熟悉的函数时先查这个头文件的注释，再翻文档，效率最高。把这几个文件读透后，再去看示例代码就会顺畅很多。
4. 核心机制解析：emWin窗口管理与回调设计
4.1 emWin的整体架构
emWin虽然庞大，但架构分层很清晰。从底层往上依次是LCD驱动层、图形设备层、GUI核心层、窗口管理器层、控件层，最上面才是你的应用代码。
LCD驱动层负责把像素点最终显示到屏幕上，模拟器里对应GDI模拟，真实硬件里对应具体的LCD控制器驱动。图形设备层封装了绘图原语，像画点、画线、填充矩形这些操作都在这层实现。GUI核心层提供字体渲染、位图操作、颜色管理等功能。窗口管理器层引入窗口和消息机制，是emWin交互逻辑的基础。控件层则是在窗口之上封装的按钮、文本框、列表框等现成组件。
理解这个分层对排查问题特别重要。比如界面刷新慢，问题可能出在GUI核心层的存储设备配置，也可能出在底层驱动缓冲设置，甚至连窗口重绘机制都会影响。有分层思维后，你能快速定位问题属于哪一层，不会漫无目的地瞎试。
4.2 窗口回调机制
emWin的窗口交互核心是回调函数。每个窗口创建一个回调函数，负责响应WM_PAINT、WM_TOUCH、WM_NOTIFY_PARENT等消息。这个设计思路和Windows窗口消息机制很像，但实现更轻量。
static void _cbWin(WM_MESSAGE * pMsg) { switch (pMsg->msgId) { case WM_PAINT: GUI_SetBkColor(GUI_WHITE); GUI_Clear(); GUI_SetColor(GUI_BLACK); GUI_DispStringAt("Hello emWin", 10, 10); break; default: WM_DefaultProc(pMsg); } }上面这段是典型的窗口回调结构。窗口创建后，系统在需要重绘、收到触摸事件、父窗口控件发生交互时，都会往回调里发消息。开发者在回调里维护界面状态，而不需要自己写死某个操作流程。
理解和Windows消息机制类比一下：窗口就像一块画布，回调就是画布的事件监听器。你用WM_CreateWindow创建画布，用GUI_Delay让系统有时间处理消息，界面就自动“活”起来了。这种设计让界面和业务逻辑解耦，多个窗口之间通过消息通信，复杂界面也能拆得很干净。
4.3 字体与中文显示
这是新手最容易卡壳的地方。模拟器默认加载的字体都是ASCII字体，直接GUI_DispString显示中文字符串，出来的基本是乱码或者方块。原因不复杂：emWin的字体模块需要中文字库支持，系统默认不包含中文点阵字模。
解决思路有两条。第一，用SEGGER的FontCvt工具把TTF字体转换成C语言字模数组，然后通过GUI_SetFont(GUI_FONT_XX)挂到程序里。这种方式适合真实MCU场景，字模可以烧进Flash。第二，在模拟器里如果只是想快速看效果，可以用代码加载Windows系统字体，但这种方式依赖PC环境，移植到MCU时不能直接用，所以我也只是临时验证用。
另外一个高频坑是编码格式。emWin默认支持ASCII码，如果要用中文，最好统一使用UTF-8编码，并在初始化时调用GUI_UC_SetEncodeUTF8()配置内码转换。否则源码文件是GB2312编码、UTF-8编码互相混用，显示就会乱。建议整个工程统一用UTF-8，包括所有源文件的保存编码，省掉很多莫名其妙的乱码问题。
5. 实操演示：从零跑通一个模拟器程序
5.1 搭一个MinGW手写Makefile工程
如果你和我一样习惯命令行，那可以用手写Makefile的方式把模拟器跑起来。假设已经把包解压到D:\SeggerEval，首先创建build目录，然后写一个Makefile，把GUI源码和示例源码都编译进去。
CC = gcc TARGET = emWinDemo.exe CFLAGS = -m32 -O2 -Wall -I./SimulationTrial \ -I./SimulationTrial/GUI/Inc \ -I./SimulationTrial/GUI/Addons \ -I./SimulationTrial/Application LDFLAGS = -m32 -mwindows -lgdi32 -luser32 -lcomdlg32 SRCS = $(wildcard ./SimulationTrial/GUI/*.c) \ $(wildcard ./SimulationTrial/GUI/Widget/*.c) \ $(wildcard ./SimulationTrial/GUI/WM/*.c) \ $(wildcard ./SimulationTrial/GUI/Font/*.c) \ $(wildcard ./SimulationTrial/Application/*.c) OBJS = $(SRCS:.c=.o) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $@ $^ %.o: %.c $(CC) $(CFLAGS) -c -o $@ $< clean: rm -f $(OBJS) $(TARGET)这里有几个关键点。第二行CC指定编译器，我默认用系统PATH里的gcc。CFLAGS里的-m32强制生成32位代码，和WIN32目标对应。LDFLAGS里的-mwindows让程序以Windows GUI子系统方式运行，不会弹出黑色控制台窗口，同时手动链接GDI、用户界面和通用对话框三个系统库，模拟器依赖它们完成窗口和绘图。
如果你装的是i686版本MinGW，那-m32可以去掉，因为编译器本身就只能生成32位代码。源码目录的c文件通配符匹配不一定完全准确，实际要按你解压出来的目录结构调整。我第一次编译时就漏了Font目录，结果链接器报一堆字体函数的未定义引用，补上之后一次通过。
5.2 写一个带按钮和文本的界面
工程搭好后，写一个最简单的交互界面来验证整个链路。创建一个main_task.c，放置模拟器入口代码，用窗口管理器创建父窗口，再往里面放一个TEXT文本控件和一个BUTTON按钮控件。
#include "GUI.h" static void _cbMainWin(WM_MESSAGE * pMsg) { WM_HWIN hWin = pMsg->hWin; switch (pMsg->msgId) { case WM_PAINT: GUI_SetBkColor(GUI_GRAY); GUI_Clear(); break; case WM_NOTIFY_PARENT: if (pMsg->Data.v == WM_NOTIFICATION_RELEASED) { GUI_MessageBox("Button pressed", "Info", GUI_MESSAGEBOX_CF_MOVEABLE); } break; default: WM_DefaultProc(pMsg); } } void MainTask(void) { WM_HWIN hMain; GUI_Init(); hMain = WM_CreateWindow(0, 0, 320, 240, WM_CF_SHOW, _cbMainWin, 0); TEXT_CreateEx(10, 10, 200, 20, hMain, WM_CF_SHOW, 0, GUI_ID_TEXT0, "Hello emWin"); BUTTON_CreateEx(10, 40, 100, 30, hMain, WM_CF_SHOW, 0, GUI_ID_BUTTON0, "Click Me"); while (1) { GUI_Delay(10); } }这段代码的逻辑不复杂：GUI_Init初始化GUI系统，WM_CreateWindow创建一个320x240的父窗口，TEXT_CreateEx和BUTTON_CreateEx创建文本控件和按钮控件。点击按钮时，控件会向父窗口发送WM_NOTIFY_PARENT消息，回调里弹出一个消息框。
注意MainTask的命名和返回类型，模拟器启动时会直接调用这个函数，所以不能改成别的名字。while循环里GUI_Delay(10)让系统周期性地处理窗口消息和重绘任务，如果去掉这个循环，界面会卡死无响应。
5.3 编译运行及调试
在build目录下执行make，如果一切顺利，会生成emWinDemo.exe，直接双击运行。程序启动后会显示一个灰色窗口，里面有“Hello emWin”文字和一个“Click Me”按钮，点击按钮会弹出消息框。
如果编译报错，大概率是这几类问题：头文件路径没写全、某个目录漏了、链接库不全。逐个修正就行。如果程序运行后窗口闪退，检查一下MainTask是否真的被调用，以及GUI_Init是否放在创建窗口之前。如果程序窗口黑色或空白，基本可以断定进入了某个分支但没有重绘，点一下窗口边缘触发重绘看是否恢复，能恢复就说明WM_PAINT处理有问题。
调试时我习惯在代码里临时加GUI_Delay延长，观察某一帧的绘制状态；或者用GUI_DispStringAt在特定位置打印变量值，虽然土但很有效。等逻辑稳定后再把这些调试代码删掉。
6. 常见问题与排查技巧实录
6.1 编译阶段的坑
编译阶段是我踩坑最多的地方。第一类问题是头文件找不到。模拟器的GUI.h等头文件分布在多个目录下，Makefile或工程配置里Include路径漏掉一个，立刻报错。解决方案是打开错误提示，看清是哪个文件里的哪个头文件找不到，反查它在哪个目录，把Include路径补上。
第二类问题是链接错误。最典型的是undefined reference to__imp_...一类的符号，说明对应的Windows系统库没有链接。GDI相关函数在gdi32，窗口管理相关在user32，对话框相关在comdlg32，把这三个库链接上，能解决大多数链接问题。
第三类问题是32位和64位混用。模拟器源码是WIN32目标，如果用64位MinGW直接编译，会出现很多“incompatible pointer to integer conversion”或者无法预料的链接错误。解决问题的方法就是统一用32位编译器，或者给gcc加-m32。
还有个容易被忽略的点：VS新版本打开旧工程时，Windows SDK版本可能会自动升级到最新版，而emWin老版本工程有时和最新SDK不兼容，出现重定义之类的错误。这时候手工把工程的SDK版本降级到8.1或10.0某个稳定版本，一般能解决。MinGW和VSCode组合下，要检查c_cpp_properties.json里selectedCompiler是否指向了正确的gcc路径，环境变量配置错误会导致编译器调用失败。
6.2 运行和显示阶段的坑
程序编译通过不代表万事大吉，运行阶段的显示问题更磨人。
先说黑屏问题。最常见原因是主循环里没有调用GUI_Delay或GUI_Exec，窗口创建后消息队列没有驱动，绘制请求得不到处理。另一种原因是WM_PAINT回调里的绘制代码没有被正确触发，可以手动调用WM_Paint(hWin)强制重绘测试。
再说中文乱码。这个问题在第4章已经讲过，根源基本都是字体和编码问题。检查两点：是否在GUI_Init后调用了GUI_UC_SetEncodeUTF8()，以及当前字体是否包含中文字模。ASCII字体显示中文一定是乱码，不是代码逻辑问题。
存储设备闪
本文还有配套的精品资源，点击获取
