★ FEATURED ARTICLE 1. 项目概述为什么“纯软件”STM32入门正在成为硬需求最近在几个嵌入式学习社群里反复看到同一类提问“刚学STM32手头没开发板能不能先跑起来”“学生党预算有限买完板子下载器杜邦线LED灯珠还没开始写代码钱包先空了。”“公司新招的应届生想提前熟悉外设逻辑但采购流程走完要三周——能不能先搭个环境”这些不是偶然的焦虑而是真实存在的入门断层。我带过十几期嵌入式实训班发现一个扎心事实超过65%的初学者在拿到第一块STM32F103C8T6俗称“蓝 pill”之前已经因为环境搭建失败、ST-Link驱动冲突、Keil授权过期或串口助手收不到数据而放弃超过3次。这不是学习能力问题是工具链门槛把人拦在了门口。所谓“纯软件STM32仿真”核心不是“不用硬件”而是用可验证、可调试、可复现的软件环境完整映射真实MCU的寄存器行为、时序逻辑和外设交互机制。它不替代真机调试比如ADC采样噪声、PWM死区时间、CAN总线物理层抖动但能100%覆盖GPIO翻转时序、UART帧结构解析、TIM定时中断触发、I2C状态机流转、SPI主从通信握手等90%以上的逻辑层验证场景。我把它称为“逻辑沙盒”——就像建筑师先用CAD建模再施工嵌入式开发者完全可以在虚拟世界里把每个外设的初始化流程、中断服务函数执行路径、寄存器修改副作用全部推演清楚等真板到手时直接跳过“为什么LED不亮”“为什么串口乱码”这类低级排错直奔性能优化和系统集成。这个方案的关键价值在于“零成本启动”和“确定性反馈”。一块基础开发板加下载器至少120元而一套完整的纯软件环境STM32CubeMX生成初始化代码、TrueSTUDIO免费版编译、QEMU模拟ARM Cortex-M3内核、OpenOCD提供GDB调试接口、Python脚本模拟外设行为——所有工具链均为开源免费安装包总大小不到800MBWindows/macOS/Linux全平台支持。更重要的是你在QEMU里看到的SYSTICK计数器值、NVIC中断挂起标志、USART_SR寄存器的TXE位变化和真实芯片示波器捕获的波形在逻辑层面完全一致。这不是“差不多”的仿真而是基于ARM官方CMSIS标准的寄存器级建模。接下来我会拆解整个实现链条从为什么选QEMU而非Keil自带仿真器到如何让GPIO输出精准对应到终端打印的“PA51”再到用Python脚本模拟温湿度传感器返回I2C数据——每一步都给出可粘贴运行的命令、配置文件和避坑细节。2. 整体架构设计为什么必须绕开Keil/MDK仿真器选择QEMUOpenOCD组合2.1 Keil仿真器的三大硬伤不是不够用而是根本不能用很多新手会本能地打开Keil uVision点开“Debug → Start/Stop Debug Session”以为这就是“纯软件仿真”。实测下来这种做法在STM32入门阶段几乎必然失败原因有三第一Keil仿真器本质是“指令级解释器”而非“外设级模拟器”。它能正确执行MOV R0, #0x01但遇到LDR R1, [R0, #0x18]读取GPIOA_BSRR寄存器时不会返回任何有意义的值——因为Keil根本没有实现GPIO外设模型。你看到的永远是0xFFFFFFFF或随机值无法验证BSRR写1置位、写0无效的硬件行为。更致命的是当代码执行到while(!(USART1-SR USART_SR_TXE))等待发送完成时Keil仿真器不会模拟TXE位自动置1的过程导致程序永远卡死在循环里连最基本的“Hello World”串口打印都无法完成。第二调试体验严重割裂。Keil仿真模式下你无法使用GDB标准命令如monitor reg查看寄存器、monitor reset软复位所有操作被封装在图形界面按钮中。而真实项目中工程师90%的调试工作依赖GDB命令行比如用watch *(uint32_t*)0x40010800监控USART1_SR地址变化用info registers快速定位SP异常。在Keil里这些能力全部消失你被迫用鼠标点开“Peripheral Registers”窗口手动刷新效率降低5倍以上。第三生态封闭无法扩展。你想模拟一个DS18B20温度传感器Keil不提供外设插件接口。你想把UART输出重定向到Python脚本做协议解析Keil没有标准输入/输出管道。它的设计目标是“辅助真机调试”而非“构建可编程仿真环境”。提示如果你已经装了Keil别卸载——它仍是真机烧录的黄金标准。但入门仿真请立刻切换到QEMU方案。这不是技术偏好而是工程效率的刚性需求。2.2 QEMUOpenOCD组合的不可替代性寄存器级建模与GDB原生支持QEMU作为业界最成熟的开源处理器模拟器其ARM Cortex-M3支持模块qemu-system-arm由ARM官方参与维护关键优势在于外设模型可编程QEMU提供标准外设框架hw/arm/vexpress.c允许开发者通过C代码注入自定义外设行为。我们不需要从零写GPIO模型——社区已维护成熟的stm32f103机器类型基于QEMU 7.2内置GPIOA-GPIOE、USART1-USART3、TIM2-TIM4、I2C1、SPI1等全部F1系列外设的寄存器映射和状态机逻辑。例如当你执行GPIOA-BSRR 0x0020置位PA5QEMU内部会立即更新PA5引脚状态并在下次USART1发送时根据PA9/PA10的复用功能配置决定是否启用TX/RX。GDB Stub深度集成QEMU原生支持GDB远程调试协议-s -S参数启动后自动监听localhost:1234端口。这意味着你可以用VS Code Cortex-Debug插件、CLion、甚至纯终端GDB以完全一致的方式调试仿真代码和真机代码。stepi单步执行指令、break main打断点、print/x *(uint32_t*)0x40010800查看寄存器——所有命令无缝迁移。硬件行为可验证QEMU的外设模型严格遵循STM32参考手册时序图。以TIM2为例当你设置TIM2-PSC 7199预分频7200、TIM2-ARR 999自动重装载1000QEMU会精确模拟72MHz主频经分频后得到10kHz计数频率并在第1000次计数溢出时将TIM2-SR的UIF位置1、触发NVIC_SetPriority(TIM2_IRQn, 0)配置的中断优先级。你甚至可以用GDB命令monitor info qtree查看当前所有设备树节点确认TIM2外设已正确注册。注意QEMU默认不包含STM32专用机器类型。你需要编译启用--target-listarm-softmmu并打上社区补丁后文详述或直接使用预编译的qemu-stm32发行版。这是唯一需要动手编译的环节但只需一次。2.3 架构全景图从代码到可视化的全链路闭环整个纯软件仿真环境由五层构成每一层都承担明确职责且全部开源免费代码生成层STM32CubeMX图形化配置时钟树、GPIO模式、USART参数生成符合CMSIS标准的main.c和stm32f1xx_hal_msp.c。关键点勾选“Generate peripheral initialization as a pair of ‘.c/.h’ files per peripheral”避免HAL库耦合过深时钟配置必须与QEMU模拟的72MHz主频一致CubeMX中APB136MHz, APB272MHz。编译层GNU Arm Embedded Toolchain使用arm-none-eabi-gcc编译生成.elf可执行文件。必须添加链接脚本STM32F103C8Tx_FLASH.ldCubeMX生成确保向量表定位到0x08000000且堆栈段.bss,.data正确分配。模拟层QEMU加载.elf文件实例化stm32f103机器挂载虚拟外设。核心命令qemu-system-arm -M stm32f103 -cpu cortex-m3 -nographic -kernel build/project.elf -s -S其中-nographic禁用图形界面所有输出重定向到终端-s -S启动GDB服务器并暂停CPU。调试层OpenOCD作为GDB与QEMU的桥梁提供标准SWD/JTAG接口抽象。配置文件openocd_stm32f103.cfg仅需两行source [find target/stm32f1x.cfg]加载芯片描述gdb_port 3333暴露GDB端口与QEMU的1234端口解耦便于多工具协同可视化层Python脚本监听QEMU的串口输出通过-serial stdio重定向或通过QEMU的-chardev socket创建TCP服务用Python接收JSON格式的外设状态变更如{gpio:PA5,state:1,timestamp:123456}渲染成Web界面或控制台动画。这才是“把外设一个个跑通”的终极形态——你看到的不再是寄存器值而是实时跳动的LED、滚动的温湿度曲线、闪烁的I2C通信指示灯。这套架构的价值在于它把“理解外设原理”从抽象概念转化为可触摸的反馈。当你的代码让PA5输出高电平终端立刻打印“LED ON”当I2C向0x40地址发送读请求Python脚本同步返回模拟的HTU21D温湿度数据包。这种即时正向反馈是硬件调试永远无法提供的学习加速度。3. 核心细节解析GPIO/USART/TIM/I2C四大外设的仿真要点与实操陷阱3.1 GPIO仿真不只是高低电平更是复用功能与中断触发链GPIO是STM32最基础也最易误解的外设。纯软件仿真中必须同时验证三个层次引脚电平状态、复用功能使能、外部中断触发。QEMU的stm32f103机器对GPIOA-GPIOE的建模覆盖全部16个引脚但新手常踩的坑在于忽略“时钟使能”和“复用重映射”这两个硬件前提。实操步骤与关键验证点在CubeMX中配置PA5为“GPIO_Output”生成代码后检查MX_GPIO_Init()函数__HAL_RCC_GPIOA_CLK_ENABLE(); // 必须存在QEMU会检查此位 GPIO_InitStruct.Pin GPIO_PIN_5; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; // 推挽输出 GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOA, GPIO_InitStruct);注意如果忘记__HAL_RCC_GPIOA_CLK_ENABLE()QEMU中PA5所有寄存器读写均无效HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET)不会改变任何状态。这是90%初学者第一个崩溃点。在main()循环中添加while (1) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); HAL_Delay(500); // 此处必须用HAL_Delay非SysTick_Handler }关键点HAL_Delay()底层依赖SysTick定时器而SysTick在QEMU中需正确初始化。CubeMX生成的SystemClock_Config()已包含HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000)但需确认HAL_RCC_GetHCLKFreq()返回7200000072MHz。若返回0说明系统时钟未配置成功QEMU会报错“Failed to init systick”。启动QEMU并连接GDB# 终端1启动QEMU qemu-system-arm -M stm32f103 -cpu cortex-m3 -nographic \ -kernel build/project.elf -s -S -serial stdio # 终端2连接GDB arm-none-eabi-gdb build/project.elf (gdb) target remote :1234 (gdb) load (gdb) continue此时终端1会持续打印“LED ON”“LED OFF”需在HAL_GPIO_TogglePin后添加printf重定向到串口。若无输出用monitor info registers检查R0-R12是否正常重点看PC是否卡在HAL_Delay的循环里——这通常意味着SysTick未触发中断。独家心得我曾用示波器对比QEMU仿真与真机的PA5翻转波形发现两者上升沿延迟均为12nsQEMU模拟了IO驱动能力但下降沿QEMU为8ns真机为15ns。这说明QEMU建模侧重逻辑时序而非电气特性。因此仿真中验证“能否翻转”“翻转顺序是否正确”即可不要纠结于纳秒级延迟差异。真正需要关注的是当PA5配置为AFIO复用功能如USART1_TXQEMU是否会阻止普通GPIO写操作答案是肯定的——它会返回错误码这正是硬件保护机制的完美复现。3.2 USART仿真从寄存器级收发到协议解析闭环USART仿真最容易陷入“能发不能收”的误区。QEMU的stm32f103机器实现了完整的USART外设模型包括发送移位寄存器、接收移位寄存器、状态寄存器SR、控制寄存器CR1-CR3但必须满足三个条件才能双向通信时钟源必须稳定USART1挂载在APB2总线时钟由RCC_CFGR的PPRE2位控制。CubeMX中需确保APB2 Prescaler1即72MHz否则USARTDIV计算错误波特率偏差超10%导致接收失败。TX/RX引脚必须正确复用PA9/PA10需配置为AF_PP复用推挽且GPIOA_AFRH寄存器的AFRL[9]和AFRL[10]必须指向AF7USART1。QEMU会严格校验此配置若设为GPIO_MODE_OUTPUT_PP则USART1-DR写入数据后USART1-SR的TXE位永不置1。接收缓冲区需主动轮询或中断QEMU不模拟外部串口线上的物理信号因此“接收”动作需由Python脚本模拟。我们采用-chardev socket方式创建TCP服务qemu-system-arm -M stm32f103 -cpu cortex-m3 -nographic \ -kernel build/project.elf -s -S \ -chardev socket,idser0,hostlocalhost,port1234,server,nowait \ -device stm32f103-usart,chardevser0,regbase0x40013800此时QEMU将USART1的收发数据流重定向到本地1234端口。Python脚本连接该端口发送bAT\r\nQEMU内部会触发USART1-SR的RXNE位置1你的代码执行if(__HAL_USART_GET_FLAG(huart1, USART_FLAG_RXNE)) { data huart1.Instance-DR; }即可读取。实操验证清单✅ 发送测试printf(Hello STM32\r\n)应在终端1完整显示无乱码证明TXE/TC标志位正确置位✅ 接收测试Python脚本发送b1代码中HAL_UART_Receive(huart1, rx_data, 1, 100)返回HAL_OK✅ 中断测试配置HAL_UART_Receive_IT(huart1, rx_buffer, 1)当Python发送数据时USART1_IRQHandler必须被调用且HAL_UART_RxCpltCallback触发❌ 常见失败HAL_UART_Receive超时——检查huart1.Init.BaudRate是否与QEMU波特率匹配默认115200QEMU不支持动态波特率调整提示QEMU的USART模型严格遵循参考手册的“发送完成”定义TC位在最后一个停止位发送完毕后置1而非TXE发送寄存器空。很多新手混淆二者导致HAL_UART_Transmit后立即读TC位失败。正确做法是等待TC或使用HAL_UART_Transmit_DMA。3.3 TIM定时器仿真精确到微秒的中断与PWM波形生成TIM2/TIM3/TIM4是STM32的通用定时器仿真难点在于时基精度和中断嵌套行为。QEMU的stm32f103机器对TIM外设的建模精度达1us但需注意两个关键配置预分频器PSC与自动重装载ARR的协同假设系统时钟72MHz要生成1kHz方波周期1ms需设置PSC719972MHz/720010kHz计数频率ARR910kHz/101kHz。QEMU会精确模拟每次计数器递增1溢出时置UIF位并触发中断。若PSC设为7199但ARR为10则实际频率为909HzQEMU会如实反映这一偏差。中断优先级与抢占QEMU完全模拟NVIC的8位优先级分组SCB-AIRCR。当TIM2中断优先级2和EXTI0中断优先级1同时触发时QEMU会按优先级执行__set_PRIMASK(1)可屏蔽所有可屏蔽中断。这是验证中断嵌套逻辑的绝佳沙盒——你无需示波器用GDB的info threads就能看到中断服务函数的调用栈。PWM仿真实操CubeMX中配置TIM3_CH2PB1为PWM输出设置Prescaler7199,Counter Period9991kHzChannel 2 Pulse50050%占空比。生成代码后HAL_TIM_PWM_Start(htim3, TIM_CHANNEL_2)启动PWM。QEMU中无物理引脚但可通过monitor info qtree查看tim3设备状态或用GDB命令(gdb) p/x *(uint32_t*)0x40000400 # TIM3-CR1 查看CEN位是否为1 (gdb) p/x *(uint32_t*)0x4000042c # TIM3-CCR2 查看比较值是否为500若CCR2值正确但无输出检查GPIOB-AFR[1]是否配置为AF2TIM3_CH2复用功能。避坑指南QEMU的TIM模型不模拟“影子寄存器更新时机”因此TIM3-ARR写入后立即生效无需等待UG位。HAL_TIM_Base_Start_IT(htim3)启动后QEMU会按设定频率触发TIM3_IRQHandler但中断服务函数内必须调用HAL_TIM_IRQHandler(htim3)否则UIF位不清零中断持续触发。这是新手最常漏写的代码导致QEMU CPU占用100%。3.4 I2C仿真从总线仲裁到传感器数据模拟I2C是外设仿真中最复杂的协议涉及起始/停止条件、ACK/NACK、时钟拉伸、从机地址匹配。QEMU的stm32f103机器实现了完整的I2C1主控模型但需配合Python脚本模拟从机行为才能形成闭环。核心仿真逻辑QEMU中的I2C1外设模型严格遵循标准当主机发送0x40HTU21D地址后QEMU会检查I2C1-OAR1寄存器的ADD0位是否匹配。若匹配则I2C1-SR1的ADDR位置1触发I2C1_EV_IRQHandler。主机发送读命令0x40 | 0x01后QEMU等待从机响应ACK。此时Python脚本必须通过TCP连接向QEMU的I2C chardev端口发送0x01模拟ACK否则QEMU卡在SB1 ADDR1状态I2C_TransmitData(I2C1, 0x00)失败。Python从机模拟脚本关键片段import socket # 连接QEMU I2C端口假设QEMU启动时 -chardev socket,idi2c0,hostlocalhost,port1235 sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((localhost, 1235)) # 模拟HTU21D收到0xE0触发温度测量后返回2字节温度数据 while True: cmd sock.recv(1) if cmd b\xe0: # 测量命令 sock.send(b\x1a\x8c) # 模拟25.5°C的原始数据 elif cmd b\xf3: # 读取结果命令 sock.send(b\x1a\x8c)实操验证步骤CubeMX中配置I2C1为标准模式100kHz生成代码。在main()中调用HAL_I2C_Mem_Read(hi2c1, 0x401, 0xF3, I2C_MEM_ADD_SIZE_8BIT, rx_data, 2, 100)。启动QEMU和Python脚本观察rx_data[0]是否为0x1Arx_data[1]是否为0x8C。用GDB在HAL_I2C_Mem_Read入口打断点单步执行观察I2C1-SR2的TRA位传输方向、I2C1-SR1的RXNE位接收就绪变化过程。注意QEMU的I2C模型不模拟总线电容和上拉电阻因此不存在“时钟拉伸超时”问题。所有ACK/NACK均由Python脚本显式控制这反而让协议学习更清晰——你知道每一个ACK背后都是代码逻辑而非神秘的硬件时序。4. 实操全流程从零开始搭建可运行的纯软件环境含完整命令与配置4.1 环境准备跨平台工具链安装与验证所有工具均开源免费Windows/macOS/Linux统一操作流程。以下命令在Ubuntu 22.04实测通过Windows用户请用WSL2或Git Bash。步骤1安装ARM GCC工具链# Ubuntu/Debian sudo apt update sudo apt install -y gcc-arm-none-eabi binutils-arm-none-eabi # macOS (Homebrew) brew tap ArmMbed/homebrew-formulae brew install arm-none-eabi-gcc # Windows (MSYS2) pacman -S mingw-w64-x86_64-arm-none-eabi-gcc验证arm-none-eabi-gcc --version应输出10.3.1 20210824或更高版本。步骤2安装QEMU with STM32 support官方QEMU不包含stm32f103机器需编译或使用预编译版# 方案A使用预编译qemu-stm32推荐省时 wget https://github.com/beckus/qemu_stm32/releases/download/v0.2.0/qemu-stm32-0.2.0-ubuntu-20.04.tar.gz tar -xzf qemu-stm32-0.2.0-ubuntu-20.04.tar.gz export PATH$PWD/qemu-stm32-0.2.0/bin:$PATH # 方案B源码编译需15分钟 git clone https://github.com/beckus/qemu_stm32.git cd qemu_stm32 ./configure --target-listarm-softmmu --enable-debug make -j$(nproc) sudo make install验证qemu-system-arm -machine help | grep stm32应输出stm32f103。步骤3安装OpenOCD可选用于高级调试# Ubuntu sudo apt install -y openocd # macOS brew install openocd # 验证 openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg # 应输出 Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748步骤4安装STM32CubeMX图形配置工具访问st.com下载最新版免费安装时勾选“Java Runtime Environment”。启动后Help → Install New Software → 添加https://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.html更新源安装STM32F1 MCU包。4.2 创建第一个仿真项目点亮虚拟LEDStep 1CubeMX配置New Project → Select STM32F103C8Tx → Click “Start Project”Pinout Configuration → Peripherals → GPIO → PA5 → GPIO_OutputSystem Core → SYS → Debug → Serial Wire启用SWD调试Clock Configuration → HSE8MHz → PLL SourceMHSI → SYSCLK72MHzAPB136MHz, APB272MHzProject Manager → Toolchain / IDE → AC6 (ARM Compiler 6) → Code Generator → Check “Generate peripheral initialization as a pair of ‘.c/.h’ files per peripheral”Generate Code → Save asstm32_sim_demoStep 2修改main.c添加LED控制逻辑/* 在main()函数while(1)循环内添加 */ int led_state 0; while (1) { if (led_state 0) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET); printf(LED ON\r\n); led_state 1; } else { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET); printf(LED OFF\r\n); led_state 0; } HAL_Delay(1000); }关键点必须在main()开头添加setvbuf(stdout, NULL, _IONBF, 0);禁用stdout缓冲否则printf输出延迟。Step 3编译生成ELF文件cd stm32_sim_demo/Core/Src # 创建build目录并进入 mkdir build cd build # 生成MakefileCubeMX已生成只需配置 cmake -DCMAKE_TOOLCHAIN_FILE../Toolchain/arm-gcc.cmake .. make -j$(nproc) # 输出build/STM32_sim_demo.elfStep 4启动QEMU仿真# 终端1启动QEMU-serial stdio重定向printf到终端 qemu-system-arm -M stm32f103 -cpu cortex-m3 -nographic \ -kernel ../build/STM32_sim_demo.elf -s -S -serial stdio # 终端2连接GDB调试可选 arm-none-eabi-gdb ../build/STM32_sim_demo.elf (gdb) target remote :1234 (gdb) load (gdb) continue此时终端1将每秒打印“LED ON”“LED OFF”证明GPIO输出仿真成功。4.3 扩展USART通信实现PC与QEMU的双向交互Step 1CubeMX中配置USART1Pinout → PA9/PA10 → USART1_TX/RXConfiguration → Connectivity → USART1 → ModeAsynchronous → Baud Rate115200NVIC Settings → Enable USART1 Global Interrupt生成代码后MX_USART1_UART_Init()已配置好。Step 2修改main.c添加回环测试// 在main()开头添加 uint8_t rx_data; // 在while(1)循环内添加 if (HAL_UART_Receive(huart1, rx_data, 1, 10) HAL_OK) { HAL_UART_Transmit(huart1, rx_data, 1, 100); printf(Echo: 0x%02X\r\n, rx_data); }Step 3启动带串口重定向的QEMU# 启动QEMU将USART1重定向到本地TCP端口 qemu-system-arm -M stm32f103 -cpu cortex-m3 -nographic \ -kernel ../build/STM32_sim_demo.elf -s -S \ -chardev socket,idser0,hostlocalhost,port1234,server,nowait \ -device stm32f103-usart,chardevser0,regbase0x40013800Step 4用Python脚本发送接收数据# uart_test.py import socket import time sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((localhost, 1234)) for i in range(5): sock.send(bytes([0x41 i])) # 发送A,B,C,D,E time.sleep(0.1) data sock.recv(1024) print(fReceived: {data}) sock.close()运行python uart_test.pyQEMU终端将打印“Echo: 0x41”等证明USART双向通信仿真成功。4.4 进阶用Python构建可视化外设监控面板目标将QEMU的GPIO/USART/TIM状态实时渲染为Web界面点击按钮控制虚拟LED。技术栈Flask轻量Web框架 SocketIO实时通信 QEMU chardevStep 1修改QEMU启动命令暴露GPIO状态# 启动QEMU同时监听GPIO和USART端口 qemu-system-arm -M stm32f103 -cpu cortex-m3 -nographic \ -kernel ../build/STM32_sim_demo.elf -s -S \ -chardev socket,idgpio0,hostlocalhost,port1236,server,nowait \ -chardev socket,idusart0,hostlocalhost,port1234,server,nowait \ -device stm32f103-gpio,chardevgpio0,regbase0x40010800 \ -device stm32f103-usart,chardevusart0,regbase0x40013800Step 2编写Flask后端app.pyfrom flask import Flask, render_template from flask_socketio import SocketIO, emit import socket import threading app Flask(__name__) app.config[SECRET_KEY] secret! socketio SocketIO(app, cors_allowed_origins*) # 连接QEMU GPIO端口 gpio_sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) gpio_sock.connect((localhost, 1236)) app.route(/) def index(): return render_template(index.html) socketio.on(connect) def handle_connect(): emit(status, {led: off}) socketio.on(toggle_led) def handle_toggle(data): gpio_sock.send(bTOGGLE_PA5) # 发送控制命令 emit(status, {led: on if data[state] off else off}) if __name__ __main__: socketio.run(app, host0.0.0.0, port5000, debugTrue)Step 3前端HTMLtemplates/index.html!DOCTYPE html html headtitleSTM32 Simulator/title/head body h1Virtual STM32 Dashboard/h1 button idledBtnTurn LED ON
阅读完成 · 觉得有帮助？
