简介基于STM32F407的贪吃蛇游戏完整工程面向嵌入式开发初学者与进阶用户用于掌握MCU外设驱动与实时逻辑控制。工程涵盖蛇身移动、碰撞检测、食物随机生成等核心算法结合定时器中断实现帧率控制、GPIO驱动LCD显示、按键中断更新游戏状态并演示从CubeMX配置到Keil MDK编译下载的完整路径。资源共159个文件以77个h头文件与75个c源文件为主涵盖标准外设库和游戏逻辑代码另有Keil工程文件、hex烧录文件及编译批处理压缩包仅831KB结构清晰便于查阅。已有2820人学习下载适合希望深入理解STM32F407中断系统、定时器、显示驱动和C语言算法设计的开发者可直接移植或二次扩展游戏功能。1. 用STM32F407跑贪吃蛇看起来是入门题做起来是外设体检用STM32F407做一套贪吃蛇游戏程序听起来像是入门练手题但真把代码写下来你会发现游戏逻辑只占三成剩下的全是驱动、定时、按键消抖和显示刷新这些“脏活”。这份资源的价值不在于蛇跑得多快而是它把一块F407芯片的I2C、GPIO、定时器和中断全部串在了一个能玩能改的闭环里——手柄按下去屏幕上的蛇头得在几十毫秒内给出反应中间任何一个环节掉链子游戏就玩不成。适合谁手里有F407核心板、想从“点亮LED”进阶到“完整小产品”的新手或者想找个外设调用样板来二次开发的工程师。我拆完这套代码之后最大的感受是它真正值得抄的不是贪吃蛇而是“输入-逻辑-显示”三层怎么在一个裸机工程里不互相拖后腿。2. 技术选型与工程骨架先决定每个外设该干什么2.1 外设分配显示走I2C按键走GPIO定时器管节奏拆这套代码的第一步是看它把外设挂在哪。F407的资源对贪吃蛇来说相当浪费但正因为资源多选哪组外设就变成了一道“组合题”。我在最常见的一种方案里看到的分工是这样的外设用途常见挂载点说明I2C1驱动0.96寸OLEDSSD1306PB6SCL、PB7SDA128x64分辨率4线I2C帧率足够GPIOA四个方向按键PA0、PA1、PA2、PA3上拉输入低电平有效TIM21ms时基中断内部时钟负责按键消抖和游戏速度计时USART1调试日志PA9TX、PA10RX115200-8-N-1只在调试时用这套选型最合理的地方在于把“慢外设”和“快逻辑”隔开了。OLED刷新一帧128x64的页面在I2C上大约要几毫秒如果把它塞进定时器中断里做主循环会被拖死所以代码里显示刷新放在主循环定时器只负责置一个“该动一格了”的标志位。按键呢理论上可以用外部中断但四路中断加上消抖反而容易互相打扰轮询加1ms消抖更稳——这算是这类小游戏一个反直觉的点中断用得越少程序越不容易翻车。引脚冲突也是拆这套代码时要留意的。F407的PB6/PB7默认就能复用为I2C1但如果开发板上这两个引脚同时还接了其他外设那就需要换到I2C2PB10/PB11。拆的时候我会先去板子的原理图里确认引脚有没有被占用这一步没做后面白屏排查会绕很远。2.2 工程目录驱动层、逻辑层、应用层各管一摊这套工程的结构没有走花哨的分层就是经典的裸机三层。树形目录大致长这样SnakeGame/ ├── Core/ │ ├── Inc/ │ │ ├── main.h │ │ ├── tim.h │ │ └── gpio.h │ └── Src/ │ ├── main.c │ ├── tim.c │ └── gpio.c ├── Drivers/ │ ├── BSP/ │ │ ├── oled.c │ │ ├── oled.h │ │ ├── key.c │ │ └── key.h │ └── Middleware/ │ ├── snake.c │ ├── snake.h │ ├── game.c │ └── game.h └── Project/ ├── SnakeGame.ioc └── SnakeGame.uvprojxCore目录是CubeMX生成的负责时钟、GPIO、定时器初始化这部分一般不做大改动。BSP层是板级驱动oled.c封装了SSD1306的初始化、清屏、画点、画方块key.c负责扫描按键并做消抖。Middleware层就是游戏本体snake.c管蛇身数据和移动算法game.c管游戏状态、食物生成和碰撞判定。我比较认可这种分法的原因是它把“会变的”和“不会变的”拆开了。显示屏从OLED换成TFT只需要重写BSP里的oled.c游戏逻辑一个字节都不用动想改成双人模式在Middleware层加代码就行。新手容易犯的错是把画点函数直接写进游戏逻辑里到处调用结果换个屏幕等于重写整个游戏——这套工程没有这个问题可读性在线。2.3 CubeMX初始化从时钟到引脚的固话配置拆这套代码时最关键的三块初始化分别是时钟树、I2C参数和按键GPIO。F407的最高主频是168MHzCubeMX里配置PLL即可这不是性能瓶颈但需要注意APB1总线上的定时器时钟默认是84MHzTIM2做1ms时基时要按84MHz去计算预分频值。按键的GPIO配置在CubeMX生成的文件里长这样void MX_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitStruct.Pin KEY_UP_Pin | KEY_DOWN_Pin | KEY_LEFT_Pin | KEY_RIGHT_Pin; GPIO_InitStruct.Mode GPIO_MODE_INPUT; GPIO_InitStruct.Pull GPIO_PULLUP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); }这里有个细节值得多说一句按键一端接地、另一端接GPIO所以内部要配置成上拉。代码里GPIO_PULLUP就是干这个的如果选成下拉按键松开时读到的是低电平按下反而变高逻辑就全反了。速度配LOW就够按键信号本身变化极慢不需要高速翻转。我一般会建议在PA0到PA3上各串一个1kΩ电阻不是必须但能在接线抖动时减少GPIO口的电流冲击。I2C的初始化则是在i2c.c里主要参数是时钟频率设为400kHzFast Mode地址长度7位。SSD1306的I2C从机地址通常是0x3C或0x3D取决于屏的地址引脚焊接情况这一位错了后面显示就是白屏。初始化代码是CubeMX生成的不需要手写时序但需要理解HAL的I2C发送是“先发控制字节再发数据字节”的OLED驱动里封装的就是这套流程。3. 核心代码拆解蛇头走一步背后发生了什么3.1 蛇身数据结构单向链表比数组更适合“变长”拆到游戏本体时第一个要看的模块是蛇身的数据结构。比较老的写法喜欢用二维数组但数组的长度定死就意味着最大蛇长被写死而且每次移动要把整段身体搬一遍。这套工程用的是单向链表每个节点存一个坐标和下一个节点的指针typedef struct SnakeNode { uint8_t x; // 横坐标范围 0~15 uint8_t y; // 纵坐标范围 0~7 struct SnakeNode *next; // 指向下一节身体 } SnakeNode; typedef struct { SnakeNode *head; // 蛇头节点 SnakeNode *tail; // 蛇尾节点 uint8_t length; // 当前长度 uint8_t dir; // 当前方向0上 1下 2左 3右 uint8_t dir_locked; // 方向锁防止同一次按键里连续变向 } Snake;链表的好处是移动时只需要操作头尾两个节点中间的身体完全不用动。游戏区域被划分成16x8的网格每格在屏幕上占8x8像素正好映射128x64的OLED这个设计是经过计算的OLED宽度128像素除以8得16列高度64像素除以8得8行网格坐标直接乘以8就是像素坐标连除法都不用做。3.2 移动逻辑头插尾删吃到食物就“高抬贵手”蛇的移动是整个程序里最核心的函数叫snake_move。每次由定时器标志触发一次核心逻辑是两步按当前方向算出新头坐标然后判断该不该删除尾节点void snake_move(Snake *snake, uint8_t ate_food) { SnakeNode *new_head (SnakeNode *)malloc(sizeof(SnakeNode)); uint8_t new_x snake-head-x; uint8_t new_y snake-head-y; switch (snake-dir) { case DIR_UP: new_y--; break; case DIR_DOWN: new_y; break; case DIR_LEFT: new_x--; break; case DIR_RIGHT: new_x; break; } new_head-x new_x; new_head-y new_y; new_head-next snake-head; snake-head new_head; if (!ate_food) { SnakeNode *old_tail snake-tail; snake-tail old_tail-next; free(old_tail); } else { snake-length; } }这段代码的精髓在“头插尾删”四个字。没吃到食物时新节点插到头部同时尾巴砍掉一个蛇的长度不变整体往前挪一格吃到食物时只插头不删尾长度加一。这里用了动态内存分配F407有192KB的SRAM贪吃蛇最多192个节点也才占用几KB完全没有压力但要注意单片机上的malloc记得在初始化时调用系统的堆设置CubeMX默认会开堆大小在启动文件里可以调。这里还有个细节新头的坐标计算完一定要在插入之前先做碰撞检测。如果先插进去再检测撞墙时蛇头已经在墙外了回退的逻辑会很别扭。我拆到的这份代码里碰撞检测和蛇移动是分开的两个函数判断通过后才调用snake_move顺序上更安全。3.3 碰撞判定撞墙、撞自己、吃食物三类分支碰撞检测是game模块的主逻辑它把三类结果一次性算清楚返回一个枚举值给主循环typedef enum { GAME_RUNNING 0, GAME_OVER_WALL, GAME_OVER_SELF, GAME_ATE_FOOD } GameResult; GameResult game_check_collision(Snake *snake, Food *food) { uint8_t new_x snake-head-x; uint8_t new_y snake-head-y; // 按下一次方向后的预测位置 switch (snake-dir) { case DIR_UP: new_y--; break; case DIR_DOWN: new_y; break; case DIR_LEFT: new_x--; break; case DIR_RIGHT: new_x; break; } // 撞墙判定网格边界 0~15, 0~7 if (new_x 15 || new_y 7) { return GAME_OVER_WALL; } // 撞自己判定预测位置与身体任意节点重合 SnakeNode *curr snake-head; while (curr ! NULL) { if (curr-x new_x curr-y new_y) { return GAME_OVER_SELF; } curr curr-next; } // 吃食物判定 if (new_x food-x new_y food-y) { return GAME_ATE_FOOD; } return GAME_RUNNING; }这段代码有两个容易忽略的参数细节。第一个是坐标范围游戏区是16x8也就是说x坐标合法值只有0到15y坐标只有0到7判断要写成15和7很多新手写成结果蛇永远走不到最右一格看起来就像屏幕右边有一条看不见的墙。第二个是“撞自己”的遍历顺序从head开始逐个比对这里要特别小心一个边界情况——蛇头原本的位置要不要算我的经验是不要算否则蛇刚把尾巴甩开的那一帧会被误判成撞到自己导致游戏莫名结束。食物生成函数实现相对简单用随机数在空位上生成坐标。常见的做法是用rand()取模16和8如果随机出来的位置正好占着蛇身就重新生成最多尝试20次。需要提醒的是裸机工程里rand()没有自动播种我一般会用系统运行时间计数器的低几位做种子否则每次上电食物落在同一批位置游戏体验会板结。3.4 方向控制方向锁是防“一点就反向”的命门按键处理是这套代码里看起来最“没用”却最容易翻车的部分。表面逻辑很简单扫描四个按键有键按下就更新蛇的方向。但如果不在更新前加判断会出现一个经典的BUG——蛇向右走时玩家快速按了两下方向键先按上再按左结果蛇在一帧之内连续转向直接掉头撞进自己身体。解法就是代码里的dir_locked标志void game_handle_key(Snake *snake) { if (key_scan() KEY_NONE) { snake-dir_locked 0; // 没有按键时解锁 return; } if (snake-dir_locked) { return; // 同一帧内已经处理过方向忽略后续按键 } uint8_t new_dir key_get_direction(); // 禁止反向当前向右时不能直接按左 if ((snake-dir DIR_RIGHT new_dir DIR_LEFT) || (snake-dir DIR_LEFT new_dir DIR_RIGHT) || (snake-dir DIR_UP new_dir DIR_DOWN) || (snake-dir DIR_DOWN new_dir DIR_UP)) { return; } snake-dir new_dir; snake-dir_locked 1; }这个标志的语义是“每帧只接受一次方向输入”。按键扫描函数返回KEY_NONE时解锁让下一帧可以接受新方向有按键时如果已经锁住就直接丢弃阻止同帧内的二次变向。但如果你的游戏体验里感觉转向响应慢问题也出在这里——方向锁把按键响应频率限制成了每移动一格一次这是有意为之。另一个细节在key_scan里。按键是低电平有效逻辑是HAL_GPIO_ReadPin(GPIOA, key_pin) GPIO_PIN_RESET判断按下。消抖用1ms定时器累计连续读到20次低电平才算有效这能滤掉按键的机械抖动。如果消抖时间太短按键会出现“串键”——按下一次触发两次方向变化蛇会瞬移一格消抖太长则会影响手感20ms是这类游戏比较舒服的经验值。4. 运行避坑与排查白屏、串键、变速三座山4.1 烧录与启动先让程序真正跑起来编译烧录这部分我只提一个关键顺序先确认调试器连接再上电。用SWD调试器接F407的SWDIO、SWCLK、GND三个引脚部分板子还要接VCC供参考电压。打开工程后先编译如果报错先看是不是芯片型号选错了——F407家族有多个型号Flash容量不一选错型号会导致下载校验失败。下载成功后按复位键如果程序没反应优先检查BOOT0引脚是否接低电平BOOT0被拉高的话芯片会进入BootLoader用户程序根本不会执行。烧录成功的标志不只是“下载完成”弹窗而是屏幕上有画面。如果板子和程序都正常上电后OLED会先显示一帧静态的“Snake Game”标题。此时不要急着玩先按几个按键看方向是否与预期一致这一步能快速暴露接线错误。4.2 避坑记录一OLED白屏先从I2C地址查起现象程序烧录成功复位后OLED没有任何显示背光亮但不显示内容。原因排查路径最常见的是I2C地址不对。SSD1306的I2C地址受DC引脚电平影响通常是0x3C地址引脚接地或0x3D地址引脚接高。F407的HAL库用的是7位地址左移一位的写法有人把0x3C直接传给HAL_I2C_Mem_Write结果地址变成0x78正好错位。解决在初始化代码里写一个I2C扫描函数遍历0x60到0x80之间的地址调用HAL_I2C_IsDeviceReady打印出有ACK的设备地址。我每次拆这类显示驱动都会先跑一遍扫描确认地址后再改宏定义for (uint16_t addr 0x60; addr 0x80; addr 2) { if (HAL_I2C_IsDeviceReady(hi2c1, addr, 2, 50) HAL_OK) { printf(OLED found at 0x%02X\r\n, addr); } }如果扫描后什么地址都没有那问题就不在地址而在硬件连接检查SCL和SDA是否接反、板上是否已经接了上拉电阻、杜邦线是否松动。这是玄学高发区我曾经因为一根杜邦线接触不良排查了一整天才发现是物理连接问题。4.3 避坑记录二按键串键与方向瞬变现象按下一次方向键蛇连续拐了两个弯或者按左时蛇直接反向撞死。原因串键的根源多半是消抖时间不足。按键是机械结构按下瞬间会有几毫秒的抖动如果每1ms采样一次且立即生效一次按下会被识别成多次。方向瞬变则是没加方向锁两帧之间的间隙里按键被扫描了多次蛇在同一帧内连续响应了两次转向。解决把消抖时间调整到20ms到30ms之间同时保证方向锁代码生效。更好的做法是在按键状态变化时记录一个“上次稳定状态”只有状态从释放变为按下且保持20ms才认定为一次有效按键。处理后如果有按键不灵敏的现象那就是消抖时间过长或GPIO配置成了上拉但按键接地不良把时间调回20ms即可。4.4 避坑记录三蛇移动速度时快时慢现象蛇在刚开局时走得正常吃几个食物之后速度明显变快或者屏幕偶尔会停顿一下再继续。原因这是典型的“用延时函数控制游戏节奏”造成的。如果移动频率是靠HAL_Delay实现的主循环里显示刷新、按键扫描耗时会累加到每次循环里显示刷新越耗时蛇的实际移动间隔越不稳定。F407主频虽然够高但I2C刷新是阻塞式的一帧屏刷掉好几毫秒这些时间全算进了游戏节奏里。解决不要用延时控制移动改用定时器标志位。TIM2每1ms中断一次在中断服务函数里累加计数器主循环里判断计数器是否达到当前速度阈值达到才执行snake_move并清零。这样显示刷新和按键处理的耗时不会影响游戏速度volatile uint16_t g_tick_ms 0; volatile uint8_t g_move_flag 0; void TIM2_IRQHandler(void) { g_tick_ms; if (g_tick_ms speed_threshold) // 速度阈值单位ms { g_move_flag 1; g_tick_ms 0; } HAL_TIM_IRQHandler(htim2); }主循环里只需要判断if (g_move_flag 1)标志置位才执行游戏推进。速度阈值从500ms起步每吃一个食物减20ms最低到100ms这个区间在16x8的网格上既不会快到看不清也不会慢到犯困。5. 二次开发把贪吃蛇改造成你自己的交互框架这层改造思路上限很高我从三个落点讲。第一是速度曲线。现在的速度阈值是统一递减但不同玩家的手速阈值不一样正确的做法是做一个速度档位表用菜单在开局前选择简单档500ms、普通档300ms、困难档120ms。这类改动只在game.c里加一个数组和一次菜单显示完全不动驱动层。第二是显示层抽象。OLED的驱动接口有四条oled_init、oled_clear、oled_draw_pixel、oled_refresh。如果你之后想把屏幕换成TFT或者加一块LCD只需要把BSP层的这四个函数重新实现游戏逻辑调用方完全无感。我一般会再加一层DrawEngine接口让game.c只调用drawRect和drawText而不是直接操作像素这样连中文字库都能在不污染业务代码的情况下加进来。第三是扩展游戏状态。目前的代码只有RUNNING、OVER两个状态加上暂停只需要在按键里加一个PAUSE分支在game_update里跳过移动逻辑即可。复活功能也可以做撞死后等三秒蛇头重新出现在左上角长度重置为3。这些改动全部发生在Middleware层跑起来验证之后你会对“分层设计的好处”有直观感受——改错了一看栈回溯就知道是哪个层的问题。我从这套工程里学到的习惯是每拿到一个板子项目先花半小时把外设全列一张表标记引脚、时钟、电平和通讯速率然后再写一行业务代码。从那以后我每次调试遇到白屏或者串键都强制自己先查这张表而不是直奔代码大部分问题都能在硬件连接层面找到答案。希望帮到你。本文还有配套的精品资源点击获取
