2026/9/1 15:07:32
FEATURED · 精选文章 
简介本资源是一套基于STM32F103C8T6最小系统板实现的智能公交报站系统完整嵌入式源码面向嵌入式初学者、STM32课程设计学生及物联网应用开发爱好者解决公交场景下自动定位、语音播报与站名显示等核心功能的软硬件协同实现问题。压缩包共107个文件含47个头文件.h用于外设与模块接口定义、42个C源文件.c涵盖主控逻辑、USART/GPIO/ADC/TIM等标准外设驱动、GPS坐标解析、TTS语音触发及公交线路数据结构管理另有Keil工程配置.uvprojx/.uvoptx、调试配置.dbgconf、构建脚本.bat等辅助文件整体体积仅349KB轻量易部署。目前已有173人学习下载代码结构清晰模块划分合理包含从硬件初始化、中断调度到语音合成联动的全链路实现特别适合用于嵌入式系统综合实训、课程设计参考或毕业设计原型开发。 做这个智能公交报站系统之前我先说一个可能让很多人意外的事实公交车上那句“下一站XXX”背后的逻辑远没有想象中复杂。真正决定它好不好用的不是云端、不是大数据而是GPS坐标点、一站点坐标表、一个判断进站/出站的算法以及一套能稳定播报的外设而这些东西用一块几十块钱的STM32F103C8T6最小系统板完全能搞定。我这次拆解的是一个在STM32F103C8T6最小系统板上实现的智能公交报站系统源码包。它解决的痛点是传统公交车报站靠司机按按钮经常出现漏报、误报、到站不报的情况而一套完整的商用报站器又太贵很多开源爱好者、课设学生、小团队做公交线路演示时缺一套能自己修改、能看懂、能跑通的方案。这个项目把GPS定位、站点数据库、语音播报、LCD显示串成了一条完整链路做成一个独立的嵌入式系统适合有STM32基础但没做过GPS项目的人也适合想要把GNS S定位真正用起来的人参考。下面我按项目从需求拆解、硬件选型、软件算法到源码解析、实车测试的顺序把它掰开揉碎讲清楚。你会看到哪些模块是必需的哪些是锦上添花的以及在真实跑线路时最容易踩的坑在哪里。1. 项目概述为什么要自己写一个公交报站系统1.1 公交报站系统的真实需求拆解做任何项目第一步不是打开Keil写代码而是把“报站”这件事翻译成嵌入式系统能理解的输入输出需求。公交车报站本质上是一个有限状态机车辆在线路上运行车上的人需要在合适的时间听到“下一站是XX”“XX站到了”这样的语音提示同时车外的人或司机需要看到当前站点信息。拆成具体功能点大概是这几条第一系统要能知道公交车当前在什么位置这个信息来自GPS模块它输出的经纬度坐标是后续所有判断的基础第二系统要有一份“线路站点表”也就是一趟公交线路从起点到终点每个站点的名称和坐标第三系统要能自动判断公交车和站点之间的关系即是否接近某个站点、是否已经到达、是否已经离站这决定了什么时候播报“即将到站”和“到了”第四系统要把判断结果通过语音、屏幕等方式反馈出来第五因为公交车是沿固定线路走的系统还要处理GPS漂移、信号丢失、司机临时掉头等异常情况。这个源码包的核心亮点在于它没有用上位机或者手机参与全部判断都在STM32F103C8T6上完成。也就是说这块最小系统板既是定位数据的接收者也是报站逻辑的运算者还是语音播报和显示的控制者。这种“离线嵌入式”方案的好处很明显不依赖网络、开机就能用、启动快、成本低而且源码完全在自己的手里改成其他线路只要换站点表即可。1.2 为什么选STM32F103C8T6最小系统板我在选型时就一个原则能用便宜、资料多、引脚够用的芯片就不要上复杂平台。STM32F103C8T6是Cortex-M3内核主频72MHz64KB Flash20KB RAM虽然放在今天算不上高性能但对GPS数据解析、Haversine公式计算、语音播报控制这种轻量级任务来说性能绰绰有余。关键它还便宜一块最小系统板在电子市场十几块到二十几块就能拿到而且买家基本都帮你把晶振、复位电路、USB转串口、稳压电路集成好了接上ST-Link就能下载调试。你可能要问用ESP32或者树莓派Pico不是更方便吗ESP32确实有WiFi但在这类离线场景里反而多余树莓派Pico性能也很好但很多新手最熟悉的还是STM32标准库和Keil环境。再加上STM32F103C8T6的资料密度大到惊人搜索“STM32F103C8T6最小系统板”能出来几万条教程遇到问题基本都能找到答案。所以从学习成本、调试便利性、扩展空间三个角度看这个板子是这套系统最稳妥的底座。1.3 源码包内的总体架构说明这个源码包解压之后结构不是那种随手写一两个main.c的玩具工程而是分成了几个清晰的层级。底层是标准外设库或者HAL库的驱动代码负责GPIO、USART、定时器、看门狗这些基础配置中间层是GPS模块的NMEA协议解析、语音模块的串口指令封装、OLED屏幕的显示驱动上层则是业务逻辑包括站点表定义、距离计算函数、进站/出站状态机、播报触发条件判断。我拿到源码包后第一个动作就是看主循环。这里的主循环不是那种一个while(1)里从头跑到尾的傻循环而是一个有限状态机状态包括“行驶中”“接近站点”“到站停车”“离站中”几个阶段。每个阶段里只做必要的事情比如“接近站点”时反复计算与当前目标站点的距离一旦小于阈值就触发到站播报然后切换到“到站停车”状态离站后继续向下一个站点匹配。这套逻辑的好处是稳定、可预测而且每一个状态都可以单独调试。2. 硬件设计与选型最小系统板之外还需要什么2.1 外设清单与接口分配先把我实际使用的硬件清单列出来都是很容易买到的模块模块型号或规格作用与STM32的接口主控板STM32F103C8T6最小系统板核心逻辑与控制核心GPS模块ATGM336H兼容NEO-6M定位、输出经纬度USART1波特率9600语音模块SYN6288中文语音合成播报USART2波特率9600OLED屏幕0.96寸 SSD1306I2C接口显示当前站、下一站I2C1按键轻触按键x3手动切换/调试GPIO输入蜂鸣器有源蜂鸣器到站提示音GPIO输出LED普通LED x2状态指示GPIO输出接口分配的思路是GPS数据是持续不断输入的高频数据占用一个独立串口最好不要和调试打印串口混用否则抓数据时会互相干扰语音模块是输出设备占用另一个串口通过串口指令进行文本播报OLED屏幕用I2C两根线就能驱动不额外占用太多引脚按键和LED则分配到剩下的GPIO上。这里有个很重要的细节STM32F103C8T6有多个USARTUSART1默认在PA9/PA10USART2在PA2/PA3USART3在PB10/PB11。我建议GPS接USART1因为GPS模块用9600波特率连续输出USART1支持DMA方便做不定长接收语音模块接USART2发送指令用轮询发送就够了不需要太高频率调试串口如果需要可以用USART3这样三个串口各司其职。2.2 GPS模块选型与天线注意事项GPS模块市面上最常见的两种NEO-6M和ATGM336H。NEO-6M是老牌资料多搜星能力中等ATGM336H是国产芯片价格更低功耗也更低而且支持北斗GPS双模搜星数量明显优于单纯的NEO-6M在城市高架桥下表现会好一些。我实际选的是ATGM336H因为它输出的NMEA语句和NEO-6M格式完全一样源码里解析逻辑通用但定位速度和稳定度都有提升。如果你要自己复刻这个项目我强烈建议注意天线的摆放。GPS模块背面通常有一个陶瓷天线焊盘有些模块还会带一个有源天线接口。陶瓷天线的方向性很强必须朝向天空而且最好放在金属外壳外面或者靠近窗户的位置。我在调试时踩过一个坑把GPS模块直接贴在开发板下面结果在室内完全搜不到星后来把天线用延长线引到窗边冷启动一分钟内就定位成功了。这个问题的本质是GPS信号是1575.42MHz的微弱微波信号金属遮挡和电磁干扰都会严重影响接收。另外GPS模块的串口输出默认是NMEA 0183协议每秒输出一次定位数据包含GGA、RMC、GSV等若干条语句。这里要注意的是系统判断“是否定位成功”不能只看串口有没有数据而要看RMC语句的状态位是不是‘A’。模块上电后即使没定位也会输出数据只是状态位是‘V’如果忽略这个标志系统会把北纬0度、东经0度当成真实位置报站逻辑就会彻底乱套。2.3 语音播报模块选择SYN6288还是DFPlayer公交报站要的是中文语音而且内容动态可变比如“欢迎乘坐1路公交车本车开往火车站方向”。可选方案大致有三类一是用SYN6288这种中文TTS语音合成模块直接把文字通过串口发给它它就能读出中文二是用DFPlayer Mini这种MP3播放模块把每个站点的报站语音提前录制好成MP3文件放到TF卡里通过序号播放三是用WT588F这类语音芯片把语音固件烧录进去再触发播放。这个项目里选的是SYN6288。原因是报站内容不是固定的那一两句而是要动态拼接站名比如“下一站人民广场”如果用MP3方案有多少个站就要录多少段音频扩展性太差。而SYN6288只要发送GBK编码的文本指令就能读出任意中文文本站点表里存站名就行改线路只需要改文本不需要重新录音。当然SYN6288也有脾气它对电源纹波敏感用同一个5V电源同时给GPS和语音模块供电时如果电源质量不好播报时会有明显的电流声。我后来把语音模块的电源和单片机电源之间加了一个100uF电解电容和0.1uF陶瓷电容并联滤波情况明显改善。另外SYN6288串口通信的格式是固定的帧头FD、数据长度、命令字、参数然后才是GBK编码的文本内容。发送时需要注意计算长度字节多一个少一个都会导致模块不响应。2.4 供电与电平匹配中的几个坑STM32F103C8T6最小系统板的供电一般是5V USB口输入板载稳压到3.3V给芯片。GPS模块和语音模块多数也是3.3V供电有些GPS模块的VCC标称3.3V到5V都能用。但如果你用5V给GPS模块供电它的串口输出电平可能是5VSTM32的引脚容忍5V输入的话勉强能读但如果不确定最好还是统一3.3V供电避免长期高压输入损伤引脚。另一个容易被忽略的问题是模块之间的“地”。GPS模块、语音模块、STM32之间如果用了不同的电源一定要共地否则串口通信会出现乱码甚至完全收不到数据。这种问题不是代码能排查出来的硬件层面必须先保证所有模块的GND连在一起。还有一点有源蜂鸣器工作时会拉低电源电压尤其在播报瞬间和蜂鸣器同时动作时瞬时电流可能把MCU电压拉到复位阈值以下导致系统自动重启。解决办法是蜂鸣器不要直接接在单片机引脚上而是通过一个三极管或者MOS管驱动电源端再并一个大的储能电容。很多新手做这类项目习惯把所有模块的正负极直接并联到面包板电源条上这在静态调试时没问题但一到播报蜂鸣器OLED同时工作的峰值电流场景就会出各种诡异问题。3. 软件设计报站逻辑的三大核心算法3.1 经纬度距离计算Haversine公式的STM32实现报站系统要判断公交车离站点还有多远核心就是计算两个经纬度坐标之间的距离。地球是一个近似球体不能把经纬度直接当平面直角坐标来算否则在纬度较高地区误差会非常大。工程上最常用的是Haversine公式它根据球面上两点经纬度计算大圆距离精度足够满足报站需求。Haversine公式是这样的a sin²(Δlat/2) cos(lat1) * cos(lat2) * sin²(Δlon/2) c 2 * atan2(√a, √(1-a)) distance R * c其中R取地球平均半径6371km。在STM32上实现时需要注意单片机里没有math库的浮点运算单元STM32F103是Cortex-M3不带FPU所有浮点运算都由软件模拟速度虽然不算快但一次Haversine计算在72MHz主频下也就几十微秒完全不影响实时性。如果你希望更快可以把角度转弧度的系数提前算好把每次调用的常数计算省掉。下面是我在这个项目里实际使用的C代码#include math.h #define PI 3.14159265358979f #define EARTH_RADIUS 6371000.0f static float deg2rad(float deg) { return deg * PI / 180.0f; } float calc_distance(float lat1, float lon1, float lat2, float lon2) { float rad_lat1 deg2rad(lat1); float rad_lat2 deg2rad(lat2); float d_lat rad_lat2 - rad_lat1; float d_lon deg2rad(lon2) - deg2rad(lon1); float a sinf(d_lat / 2.0f) * sinf(d_lat / 2.0f) cosf(rad_lat1) * cosf(rad_lat2) * sinf(d_lon / 2.0f) * sinf(d_lon / 2.0f); float c 2.0f * atan2f(sqrtf(a), sqrtf(1.0f - a)); return EARTH_RADIUS * c; }这个函数在代码里会高频调用因为每秒钟GPS定位一次系统要计算当前位置和当前目标站点的距离。注意我用了sinf、cosf、atan2f这些浮点函数它们在链接时来自libm库Keil工程里默认是支持的不需要额外添加文件。3.2 进站判断距离阈值方向过滤避免乱报有了距离函数还不够如果只判断“距离小于30米就报进站”会出现一个很尴尬的情况公交车在站台旁边等红灯或者靠边起步时距离一直在阈值内波动系统可能反复播报“到了”。更麻烦的是GPS漂移可能让车辆在离站台还有40米的时候瞬间跳动到30米内造成误报。我用的方案是“距离阈值方向过滤出站迟滞”。进站判定条件有两个第一当前点与本站点距离小于进站阈值比如30米第二车辆行驶方向与进站方向一致也就是距离变化率是减小的判断的方法是看本次距离是否小于上一次的距离。同时满足才认为正在进站进入“接近状态”。到站播报触发后系统不会立刻切到下一个站点而是要等车辆驶离当前站点并继续前进一段距离。出站判定是“距离大于出站阈值”且“当前目标站点已经切换为下一站”。这里用了个迟滞设计进站阈值是30米出站阈值是60米这样就不会在边界反复横跳。方向过滤的另一种实现是使用GPS的航向角输出。NMEA语句中的RMC语句会输出地面航向角范围0到359.9度。你可以把每个站点设置一个“入站方向”字段比如由北向南进站的站点航向角应该在180度左右允许偏差30度如果车辆航向角和站点入站方向相差超过60度即使距离很近也不触发播报。这个方案在单行线或固定线路上非常好用但线路复杂时标定方向角比较费劲我建议以距离变化率的方案为主方向角作为辅助判据。3.3 站点顺序管理与越站补偿公交线路是固定顺序的站点表不能只存坐标还要考虑车辆可能在任意站点启动。这个源码包里用了一个“当前目标站点索引”变量来记录车辆下一个要报的站点。系统启动时从第一个站点开始车辆每经过一个站索引加一直到终点站后清零实现循环线路。但真实公交车不是总能按顺序走到终点司机可能因为调度中途掉头或者因为修路临时越站。单纯按索引递增来处理肯定会报错。我在项目里加了一个“越站补偿”逻辑每次判断距离最近的站点在站点表中的索引如果“当前目标站点索引”和“最近站点索引”相差1以上就把当前目标站点索引更新为最近站点的下一个。比如当前目标是第5站结果检测到车辆已经在第8站旁边了就会跳到第9站继续报站而不是傻傻地报第5站。这个逻辑在实车上很重要。有一次测试司机在中间站点临时拐进调度站掉头系统没有乱报而是快速重新计算了最近的站点然后继续按新的位置顺序播报。如果你做的是单向线路演示不做越站补偿其实也没问题但作为一套要真正能用的系统这部分的容错思路值得抄一份。4. 工程代码结构与关键源码解析4.1 Keil工程目录与文件职责源码包的Keil工程结构大致是这样的Project/ ├── User/ │ ├── main.c // 主函数、状态机入口 │ ├── stm32f10x_it.c // 中断服务函数 │ └── system_stm32f10x.c ├── Core/ │ ├── gpio.c │ ├── usart.c │ ├── i2c.c │ ├── timer.c │ └── delay.c ├── Driver/ │ ├── gps.c // GPS NMEA解析 │ ├── voice.c // SYN6288驱动 │ ├── oled.c // OLED显示 │ ├── key.c │ ├── buzzer.c │ └── station.c // 站点表与报站逻辑 ├── Middleware/ │ ├── ringbuffer.c // 串口环形缓冲区 │ └── calc_distance.c // 距离计算 ├── Hardware/ │ ├── stm32f10x_conf.h │ └── stm32f10x.h └── Listing/ / Objects/如果你用的是标准外设库建议不要把ST官方的库文件改得面目全非只把需要的usart、gpio、timer等源文件加进工程即可。这个项目的工程是基于标准库的为什么不用HAL库因为在这种外设简单的项目里标准库的代码量更少逻辑更直白对新手来说查寄存器也方便。当然新版CubeMX生成的HAL库也能做只是工程会多出一堆初始化和回调函数对理解核心算法反而形成干扰。4.2 GPS数据解析从NMEA到坐标GPS模块输出的是充满逗号的ASCII字符串例如$GNRMC,081712.00,A,3103.24345,N,12122.85251,E,0.04,0.00,,,*5A这条语句里的关键字段是时间、状态A有效/V无效、纬度、北纬/南纬、经度、东经/西经、速度、航向角。注意NMEA输出的纬度格式是“度分”格式3103.24345不是31.0324345度而是31度03.24345分。解析时必须做转换度取整数部分的前两位分取余下部分除以60然后相加得到十进制度数。我写了一个很小的解析函数只提取RMC语句需要的字段int parse_rmc(char *buf, GPS_Info *gps) { int field_index 0; char *p buf; char *field[14]; if (strncmp(buf 3, RMC, 3) ! 0) { return 0; } field[field_index] p; while (*p field_index 14) { if (*p ,) { *p \0; field[field_index] p 1; } p; } if (strlen(field[1]) 0 || field[2][0] ! A) { return 0; } gps-status 1; gps-lat convert_nmea(field[3], field[4][0]); gps-lon convert_nmea(field[5], field[6][0]); gps-speed atof(field[7]); gps-course atof(field[8]); return 1; }这个函数的核心是字符串切分和字段提取在嵌入式环境下不要用strtok这种会修改原字符串本身的库函数自己遍历逗号更可控。另外为了接收不丢数据GPS串口建议开启串口接收中断把数据压进一个环形缓冲区主循环或者定时器里再丢给解析函数处理。直接在主循环里阻塞式等待串口接收是很容易丢帧的因为GPS每秒输出多条语句任何一条处理时间过长都会影响下一条数据接收。4.3 语音播报驱动与串口DMA发送SYN6288的串口指令格式是帧头FD 数据长度包含命令字、参数、文本但不包含帧头和数据长度本身 命令字01 参数00 文本内容。发送“下一站人民广场”之前需要先把这个字符串转成GBK编码。如果你在Keil里直接写中文字符串字面量源文件编码必须是GB2312或GBK否则STM32发送出去的UTF-8编码SYN6288不认识会播报乱码。语音播报的驱动非常简单核心是拼帧并发送#define SYN6288_FRAME_HEAD 0xFD void voice_play_text(const char *text) { uint16_t len strlen(text) 2; // 命令字 参数 uart2_send_byte(SYN6288_FRAME_HEAD); uart2_send_byte((len 8) 0xFF); uart2_send_byte(len 0xFF); uart2_send_byte(0x01); // 合成播放命令 uart2_send_byte(0x00); // 编码格式GBK while (*text) { uart2_send_byte((uint8_t)(*text)); } }由于STM32F103C8T6没有FPU我们在语音播报的同时还要继续接收GPS数据如果串口发送也用阻塞轮询可能会拖慢主循环。实际操作中语音播报属于低频操作每次只有几十字节用阻塞发送完全够用不需要DMA。反倒是GPS接收需要DMA或中断如果你在语音播报时发现GPS数据丢了优先检查中断优先级和主循环中的延时。OLED屏幕驱动这里不多展开SSD1306是一个很经典的单色屏I2C接口只需要写一个初始化函数和一个显示字符串函数。在这个项目里OLED的作用是显示“当前站”“下一站”和“卫星数”信息量不大用标准库的I2C轮询方式就能稳定工作。4.4 主循环状态机的实现这部分是整个源码包最核心的代码逻辑。我用一个枚举类型来表示系统状态typedef enum { STATE_DRIVING, // 行驶中未接近任何站点 STATE_APPROACHING, // 接近目标站点已播报“即将到站” STATE_ARRIVED, // 已到站已播报“XX站到了” STATE_LEAVING // 离站中等待进入下一站范围 } BusState;主循环的伪代码如下while (1) { if (gps_updated) { gps_updated 0; current_distance calc_distance( gps.lat, gps.lon, station_table[next_station_index].lat, station_table[next_station_index].lon); switch (bus_state) { case STATE_DRIVING: if (current_distance APPROACH_THRESHOLD) { voice_play_text(station_table[next_station_index].approach_msg); bus_state STATE_APPROACHING; } break; case STATE_APPROACHING: if (current_distance ARRIVE_THRESHOLD) { voice_play_text(station_table[next_station_index].arrive_msg); oled_show_station(next_station_index); bus_state STATE_ARRIVED; } break; case STATE_ARRIVED: if (current_distance ARRIVE_THRESHOLD HYSTERESIS) { bus_state STATE_LEAVING; } break; case STATE_LEAVING: if (current_distance LEAVE_THRESHOLD next_station_index 1 station_count) { next_station_index; bus_state STATE_DRIVING; } break; } } }其中APPROACH_THRESHOLD表示“距站点多少米开始报下一站”ARRIVE_THRESHOLD表示“距站点多少米算到站”HYSTERESIS是迟滞量LEAVE_THRESHOLD是离站后切换下一个目标站点需要的距离。这些参数必须根据GPS精度和站点间距调整后面调试部分我会详细说。不要小看这个状态机。它把连续变化的GPS坐标离散成了几个稳定状态每次状态切换都有明确的触发条件和播报动作排查问题的时候只需要看当前处于哪个状态大大降低调试难度。5. 调参与测试实车效果是磨出来的5.1 串口调试助手抓GPS数据的实测源码写完之后不要直接上车。先把GPS模块放在窗边用USB转TTL接电脑打开串口助手波特率9600观察NMEA语句。确认以下几点RMC语句的状态字段是否为A纬度经度是否符合你所在城市的实际位置移动模块几十米后坐标有没有跟随变化在窗户边搜到的卫星数是多少。如果串口助手上一片空白先排查接线GPS模块的TXD要接STM32的RXDGPS的RXD接STM32的TXD交叉接。很多新手把同向接线导致收不到数据。如果使用USB转TTL直接接GPS模块测试还要注意模块的TX要接USB转TTL的RX。实测时我会在程序里留一个调试开关把解析出来的经纬度、状态、距离值通过USART3打印到电脑上。这样上车之后不需要额外的显示设备只靠串口助手就能实时观察系统判断是否正常。比如输出OK lat31.23042 lon121.47362 dist45.3m stateDRIVING OK lat31.23049 lon121.47370 dist32.1m stateAPPROACHING这个日志格式非常有效每个问题都能按时间序列回放。如果你不在意调试打印拖慢系统建议保留这个功能直到测试结束。5.2 距离阈值怎么标定距离阈值不是拍脑袋定的要按实际GPS精度来。民用GPS在城市环境下的水平定位精度大概是3到10米静态漂移有时能达到15米。如果进站阈值设成10米很可能车明明停在站台上系统却一直认为还没到如果设成50米可能离站还有一两个车位就播报了。我的标定方法是在站点中心位置实地站着等GPS数据稳定记录当前位置计算的站点距离连续记录一分钟得到最小值和最大值。然后取最大值的1.5到2倍作为进站阈值。比如站点附近GPS波动最大时距离显示25米进站阈值就设40米左右这样既能保证车辆进站前提示又不会因为普通路过的GPS抖动误触发。出站阈值一般设为进站阈值的2倍比如进站阈值40米出站阈值80米。实测下来站台长度一般不超过30米公交车停在站内距离应该小于40米出站后向前开60到80米距离站台中心点就超过80米了正好切到下一站。5.3 常见问题与排查技巧实录下面这些问题都是我实际调试过程中遇到过的整理成速查表方便你按图索骥现象可能原因排查方向串口收到GPS数据但都是乱码波特率不对或GND不共地确认GPS波特率9600检查共地一直显示定位无效V天线朝向不好、室内遮挡把模块移到窗边或车外重新冷启动车辆未到站但提前播报进站阈值太大重新标定阈值缩小范围到站后重复播报出站未切状态GPS抖动增加迟滞量检查状态机切换语音模块播报乱码源文件编码不是GBKKeil里把源文件编码改为GB2312语音播报时GPS数据丢失阻塞发送时间过长改用中断/DMA接收GPS或降低语音发送频率系统启动后反复重启蜂鸣器/语音模块拉低电源独立驱动蜂鸣器完善电源滤波OLED不亮I2C地址错误或接线错SSD1306默认地址0x3C或0x3D确认模块还有一个很容易被忽略的问题部分GPS模块上电后需要几秒到一两分钟才能冷启动定位如果系统上电后立刻开机播报“欢迎乘坐”而GPS还没定位成功报站逻辑会先把无效坐标当成真实位置。所以主程序里必须加一个“等待GPS有效定位后再开始报站”的逻辑。最简单的方式是初始化时检查GPS状态无效时OLED显示“正在定位”同时阻塞循环直到状态有效如果需要快速启动也可以直接播报欢迎词但报站逻辑要等GPS有效后再开启。6. 项目扩展与后续思路6.1 从单线到多线路站点表如何组织这个源码包默认只有一条线路的站点表但代码结构上已经把站点表独立成了一个station.c文件想扩成多线路并不难。线路表可以设计成二维数组或者结构体数组每个线路包含线路名称、站点数、站点指针报站时先选择线路再根据线路内的站点表跑状态机。我建议把站点表的坐标尽量规划整理好。比如设计一个结构体typedef struct { uint8_t id; char name[32]; float lat; float lon; char approach_msg[64]; char arrive_msg[64]; } StationInfo;然后把线路数据放到一个单独的数组中。注意闪存容量只有64KB一个汉字UTF-8是3字节GBK是2字节如果站点很多文字信息会占用不少空间。用标准库时数组默认放在Flash里不会耗RAM但启动时如果有拷贝操作要注意RAM占用。6.2 加入OLED显示与按键交互OLED在这个项目里完全可以做得更花哨一些比如显示线路图、显示当前站点序号、显示距离下一站的剩余米数。如果你想增加可玩性还可以用按键来手动切换线路或站点这在没有GPS信号的地下车库测试时非常有用。按键处理需要注意防抖。STM32主循环跑得很快直接用读取GPIO的方式判断按键按下会出现抖动导致一次按下被当成多次。主流做法是用定时器每10毫秒扫描一次按键连续读到两次稳定电平才确认有效或者用外部中断加延时消抖。对于这种低频操作简单地在按键检测函数里加一个10到20毫秒的delay再确认电平也够用了。6.3 还可以加的功能如果你想把项目升级到真正可用的级别可以做这几件事第一加入Flash存储把上下行线路、站点偏移等参数保存在Flash里断电不丢失第二加入ADC采集车载电源电压当电压过低时提醒司机第三加入LCD1602或更大尺寸的LCD屏让后排乘客也能看到下一站信息第四把GPS数据和报站日志通过蓝牙模块发送到手机App方便运营分析。不过加功能前要先想清楚STM32F103C8T6的64KB Flash和20KB RAM是有限的代码越多调试越难。最好的做法是先把基础报站功能做到稳定再逐步添加次要功能。每加一个功能都要回归测试一次从起点到终点的完整线路确保GPS定位、语音播报、状态切换不会因为新代码而受影响。我在实际调试这个项目时最深的一个体会是嵌入式项目的问题十有八九不是“代码不会写”而是“现象没看懂”。GPS数据看上去收到了但没解析对距离算出来了但阈值不合适语音能播报了但电源一抖就断。只有把每个环节的中间数据都能看到、能回放你才会有底气说这套系统是稳定的。这也是我反复建议在串口日志里打印经纬度和状态的原因。如果你照着这个源码包做遇到问题不要急着改代码先把日志打开从GPS解析开始一层层往上排查所有奇怪的现象最后都能落到一个具体的错误原因上。这套排查思路比代码本身更有价值也是你从“改例子”走向“做项目”最关键的一步。本文还有配套的精品资源点击获取
基于STM32的GPS智能公交报站系统：从原理到实车调试
简介本资源是一套基于STM32F103C8T6最小系统板实现的智能公交报站系统完整嵌入式源码面向嵌入式初学者、STM32课程设计学生及物联网应用开发爱好者解决公交场景下自动定位、语音播报与站名显示等核心功能的软硬件协同实现问题。压缩包共107个文件含47个头文件.h用于外设与模块接口定义、42个C源文件.c涵盖主控逻辑、USART/GPIO/ADC/TIM等标准外设驱动、GPS坐标解析、TTS语音触发及公交线路数据结构管理另有Keil工程配置.uvprojx/.uvoptx、调试配置.dbgconf、构建脚本.bat等辅助文件整体体积仅349KB轻量易部署。目前已有173人学习下载代码结构清晰模块划分合理包含从硬件初始化、中断调度到语音合成联动的全链路实现特别适合用于嵌入式系统综合实训、课程设计参考或毕业设计原型开发。 做这个智能公交报站系统之前我先说一个可能让很多人意外的事实公交车上那句“下一站XXX”背后的逻辑远没有想象中复杂。真正决定它好不好用的不是云端、不是大数据而是GPS坐标点、一站点坐标表、一个判断进站/出站的算法以及一套能稳定播报的外设而这些东西用一块几十块钱的STM32F103C8T6最小系统板完全能搞定。我这次拆解的是一个在STM32F103C8T6最小系统板上实现的智能公交报站系统源码包。它解决的痛点是传统公交车报站靠司机按按钮经常出现漏报、误报、到站不报的情况而一套完整的商用报站器又太贵很多开源爱好者、课设学生、小团队做公交线路演示时缺一套能自己修改、能看懂、能跑通的方案。这个项目把GPS定位、站点数据库、语音播报、LCD显示串成了一条完整链路做成一个独立的嵌入式系统适合有STM32基础但没做过GPS项目的人也适合想要把GNS S定位真正用起来的人参考。下面我按项目从需求拆解、硬件选型、软件算法到源码解析、实车测试的顺序把它掰开揉碎讲清楚。你会看到哪些模块是必需的哪些是锦上添花的以及在真实跑线路时最容易踩的坑在哪里。1. 项目概述为什么要自己写一个公交报站系统1.1 公交报站系统的真实需求拆解做任何项目第一步不是打开Keil写代码而是把“报站”这件事翻译成嵌入式系统能理解的输入输出需求。公交车报站本质上是一个有限状态机车辆在线路上运行车上的人需要在合适的时间听到“下一站是XX”“XX站到了”这样的语音提示同时车外的人或司机需要看到当前站点信息。拆成具体功能点大概是这几条第一系统要能知道公交车当前在什么位置这个信息来自GPS模块它输出的经纬度坐标是后续所有判断的基础第二系统要有一份“线路站点表”也就是一趟公交线路从起点到终点每个站点的名称和坐标第三系统要能自动判断公交车和站点之间的关系即是否接近某个站点、是否已经到达、是否已经离站这决定了什么时候播报“即将到站”和“到了”第四系统要把判断结果通过语音、屏幕等方式反馈出来第五因为公交车是沿固定线路走的系统还要处理GPS漂移、信号丢失、司机临时掉头等异常情况。这个源码包的核心亮点在于它没有用上位机或者手机参与全部判断都在STM32F103C8T6上完成。也就是说这块最小系统板既是定位数据的接收者也是报站逻辑的运算者还是语音播报和显示的控制者。这种“离线嵌入式”方案的好处很明显不依赖网络、开机就能用、启动快、成本低而且源码完全在自己的手里改成其他线路只要换站点表即可。1.2 为什么选STM32F103C8T6最小系统板我在选型时就一个原则能用便宜、资料多、引脚够用的芯片就不要上复杂平台。STM32F103C8T6是Cortex-M3内核主频72MHz64KB Flash20KB RAM虽然放在今天算不上高性能但对GPS数据解析、Haversine公式计算、语音播报控制这种轻量级任务来说性能绰绰有余。关键它还便宜一块最小系统板在电子市场十几块到二十几块就能拿到而且买家基本都帮你把晶振、复位电路、USB转串口、稳压电路集成好了接上ST-Link就能下载调试。你可能要问用ESP32或者树莓派Pico不是更方便吗ESP32确实有WiFi但在这类离线场景里反而多余树莓派Pico性能也很好但很多新手最熟悉的还是STM32标准库和Keil环境。再加上STM32F103C8T6的资料密度大到惊人搜索“STM32F103C8T6最小系统板”能出来几万条教程遇到问题基本都能找到答案。所以从学习成本、调试便利性、扩展空间三个角度看这个板子是这套系统最稳妥的底座。1.3 源码包内的总体架构说明这个源码包解压之后结构不是那种随手写一两个main.c的玩具工程而是分成了几个清晰的层级。底层是标准外设库或者HAL库的驱动代码负责GPIO、USART、定时器、看门狗这些基础配置中间层是GPS模块的NMEA协议解析、语音模块的串口指令封装、OLED屏幕的显示驱动上层则是业务逻辑包括站点表定义、距离计算函数、进站/出站状态机、播报触发条件判断。我拿到源码包后第一个动作就是看主循环。这里的主循环不是那种一个while(1)里从头跑到尾的傻循环而是一个有限状态机状态包括“行驶中”“接近站点”“到站停车”“离站中”几个阶段。每个阶段里只做必要的事情比如“接近站点”时反复计算与当前目标站点的距离一旦小于阈值就触发到站播报然后切换到“到站停车”状态离站后继续向下一个站点匹配。这套逻辑的好处是稳定、可预测而且每一个状态都可以单独调试。2. 硬件设计与选型最小系统板之外还需要什么2.1 外设清单与接口分配先把我实际使用的硬件清单列出来都是很容易买到的模块模块型号或规格作用与STM32的接口主控板STM32F103C8T6最小系统板核心逻辑与控制核心GPS模块ATGM336H兼容NEO-6M定位、输出经纬度USART1波特率9600语音模块SYN6288中文语音合成播报USART2波特率9600OLED屏幕0.96寸 SSD1306I2C接口显示当前站、下一站I2C1按键轻触按键x3手动切换/调试GPIO输入蜂鸣器有源蜂鸣器到站提示音GPIO输出LED普通LED x2状态指示GPIO输出接口分配的思路是GPS数据是持续不断输入的高频数据占用一个独立串口最好不要和调试打印串口混用否则抓数据时会互相干扰语音模块是输出设备占用另一个串口通过串口指令进行文本播报OLED屏幕用I2C两根线就能驱动不额外占用太多引脚按键和LED则分配到剩下的GPIO上。这里有个很重要的细节STM32F103C8T6有多个USARTUSART1默认在PA9/PA10USART2在PA2/PA3USART3在PB10/PB11。我建议GPS接USART1因为GPS模块用9600波特率连续输出USART1支持DMA方便做不定长接收语音模块接USART2发送指令用轮询发送就够了不需要太高频率调试串口如果需要可以用USART3这样三个串口各司其职。2.2 GPS模块选型与天线注意事项GPS模块市面上最常见的两种NEO-6M和ATGM336H。NEO-6M是老牌资料多搜星能力中等ATGM336H是国产芯片价格更低功耗也更低而且支持北斗GPS双模搜星数量明显优于单纯的NEO-6M在城市高架桥下表现会好一些。我实际选的是ATGM336H因为它输出的NMEA语句和NEO-6M格式完全一样源码里解析逻辑通用但定位速度和稳定度都有提升。如果你要自己复刻这个项目我强烈建议注意天线的摆放。GPS模块背面通常有一个陶瓷天线焊盘有些模块还会带一个有源天线接口。陶瓷天线的方向性很强必须朝向天空而且最好放在金属外壳外面或者靠近窗户的位置。我在调试时踩过一个坑把GPS模块直接贴在开发板下面结果在室内完全搜不到星后来把天线用延长线引到窗边冷启动一分钟内就定位成功了。这个问题的本质是GPS信号是1575.42MHz的微弱微波信号金属遮挡和电磁干扰都会严重影响接收。另外GPS模块的串口输出默认是NMEA 0183协议每秒输出一次定位数据包含GGA、RMC、GSV等若干条语句。这里要注意的是系统判断“是否定位成功”不能只看串口有没有数据而要看RMC语句的状态位是不是‘A’。模块上电后即使没定位也会输出数据只是状态位是‘V’如果忽略这个标志系统会把北纬0度、东经0度当成真实位置报站逻辑就会彻底乱套。2.3 语音播报模块选择SYN6288还是DFPlayer公交报站要的是中文语音而且内容动态可变比如“欢迎乘坐1路公交车本车开往火车站方向”。可选方案大致有三类一是用SYN6288这种中文TTS语音合成模块直接把文字通过串口发给它它就能读出中文二是用DFPlayer Mini这种MP3播放模块把每个站点的报站语音提前录制好成MP3文件放到TF卡里通过序号播放三是用WT588F这类语音芯片把语音固件烧录进去再触发播放。这个项目里选的是SYN6288。原因是报站内容不是固定的那一两句而是要动态拼接站名比如“下一站人民广场”如果用MP3方案有多少个站就要录多少段音频扩展性太差。而SYN6288只要发送GBK编码的文本指令就能读出任意中文文本站点表里存站名就行改线路只需要改文本不需要重新录音。当然SYN6288也有脾气它对电源纹波敏感用同一个5V电源同时给GPS和语音模块供电时如果电源质量不好播报时会有明显的电流声。我后来把语音模块的电源和单片机电源之间加了一个100uF电解电容和0.1uF陶瓷电容并联滤波情况明显改善。另外SYN6288串口通信的格式是固定的帧头FD、数据长度、命令字、参数然后才是GBK编码的文本内容。发送时需要注意计算长度字节多一个少一个都会导致模块不响应。2.4 供电与电平匹配中的几个坑STM32F103C8T6最小系统板的供电一般是5V USB口输入板载稳压到3.3V给芯片。GPS模块和语音模块多数也是3.3V供电有些GPS模块的VCC标称3.3V到5V都能用。但如果你用5V给GPS模块供电它的串口输出电平可能是5VSTM32的引脚容忍5V输入的话勉强能读但如果不确定最好还是统一3.3V供电避免长期高压输入损伤引脚。另一个容易被忽略的问题是模块之间的“地”。GPS模块、语音模块、STM32之间如果用了不同的电源一定要共地否则串口通信会出现乱码甚至完全收不到数据。这种问题不是代码能排查出来的硬件层面必须先保证所有模块的GND连在一起。还有一点有源蜂鸣器工作时会拉低电源电压尤其在播报瞬间和蜂鸣器同时动作时瞬时电流可能把MCU电压拉到复位阈值以下导致系统自动重启。解决办法是蜂鸣器不要直接接在单片机引脚上而是通过一个三极管或者MOS管驱动电源端再并一个大的储能电容。很多新手做这类项目习惯把所有模块的正负极直接并联到面包板电源条上这在静态调试时没问题但一到播报蜂鸣器OLED同时工作的峰值电流场景就会出各种诡异问题。3. 软件设计报站逻辑的三大核心算法3.1 经纬度距离计算Haversine公式的STM32实现报站系统要判断公交车离站点还有多远核心就是计算两个经纬度坐标之间的距离。地球是一个近似球体不能把经纬度直接当平面直角坐标来算否则在纬度较高地区误差会非常大。工程上最常用的是Haversine公式它根据球面上两点经纬度计算大圆距离精度足够满足报站需求。Haversine公式是这样的a sin²(Δlat/2) cos(lat1) * cos(lat2) * sin²(Δlon/2) c 2 * atan2(√a, √(1-a)) distance R * c其中R取地球平均半径6371km。在STM32上实现时需要注意单片机里没有math库的浮点运算单元STM32F103是Cortex-M3不带FPU所有浮点运算都由软件模拟速度虽然不算快但一次Haversine计算在72MHz主频下也就几十微秒完全不影响实时性。如果你希望更快可以把角度转弧度的系数提前算好把每次调用的常数计算省掉。下面是我在这个项目里实际使用的C代码#include math.h #define PI 3.14159265358979f #define EARTH_RADIUS 6371000.0f static float deg2rad(float deg) { return deg * PI / 180.0f; } float calc_distance(float lat1, float lon1, float lat2, float lon2) { float rad_lat1 deg2rad(lat1); float rad_lat2 deg2rad(lat2); float d_lat rad_lat2 - rad_lat1; float d_lon deg2rad(lon2) - deg2rad(lon1); float a sinf(d_lat / 2.0f) * sinf(d_lat / 2.0f) cosf(rad_lat1) * cosf(rad_lat2) * sinf(d_lon / 2.0f) * sinf(d_lon / 2.0f); float c 2.0f * atan2f(sqrtf(a), sqrtf(1.0f - a)); return EARTH_RADIUS * c; }这个函数在代码里会高频调用因为每秒钟GPS定位一次系统要计算当前位置和当前目标站点的距离。注意我用了sinf、cosf、atan2f这些浮点函数它们在链接时来自libm库Keil工程里默认是支持的不需要额外添加文件。3.2 进站判断距离阈值方向过滤避免乱报有了距离函数还不够如果只判断“距离小于30米就报进站”会出现一个很尴尬的情况公交车在站台旁边等红灯或者靠边起步时距离一直在阈值内波动系统可能反复播报“到了”。更麻烦的是GPS漂移可能让车辆在离站台还有40米的时候瞬间跳动到30米内造成误报。我用的方案是“距离阈值方向过滤出站迟滞”。进站判定条件有两个第一当前点与本站点距离小于进站阈值比如30米第二车辆行驶方向与进站方向一致也就是距离变化率是减小的判断的方法是看本次距离是否小于上一次的距离。同时满足才认为正在进站进入“接近状态”。到站播报触发后系统不会立刻切到下一个站点而是要等车辆驶离当前站点并继续前进一段距离。出站判定是“距离大于出站阈值”且“当前目标站点已经切换为下一站”。这里用了个迟滞设计进站阈值是30米出站阈值是60米这样就不会在边界反复横跳。方向过滤的另一种实现是使用GPS的航向角输出。NMEA语句中的RMC语句会输出地面航向角范围0到359.9度。你可以把每个站点设置一个“入站方向”字段比如由北向南进站的站点航向角应该在180度左右允许偏差30度如果车辆航向角和站点入站方向相差超过60度即使距离很近也不触发播报。这个方案在单行线或固定线路上非常好用但线路复杂时标定方向角比较费劲我建议以距离变化率的方案为主方向角作为辅助判据。3.3 站点顺序管理与越站补偿公交线路是固定顺序的站点表不能只存坐标还要考虑车辆可能在任意站点启动。这个源码包里用了一个“当前目标站点索引”变量来记录车辆下一个要报的站点。系统启动时从第一个站点开始车辆每经过一个站索引加一直到终点站后清零实现循环线路。但真实公交车不是总能按顺序走到终点司机可能因为调度中途掉头或者因为修路临时越站。单纯按索引递增来处理肯定会报错。我在项目里加了一个“越站补偿”逻辑每次判断距离最近的站点在站点表中的索引如果“当前目标站点索引”和“最近站点索引”相差1以上就把当前目标站点索引更新为最近站点的下一个。比如当前目标是第5站结果检测到车辆已经在第8站旁边了就会跳到第9站继续报站而不是傻傻地报第5站。这个逻辑在实车上很重要。有一次测试司机在中间站点临时拐进调度站掉头系统没有乱报而是快速重新计算了最近的站点然后继续按新的位置顺序播报。如果你做的是单向线路演示不做越站补偿其实也没问题但作为一套要真正能用的系统这部分的容错思路值得抄一份。4. 工程代码结构与关键源码解析4.1 Keil工程目录与文件职责源码包的Keil工程结构大致是这样的Project/ ├── User/ │ ├── main.c // 主函数、状态机入口 │ ├── stm32f10x_it.c // 中断服务函数 │ └── system_stm32f10x.c ├── Core/ │ ├── gpio.c │ ├── usart.c │ ├── i2c.c │ ├── timer.c │ └── delay.c ├── Driver/ │ ├── gps.c // GPS NMEA解析 │ ├── voice.c // SYN6288驱动 │ ├── oled.c // OLED显示 │ ├── key.c │ ├── buzzer.c │ └── station.c // 站点表与报站逻辑 ├── Middleware/ │ ├── ringbuffer.c // 串口环形缓冲区 │ └── calc_distance.c // 距离计算 ├── Hardware/ │ ├── stm32f10x_conf.h │ └── stm32f10x.h └── Listing/ / Objects/如果你用的是标准外设库建议不要把ST官方的库文件改得面目全非只把需要的usart、gpio、timer等源文件加进工程即可。这个项目的工程是基于标准库的为什么不用HAL库因为在这种外设简单的项目里标准库的代码量更少逻辑更直白对新手来说查寄存器也方便。当然新版CubeMX生成的HAL库也能做只是工程会多出一堆初始化和回调函数对理解核心算法反而形成干扰。4.2 GPS数据解析从NMEA到坐标GPS模块输出的是充满逗号的ASCII字符串例如$GNRMC,081712.00,A,3103.24345,N,12122.85251,E,0.04,0.00,,,*5A这条语句里的关键字段是时间、状态A有效/V无效、纬度、北纬/南纬、经度、东经/西经、速度、航向角。注意NMEA输出的纬度格式是“度分”格式3103.24345不是31.0324345度而是31度03.24345分。解析时必须做转换度取整数部分的前两位分取余下部分除以60然后相加得到十进制度数。我写了一个很小的解析函数只提取RMC语句需要的字段int parse_rmc(char *buf, GPS_Info *gps) { int field_index 0; char *p buf; char *field[14]; if (strncmp(buf 3, RMC, 3) ! 0) { return 0; } field[field_index] p; while (*p field_index 14) { if (*p ,) { *p \0; field[field_index] p 1; } p; } if (strlen(field[1]) 0 || field[2][0] ! A) { return 0; } gps-status 1; gps-lat convert_nmea(field[3], field[4][0]); gps-lon convert_nmea(field[5], field[6][0]); gps-speed atof(field[7]); gps-course atof(field[8]); return 1; }这个函数的核心是字符串切分和字段提取在嵌入式环境下不要用strtok这种会修改原字符串本身的库函数自己遍历逗号更可控。另外为了接收不丢数据GPS串口建议开启串口接收中断把数据压进一个环形缓冲区主循环或者定时器里再丢给解析函数处理。直接在主循环里阻塞式等待串口接收是很容易丢帧的因为GPS每秒输出多条语句任何一条处理时间过长都会影响下一条数据接收。4.3 语音播报驱动与串口DMA发送SYN6288的串口指令格式是帧头FD 数据长度包含命令字、参数、文本但不包含帧头和数据长度本身 命令字01 参数00 文本内容。发送“下一站人民广场”之前需要先把这个字符串转成GBK编码。如果你在Keil里直接写中文字符串字面量源文件编码必须是GB2312或GBK否则STM32发送出去的UTF-8编码SYN6288不认识会播报乱码。语音播报的驱动非常简单核心是拼帧并发送#define SYN6288_FRAME_HEAD 0xFD void voice_play_text(const char *text) { uint16_t len strlen(text) 2; // 命令字 参数 uart2_send_byte(SYN6288_FRAME_HEAD); uart2_send_byte((len 8) 0xFF); uart2_send_byte(len 0xFF); uart2_send_byte(0x01); // 合成播放命令 uart2_send_byte(0x00); // 编码格式GBK while (*text) { uart2_send_byte((uint8_t)(*text)); } }由于STM32F103C8T6没有FPU我们在语音播报的同时还要继续接收GPS数据如果串口发送也用阻塞轮询可能会拖慢主循环。实际操作中语音播报属于低频操作每次只有几十字节用阻塞发送完全够用不需要DMA。反倒是GPS接收需要DMA或中断如果你在语音播报时发现GPS数据丢了优先检查中断优先级和主循环中的延时。OLED屏幕驱动这里不多展开SSD1306是一个很经典的单色屏I2C接口只需要写一个初始化函数和一个显示字符串函数。在这个项目里OLED的作用是显示“当前站”“下一站”和“卫星数”信息量不大用标准库的I2C轮询方式就能稳定工作。4.4 主循环状态机的实现这部分是整个源码包最核心的代码逻辑。我用一个枚举类型来表示系统状态typedef enum { STATE_DRIVING, // 行驶中未接近任何站点 STATE_APPROACHING, // 接近目标站点已播报“即将到站” STATE_ARRIVED, // 已到站已播报“XX站到了” STATE_LEAVING // 离站中等待进入下一站范围 } BusState;主循环的伪代码如下while (1) { if (gps_updated) { gps_updated 0; current_distance calc_distance( gps.lat, gps.lon, station_table[next_station_index].lat, station_table[next_station_index].lon); switch (bus_state) { case STATE_DRIVING: if (current_distance APPROACH_THRESHOLD) { voice_play_text(station_table[next_station_index].approach_msg); bus_state STATE_APPROACHING; } break; case STATE_APPROACHING: if (current_distance ARRIVE_THRESHOLD) { voice_play_text(station_table[next_station_index].arrive_msg); oled_show_station(next_station_index); bus_state STATE_ARRIVED; } break; case STATE_ARRIVED: if (current_distance ARRIVE_THRESHOLD HYSTERESIS) { bus_state STATE_LEAVING; } break; case STATE_LEAVING: if (current_distance LEAVE_THRESHOLD next_station_index 1 station_count) { next_station_index; bus_state STATE_DRIVING; } break; } } }其中APPROACH_THRESHOLD表示“距站点多少米开始报下一站”ARRIVE_THRESHOLD表示“距站点多少米算到站”HYSTERESIS是迟滞量LEAVE_THRESHOLD是离站后切换下一个目标站点需要的距离。这些参数必须根据GPS精度和站点间距调整后面调试部分我会详细说。不要小看这个状态机。它把连续变化的GPS坐标离散成了几个稳定状态每次状态切换都有明确的触发条件和播报动作排查问题的时候只需要看当前处于哪个状态大大降低调试难度。5. 调参与测试实车效果是磨出来的5.1 串口调试助手抓GPS数据的实测源码写完之后不要直接上车。先把GPS模块放在窗边用USB转TTL接电脑打开串口助手波特率9600观察NMEA语句。确认以下几点RMC语句的状态字段是否为A纬度经度是否符合你所在城市的实际位置移动模块几十米后坐标有没有跟随变化在窗户边搜到的卫星数是多少。如果串口助手上一片空白先排查接线GPS模块的TXD要接STM32的RXDGPS的RXD接STM32的TXD交叉接。很多新手把同向接线导致收不到数据。如果使用USB转TTL直接接GPS模块测试还要注意模块的TX要接USB转TTL的RX。实测时我会在程序里留一个调试开关把解析出来的经纬度、状态、距离值通过USART3打印到电脑上。这样上车之后不需要额外的显示设备只靠串口助手就能实时观察系统判断是否正常。比如输出OK lat31.23042 lon121.47362 dist45.3m stateDRIVING OK lat31.23049 lon121.47370 dist32.1m stateAPPROACHING这个日志格式非常有效每个问题都能按时间序列回放。如果你不在意调试打印拖慢系统建议保留这个功能直到测试结束。5.2 距离阈值怎么标定距离阈值不是拍脑袋定的要按实际GPS精度来。民用GPS在城市环境下的水平定位精度大概是3到10米静态漂移有时能达到15米。如果进站阈值设成10米很可能车明明停在站台上系统却一直认为还没到如果设成50米可能离站还有一两个车位就播报了。我的标定方法是在站点中心位置实地站着等GPS数据稳定记录当前位置计算的站点距离连续记录一分钟得到最小值和最大值。然后取最大值的1.5到2倍作为进站阈值。比如站点附近GPS波动最大时距离显示25米进站阈值就设40米左右这样既能保证车辆进站前提示又不会因为普通路过的GPS抖动误触发。出站阈值一般设为进站阈值的2倍比如进站阈值40米出站阈值80米。实测下来站台长度一般不超过30米公交车停在站内距离应该小于40米出站后向前开60到80米距离站台中心点就超过80米了正好切到下一站。5.3 常见问题与排查技巧实录下面这些问题都是我实际调试过程中遇到过的整理成速查表方便你按图索骥现象可能原因排查方向串口收到GPS数据但都是乱码波特率不对或GND不共地确认GPS波特率9600检查共地一直显示定位无效V天线朝向不好、室内遮挡把模块移到窗边或车外重新冷启动车辆未到站但提前播报进站阈值太大重新标定阈值缩小范围到站后重复播报出站未切状态GPS抖动增加迟滞量检查状态机切换语音模块播报乱码源文件编码不是GBKKeil里把源文件编码改为GB2312语音播报时GPS数据丢失阻塞发送时间过长改用中断/DMA接收GPS或降低语音发送频率系统启动后反复重启蜂鸣器/语音模块拉低电源独立驱动蜂鸣器完善电源滤波OLED不亮I2C地址错误或接线错SSD1306默认地址0x3C或0x3D确认模块还有一个很容易被忽略的问题部分GPS模块上电后需要几秒到一两分钟才能冷启动定位如果系统上电后立刻开机播报“欢迎乘坐”而GPS还没定位成功报站逻辑会先把无效坐标当成真实位置。所以主程序里必须加一个“等待GPS有效定位后再开始报站”的逻辑。最简单的方式是初始化时检查GPS状态无效时OLED显示“正在定位”同时阻塞循环直到状态有效如果需要快速启动也可以直接播报欢迎词但报站逻辑要等GPS有效后再开启。6. 项目扩展与后续思路6.1 从单线到多线路站点表如何组织这个源码包默认只有一条线路的站点表但代码结构上已经把站点表独立成了一个station.c文件想扩成多线路并不难。线路表可以设计成二维数组或者结构体数组每个线路包含线路名称、站点数、站点指针报站时先选择线路再根据线路内的站点表跑状态机。我建议把站点表的坐标尽量规划整理好。比如设计一个结构体typedef struct { uint8_t id; char name[32]; float lat; float lon; char approach_msg[64]; char arrive_msg[64]; } StationInfo;然后把线路数据放到一个单独的数组中。注意闪存容量只有64KB一个汉字UTF-8是3字节GBK是2字节如果站点很多文字信息会占用不少空间。用标准库时数组默认放在Flash里不会耗RAM但启动时如果有拷贝操作要注意RAM占用。6.2 加入OLED显示与按键交互OLED在这个项目里完全可以做得更花哨一些比如显示线路图、显示当前站点序号、显示距离下一站的剩余米数。如果你想增加可玩性还可以用按键来手动切换线路或站点这在没有GPS信号的地下车库测试时非常有用。按键处理需要注意防抖。STM32主循环跑得很快直接用读取GPIO的方式判断按键按下会出现抖动导致一次按下被当成多次。主流做法是用定时器每10毫秒扫描一次按键连续读到两次稳定电平才确认有效或者用外部中断加延时消抖。对于这种低频操作简单地在按键检测函数里加一个10到20毫秒的delay再确认电平也够用了。6.3 还可以加的功能如果你想把项目升级到真正可用的级别可以做这几件事第一加入Flash存储把上下行线路、站点偏移等参数保存在Flash里断电不丢失第二加入ADC采集车载电源电压当电压过低时提醒司机第三加入LCD1602或更大尺寸的LCD屏让后排乘客也能看到下一站信息第四把GPS数据和报站日志通过蓝牙模块发送到手机App方便运营分析。不过加功能前要先想清楚STM32F103C8T6的64KB Flash和20KB RAM是有限的代码越多调试越难。最好的做法是先把基础报站功能做到稳定再逐步添加次要功能。每加一个功能都要回归测试一次从起点到终点的完整线路确保GPS定位、语音播报、状态切换不会因为新代码而受影响。我在实际调试这个项目时最深的一个体会是嵌入式项目的问题十有八九不是“代码不会写”而是“现象没看懂”。GPS数据看上去收到了但没解析对距离算出来了但阈值不合适语音能播报了但电源一抖就断。只有把每个环节的中间数据都能看到、能回放你才会有底气说这套系统是稳定的。这也是我反复建议在串口日志里打印经纬度和状态的原因。如果你照着这个源码包做遇到问题不要急着改代码先把日志打开从GPS解析开始一层层往上排查所有奇怪的现象最后都能落到一个具体的错误原因上。这套排查思路比代码本身更有价值也是你从“改例子”走向“做项目”最关键的一步。本文还有配套的精品资源点击获取 
