简介基于STM32的谷歌小恐龙游戏移植项目面向嵌入式学习者和游戏开发爱好者演示如何将浏览器经典小游戏完整落地到STM32F103平台。项目核心涵盖GPIO接入按键与LCD屏、定时器控制游戏帧率、中断响应跳跃、SPI/I2C驱动显示、内存优化以及C语言重写游戏逻辑等关键环节适合希望综合提升STM32外设编程与嵌入式图形开发能力的中级开发者。压缩包共87个文件以45个h头文件、20个c源码文件为主辅以makefile构建脚本、ioc工程配置、md说明文档及图片资源整体约855KB目录结构清晰按Drivers、Core、Src、Inc等模块组织便于直接导入CubeIDE或阅读移植思路。资源已有1208人学习包含完整的工程源码、LCD显示驱动、按键控制逻辑和碰撞检测与计分系统入手后可快速复现并基于此扩展动画、音效或更多关卡。1. 基于stm32的谷歌小恐龙游戏练的不是点灯是整条渲染链路把Chrome断网页的小恐龙搬到嵌入式屏上第一反应可能是“一个玩具”。但真要在stm32上跑起来你面对的是SPI屏驱动、帧缓冲管理、定时器中断调度、碰撞检测状态机还有“屏幕刷新跟不上逻辑更新”这个所有嵌入式GUI都要过的坎。这个项目很适合作为stm32入门到进阶的中转站也能直接当课设或毕业设计底子。文章里我用F103蓝丸加128x64的SSD1306来讲CPU性能和RAM余量都留出了足够空间你换F401、F407或者国产APM32也只要对着引脚改下就行。2. 硬件选型与CubeMX工程主控、屏幕、引脚先谈清楚2.1 主控选型F103C8T6、F401CCU6、F407VET6 怎么选这个游戏本身计算量不大真正的瓶颈在屏幕刷新和内存。先把三款常见的stm32芯片放一起比型号Flash/RAM主频硬件SPI适合度STM32F103C8T664KB/20KB72MHzSPI1/SPI2主选RAM够放帧缓冲Flash够放spriteSTM32F401CCU6256KB/64KB84MHzSPI1/2/3有余量上彩色ST7735也不怕STM32F407VET6512KB/128KB168MHzSPI1..3资源过于充足玩具项目性价比低我一般建议F103C8T6起步原因很直接这个项目用到的全部资源就是一块单色屏帧缓冲、几十个sprite数组、两个定时器。F103C8T6的20KB RAM里SSD1306的帧缓冲只占512字节剩下的空间足够你做双缓冲或者存曲线数据。64KB Flash在开-O2优化后也剩不少不至于为了挤空间去手写汇编。另外提一下APM32F103系列在寄存器和HAL库兼容性上做得相当好如果你手上有国产替代芯片工程文件基本可以直接烧不用改引脚映射。2.2 屏幕与接口SSD1306 SPI是首选I2C版本要慎用市面上一搜“stm32 屏幕”会出现一堆型号但适合这个游戏的就两类0.96寸的SSD1306和1.8寸的ST7735。我用下面这张表说明差别屏幕分辨率与颜色帧缓冲大小整屏刷新开销推荐度SSD1306 0.96寸 SPI128x64 单色512字节8MHz SPI下约0.5ms首选SSD1306 0.96寸 I2C128x64 单色512字节400kHz下约23ms不推荐做游戏ST7735 1.8寸 SPI128x160 RGB56540KB左右局部刷新可用备选ILI9341 2.4寸 SPI240x320 RGB565150KB以上F103吃不消不推荐说句不好听的SSD1306的I2C版本在游戏项目里是个坑。400kHz I2C理论带宽约50KB/s一屏1024字节大约要20多毫秒也就是你辛辛苦苦把逻辑跑出60fps最后被屏幕刷新锁死在四十多帧而且CPU全程阻塞在发数据上。换成SPI版本后同样内容一帧几毫秒就发完完全不给游戏逻辑拖后腿。2.3 引脚分配、CubeMX配置与最小驱动代码以SSD1306 4线SPI为例接线非常固定信号STM32引脚说明SCKPA5SPI1_SCKMOSIPA7SPI1_MOSICSPB0GPIO输出低电平有效DCPB1GPIO输出0为命令1为数据RESPB10GPIO输出复位KEYPA0按键输入接3.3VCubeMX里勾上SPI1的Full-Duplex Master模式Prescaler选16分频72MHz主频下得到4.5MHz的SPI时钟SD1306完全支持这个速度。GPIO配置上CS、DC、RES全部设成推挽输出KEY设成下拉输入。用HAL库写最小驱动只需要两步初始化序列以及一个发命令的函数。初始化时要特别注意SSD1306必须先关显示0xAE等charge pump配置好再开显示0xAF顺序反了大概率花屏。static void OLED_Cmd(uint8_t cmd) { HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_RESET); // CS拉低 HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_RESET); // DC0 命令 HAL_SPI_Transmit(hspi1, cmd, 1, 10); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET); // CS拉高 } static void OLED_Init(void) { HAL_GPIO_WritePin(GPIOB, GPIO_PIN_10, GPIO_PIN_RESET); HAL_Delay(50); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_10, GPIO_PIN_SET); HAL_Delay(20); OLED_Cmd(0xAE); OLED_Cmd(0xD5); OLED_Cmd(0x80); OLED_Cmd(0xA8); OLED_Cmd(0x3F); OLED_Cmd(0xD3); OLED_Cmd(0x00); OLED_Cmd(0x40); OLED_Cmd(0x8D); OLED_Cmd(0x14); // 打开charge pump OLED_Cmd(0x20); OLED_Cmd(0x00); // 水平寻址模式 OLED_Cmd(0xA1); OLED_Cmd(0xC8); OLED_Cmd(0xDA); OLED_Cmd(0x12); OLED_Cmd(0x81); OLED_Cmd(0xEF); OLED_Cmd(0xA6); OLED_Cmd(0xAF); }这里HAL_SPI_Transmit的最后一个参数是超时毫秒游戏代码里我习惯写10。另外注意CS和DC的时序必须在发送命令前后手动维护CubeMX的软件NSS不会帮你管这个。发数据的版本只要把DC拉高其它逻辑一模一样。如果你用的是Keil MDK而且还没装F1系列芯片包打开Pack Installer搜“STM32F1xx_DFP”装上否则CubeMX生成的工程编译时直接报Device not found这步是很多刚复现stm32项目的人最先卡住的地方。3. 定时器调度与状态机跳跃、障碍和碰撞都在这几毫秒里发生3.1 游戏逻辑不要裸写在while(1)里用固定时间片驱动初学阶段常见的写法是直接在while循环里“刷新一下屏幕移动一下障碍”看起来简单实际跑起来会发现障碍移动速度忽快忽慢画面有小撕裂。原因是渲染耗时不稳定逻辑更新被渲染拖累。这个游戏跟流水灯不一样物理参数基于时间而不是基于循环次数所以必须固定时间片。固定时间片的做法是用stm32定时器产生中断中断服务函数里只置标志位主循环检测到标志位后再执行逻辑和渲染。volatile uint8_t g_gameTick 0; void TIM2_IRQHandler(void) { if (TIM2-SR TIM_SR_UIF) { TIM2-SR ~TIM_SR_UIF; g_gameTick 1; } } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_SPI1_Init(); OLED_Init(); TIM2_Init(); // 71分频9999重载10ms中断一次 while (1) { if (!g_gameTick) continue; g_gameTick 0; ProcessInput(); UpdateGame(); RenderFrame(); } }参数说明TIM2的预分频器设为71自动重载值设为999972MHz经过72分频后正好是1MHz再计10000个数就是100Hz也就是10ms一个tick。ISR里不做游戏逻辑只翻标志好处是中断执行时间极短不会跟主循环里的HAL_Delay之类功能抢时间。有人把逻辑直接写进中断结果跳跃和障碍更新互相穿插调参时想骂人。3.2 状态机待机、奔跑、撞树三个状态一笔理清小恐龙游戏的逻辑结构用状态机标注最清晰。开机进入待机按一下进入奔跑奔跑中检测到碰撞就进入结束结束再按一次跳回待机。typedef enum { ST_READY, // 待机恐龙原地站立 ST_RUNNING, // 奔跑中障碍物开始移动 ST_OVER // 碰撞结束等待复位 } GameState; static GameState g_state ST_READY; void ChangeState(GameState next) { g_state next; if (next ST_READY) { dinoY GROUND_Y; dinoVY 0; obstacleX -1; score 0; } }这里没有用switch包裹所有状态行为而是在每个Update函数开头判断当前状态代码更直白。容易出现的问题是进入ST_OVER后障碍物还在继续移动。正确做法是在状态切换时把所有动态变量重置而不是等下一帧去“补救”。3.3 跳跃物理用整数运算别让浮点进中断路径跳跃用重力模型模拟但嵌入式里我不建议用浮点原因不是算不动而是不同编译优化级别下浮点行为不一致调试麻烦。用整数就够了。#define GROUND_Y 56 #define GRAVITY 3 #define JUMP_VY -14 static int8_t dinoY GROUND_Y; static int8_t dinoVY 0; static uint8_t isJumping 0; void UpdateDino(uint8_t isKeyPressed) { if (!isJumping isKeyPressed) { isJumping 1; dinoVY JUMP_VY; } if (isJumping) { dinoVY GRAVITY; dinoY dinoVY; if (dinoY GROUND_Y) { dinoY GROUND_Y; dinoVY 0; isJumping 0; } } }解释一下这组参数的含义100Hz tick下起跳速度-14像素/帧重力加速度3像素/帧平方。最高点大约在1414/(23)约33像素处。太小了跳不过仙人掌太大了一跳顶到屏幕边缘。这组数据是我反复试过后比较舒服的区间。帧率JUMP_VYGRAVITY最高点估算100Hz (10ms)-143约33像素100Hz (10ms)-102约25像素200Hz (5ms)-286约65像素偏跳太高调参时有个原则改跳跃速度就同步缩放重力两者保持同一比例才不会让跳跃轨迹变“飘”。很多人只把JUMP_VY改大结果恐龙像蹦床一样半天不下来。3.4 障碍物生成与碰撞检测的边界留一线障碍物每隔一段时间从屏幕右侧生成向左移动移出左边界后归位。每帧移动两个像素。static int8_t obstacleX -1; static uint16_t obstacleCountdown 30; #define OBSTACLE_W 10 #define OBSTACLE_H 16 #define OBSTACLE_Y (GROUND_Y - OBSTACLE_H) void UpdateObstacle(void) { if (obstacleX 0) { if (obstacleCountdown 0) { obstacleCountdown--; return; } obstacleX 128; obstacleCountdown 20 rand() % 30; return; } obstacleX - 2; if (obstacleX OBSTACLE_W 0) obstacleX -1; }碰撞检测是实现“手感”的关键地方。很多新手直接拿整个sprite矩形去做相交判断结果玩家觉得“明明没撞上怎么就死了”。原因是黑白的sprite边缘有透明像素视觉上没接触几何上已经重叠所以要做边界内缩。static uint8_t CheckHit(void) { int8_t dl dinoX 2; int8_t dr dinoX DINO_W - 3; int8_t dt dinoY 2; int8_t db dinoY DINO_H - 1; int8_t ol obstacleX 1; int8_t orr obstacleX OBSTACLE_W - 2; int8_t ot obstacleY 1; int8_t ob obstacleY OBSTACLE_H - 1; return !(dr ol || dl orr || db ot || dt ob); }每个方向缩进1到2个像素看起来完全没毛病玩家体验上会觉得“判定很公平”。这个技巧在纯色数字屏幕上特别管用因为sprite没有半透明过渡全包矩形必然偏大。4. 渲染与显存优化位图定义、页对齐和局部刷新怎么配合4.1 帧缓冲一张512字节的画布解决所有闪烁问题SSD1306内部有1KB显存但游戏里不能直接往屏上画一个点就完事。你操作屏幕内部显存每次“读改写”都要通过I2C或SPI跟屏幕芯片打交道速度很慢还会闪烁。常见的做法是在stm32端再开一块等尺寸的帧缓冲所有绘制操作先写进这块RAM最后一次性同步到屏幕。static uint8_t fb[128][8]; // 128列 x 8页每页8像素下面这个函数是帧缓冲最基本的操作所有sprite绘制都建立在它之上static void FbSetPixel(uint8_t x, uint8_t y, uint8_t on) { if (x 128 || y 64) return; uint8_t page y 3; uint8_t bit 1u (y 7); if (on) fb[x][page] | bit; else fb[x][page] (uint8_t)~bit; }y 3是页号0到7y 7是页内位偏移。这个函数看着简单但它是后面所有渲染操作的地基。注意on是uint8_t别拿1直接进去展开成int后在位运算里容易出意外。使用时有两点要注意第一帧缓冲坐标原点和屏幕机械方向可能不一致不同卖家模块的镜像方向不同如果发现画面反了调整初始化序列里0xA1和0xC8这两个命令即可第二fb是三维数组的话尽量把列放在第一维因为后面局部刷新时按列连续读取cache友好。4.2 位图存储按页组织sprite比BMP数组省事十倍从网上找一张Chrome恐龙的截图转成数组最常见的后果是方向不对、颜色反转、烧进去花屏。我的做法是手工按页组织位图一个16x16的sprite拆成上下两页每页16字节每字节代表8个像素的列。static const uint8_t dino_run1[2][16] { { 0x00, 0x7F, 0x40, 0x40, 0x40, 0x7F, 0x00, 0x40, 0x40, 0xE0, 0xE0, 0x40, 0x40, 0x40, 0x40, 0x00 }, { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x60, 0x60, 0x60, 0x60, 0x60, 0x60, 0x60, 0x60, 0x00 } };数组里的具体数值只是形状示意不代表逐像素对应Chrome原版你可以用取模软件或者手写像素编辑器生成自己的。关键在存储结构每一行代表一页16字节对应16列字节内高位在上。这样绘制时不需要逐像素扫描整块做位或写进帧缓冲即可。static void FbBlitPageAligned(uint8_t x, uint8_t page, const uint8_t *spr, uint8_t w) { if (page 8) return; for (uint8_t i 0; i w; i) { uint8_t cx x i; if (cx 128) break; fb[cx][page] | spr[i]; } }参数含义x是列起点page是页号spr是位图数组指针w是sprite宽度。这个函数假设绘制位置的y坐标是8的倍数实际游戏里地面在y56正好是页7天然对齐。如果以后要做非页对齐的动画比如sprite从y50开始就得在位移合成逻辑上再写一层新手阶段先保证页对齐能让调试成本大幅下降。素材的Flash占用在这种存储格式下非常低素材尺寸占用Flash恐龙跑步两帧16x1664字节仙人掌10x1620字节云16x816字节地面滚动条128x8128字节加起来还不到300字节这就是单色屏的好处。彩色屏一张sprite动辄几百字节Flash和RAM都会紧张。4.3 局部刷新按脏矩形刷整屏刷新留给菜单画面SSD1306支持页地址和列地址设置利用它的页面模式可以只刷新地图上真正变化的矩形区域这在游戏里效果极其明显。恐龙在x40附近障碍在100到128之间移动两个区域根本不重叠所以每帧只需要发送两个窄条。void OLED_WriteRect(uint8_t x0, uint8_t page0, uint8_t x1, uint8_t page1) { OLED_Cmd(0x21); // 设置列地址范围 OLED_Cmd(x0); OLED_Cmd(x1); OLED_Cmd(0x22); // 设置页地址范围 OLED_Cmd(page0); OLED_Cmd(page1); for (uint8_t p page0; p page1; p) { for (uint8_t c x0; c x1; c) { OLED_Data(fb[c][p]); } } }有了这个函数渲染流程变成清帧缓冲画恐龙画障碍画地面然后调用两次OLED_WriteRect一次刷恐龙区域一次刷障碍区域。屏幕数据量从整屏512字节降到几十字节SPI的阻塞发送时间可忽略肉眼几乎看不到任何撕裂。有一点要提醒局部刷新要处理“擦除旧位置”这一环。最常见的问题是恐龙移动后旧位置的残影还在。解决思路是在刷新恐龙区域前先往帧缓冲里写一个全0的区域块把旧像素清掉再画新位置。也就是说每一帧固定区域一定要被完整重建而不是只在上面叠加新素材。5. 调参与排错帧率测量、0x00008200 和按住跳跃长度的标定5.1 用GPIO翻转法量出真实渲染帧率不需要J-Link不需要高级IDE找一个空闲GPIO配置成推挽输出在渲染函数末尾翻转一次用逻辑分析仪或者示波器量方波频率就行void RenderFrame(void) { // ... 清缓冲、画恐龙、画障碍、局部刷新 ... HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_8); }PA8输出方波的频率就是渲染帧率逻辑分析仪看得很直观。如果方波频率不稳定说明某帧渲染时间长多半是SPI传输阻塞或整屏刷新混进了局部刷新。理论最大帧率由HAL_SPI_Transmit的阻塞时间决定不是逻辑代码跑多快。5.2 stm32常见挂死现场CFSR值为0x00008200时查BFAR游戏跑着跑着进了HardFault_Handler不要乱猜“是不是中断优先级配错了”。在调试器里看SCB-CFSR如果是0x00008200这个值可以拆成两部分0x8000对应BFARVALID0x0200对应PRECISERR。翻译成人话就是发生了精确总线错误而且出错的地址已经记录在SCB-BFAR寄存器里。在HardFault_Handler里加这样的代码把现场信息存下来void HardFault_Handler(void) { volatile uint32_t cfsr SCB-CFSR; volatile uint32_t bfar SCB-BFAR; __asm(bkpt #0); while (1); }cfsr用来确认是否还是0x00008200bfar指向具体访问失败的地址去代码里查那个地址是谁基本两分钟就能定位。用ST-Link Utility连接目标时也能在寄存器窗口直接读到这两个值不用单步执行。这种精确总线错误最常见的原因是把sprite数组下标写越界例如障碍物x坐标减到负数后还拿去索引fb[cx][page]cx变成负值后在C语言里被隐式转换成了很大的无符号数。另一个高频挂死点是“delay卡死”症状是程序停在HAL_Delay里出不来。原因多半是在定时器中断里调用了HAL_Delay而它依赖SysTick同等级或更高优先级中断会阻塞SysTick的tick计数延时时间翻倍直到卡死。小恐龙游戏里我把TIM2中断只置标志位主循环处理逻辑就是为了彻底避开这个问题。5.3 按住跳跃的时间也做成参数手感靠数据不靠玄学原版小恐龙有一个很重要的操作细节按住跳跃键时起跳上升段会被“充值”松开后立即下落。这个手感用参数描述很清晰按住期间每帧附加一点上升量最多持续12帧。#define JUMP_HOLD_MAX 12 static uint8_t jumpHoldFrames 0; void UpdateDinoWithHold(uint8_t isKeyPressed) { if (!isJumping isKeyPressed) { isJumping 1; dinoVY JUMP_VY; jumpHoldFrames 0; } if (isJumping) { dinoVY GRAVITY; dinoY dinoVY; if (isKeyPressed jumpHoldFrames JUMP_HOLD_MAX) { dinoY - 1; jumpHoldFrames; } if (dinoY GROUND_Y) { dinoY GROUND_Y; dinoVY 0; isJumping 0; } } }标定这个参数时我习惯把起跳初速和按住上升量分开调先把JUMP_HOLD_MAX设成0确定基础跳跃高度保证单次按键能越过最小仙人掌再逐步增加按住帧数直到测试者觉得“长按能越过连续大障碍短按又不会跳太高”。这两个值共同影响跳跃曲线别在游戏运行中动态修改GRAVITY不然跳跃弧线会突变完全没法玩。本文还有配套的精品资源点击获取