简介这套基于STM32设计的无人超市消费系统资料包包含完整的嵌入式端与Qt上位机源码面向物联网、嵌入式或自动化方向的学生和开发者适合用于课程设计、毕业设计以及无人零售场景的项目参考。系统以STM32为主控配合RC522模块实现RFID会员卡的注册、充值、消费、挂失和余额查询付款成功后由步进电机驱动闸机开门模拟自助收银离店流程。上位机采用C/Qt开发支持商品信息录入与会员管理并通过串口与STM32实时交互。压缩包共150个文件、约22.18MB主要包含STM32的.c/.h源码、Qt工程文件.cpp/.h/.ui、编译好的可执行程序与DLL、Hex固件、原理图PDF以及功能演示图方便对照代码和电路图进行二次开发。目前已有2146人学习浏览是快速理解无人超市消费系统软硬件联调逻辑的实用参考资料。 最近整理移动硬盘翻出一个早几年做的完整项目——《基于STM32设计的无人超市消费系统带配套上位机》。当时是给一个校园创业团队做的原型机用来模拟“扫码进店—自助结账—出门校验”这套无人超市流程。整套系统从STM32下位机、外围硬件驱动到PC端上位机界面、数据库和通信协议全部自己搞定压缩包里是完整工程源码、原理图、上位机安装包和说明文档。如果你正在做嵌入式毕设或者想入门“单片机上位机”这种经典组合这个项目能当很好的参考样板。先大概说下这套系统能干什么。用户进店时刷一下IC卡或扫个二维码STM32控制的电子门打开用户拿商品到自助结算台扫描商品条码或者输入商品编号上位机根据数据库里的价格信息算出总价用户刷卡或扫码支付成功后STM32控制出门闸机放行。整个过程有传感器监测比如红外对管检测是否有人经过称重模块可以做简单的商品数量核对所有交易记录实时同步到上位机数据库里方便后台对账和库存管理。下面我会把这套系统的完整设计思路、硬件选型、上位机开发、通信协议和踩坑经验全部拆开讲清楚篇幅会稍微长一点但每一步都是可以直接“抄作业”的。1. 项目到底解决什么问题无人超市的“收银员”是怎么工作的做项目之前必须先想明白一件事无人超市和普通超市的本质区别不是“没人”而是“收银这个环节被自动化代替”了。所以整套系统的核心不是某个炫酷的硬件而是“人—货—场”之间的数据流转是否通顺。1.1 从实际场景倒推系统需求我当时把无人超市的消费流程拆成了几个环节每个环节都对应一个明确的技术动作进门环节用户身份验证IC卡或二维码验证通过后STM32驱动电磁锁开锁同时上位机记录“某人进入超市”的日志。这里需要上位机与下位机实时通信因为用户信息和开锁权限都存在数据库里单靠单片机做权限管理太吃力。结算环节用户扫描商品条码上位机读数据库返回商品名称和价格界面显示购物清单。这里真正干活的是上位机STM32只负责告诉上位机“条形码扫描枪有数据来了你赶紧处理”。支付环节用户点击“确认支付”上位机与支付模块通信原型机用的是模拟流程实际落地可接微信/支付宝的支付SDK支付成功后下发给STM32一条“允许放行”指令。出门环节STM32控制出门闸机电磁锁打开红外传感器检测到人通过后自动上锁。如果用户没有支付就试图出门系统会触发蜂鸣器报警并在上位机弹窗提示管理员。这样一拆你就明白为什么这个系统必须是“下位机上位机”双端配合。STM32擅长实时控制和传感器读取但做不了复杂的数据存储和人机交互上位机擅长数据库、界面和逻辑处理但管不了硬件引脚。两者通过串口通信配合才是一个完整的闭环。1.2 为什么是STM32上位机这套组合而不是全用手机APP或者纯PLC有人可能会问为什么不直接用手机APP加云服务器现在物联网这么成熟了远程下发指令不就行了答案是成本和开发周期。校园创业团队的原型验证阶段最怕的就是东扯西拉把战线拉太长。STM32PC上位机的好处非常实际开发门槛低资料多。STM32是嵌入式入门的绝对主流Keil开发环境、标准库、HAL库的教程一搜一大把。上位机我用C# WinForms网上同样是海量示例。遇到问题能找到人问这一点在项目开发中太重要了。调试效率高。下位机程序出问题直接ST-LINK仿真看变量上位机逻辑出问题断点调试。两边分开调试比在云服务器上调一个Web应用要直观得多。成本可控。整套硬件下来STM32最小系统板、条码扫描枪、电子锁、红外传感器、称重模块加一起几百块钱对毕设或者创业原型来说非常友好。说到底技术选型没有绝对的对错只有合适不合适。无人超市真正商用当然要上工业级PLC加云端中台但那是后话。做原型验证STM32上位机是性价比最高的路径这也是这个标题的项目能持续被搜到的原因——它门槛适中又有完整业务逻辑非常适合练手。2. 硬件侧的方案选型与电路设计硬件是整套系统的地基。很多初学者在这步容易犯一个错误一上来就画PCB结果原理图没想清楚后面改来改去。我的建议是先用开发板和模块搭出功能原型验证逻辑没问题后再考虑画板子。2.1 STM32型号怎么选F103C8T6就够用别盲目上F4/H7我选的是STM32F103C8T6这是“蓝 pill”板子上的那颗经典芯片48脚64KB Flash20KB RAM。有同学可能会质疑这个配置是不是太低了实际算一下账就清楚了无人超市的下位机需要处理的任务包括读取红外传感器状态、控制电磁锁继电器、接收条码扫描枪的串口数据、与上位机通信、驱动蜂鸣器与指示灯这些任务全部是简单的GPIO操作和串口收发加上一个简单的状态机逻辑连RTOS都用不上裸机轮询就搞定了。这种情况下F103C8T6的算力绰绰有余用F407完全是浪费。跟F103同属一个家族的APM32、GD32等国产替代芯片也提一下。APM32在引脚和寄存器层面基本兼容STM32很多情况下可以直接烧STM32的程序只有部分涉及芯片唯一ID或者特定外设的地方需要改代码。如果你在毕设阶段做实物国产芯片现货更足、价格更低这也是个可以考虑的方向。不过稳妥起见先用正经STM32开发调试完再在成熟产品上换国产芯片别反过来折腾自己。2.2 条形码识别、称重与门锁控制两个“输入”两个“输出”整套系统的外围设备可以分成四类输入设备有两个输出设备有两个。条码扫描枪是输入设备。它本质上是一个串口设备扫码后通过串口发送一串ASCII字符通常是商品条码数字到STM32的USART1。我用的型号是常见的USB接口一体式扫描枪注意它有两种工作模式一种是USB键盘模式相当于把条码当成键盘敲进去另一种是USB转串口模式。必须手动切换到串口模式才能在STM32端收到原始数据。当时调这个切换花了几个小时说明书是纯英文的后来才知道要扫一个特殊的配置码才能切换。称重模块是另一个输入设备。用的是HX711压力传感器模块接一个5kg量程的悬臂梁传感器。这个模块的作用不是精确称重而是做“数量核对”——比如系统里设定某种饮料单瓶重量是350g用户扫码后把商品放到秤上如果称出来的重量在合理误差范围内就认为数量正确。这里要注意HX711的电源纹波问题供电不干净的话读数会漂移我后来在前端加了一个100uF电解电容才稳定下来。电磁锁是输出设备。用的是12V供电的电磁锁STM32的GPIO不能直接驱动必须通过继电器中转。继电器模块用低电平触发也就是GPIO输出低电平时继电器吸合、电磁锁开锁。这里有个很多人栽过的坑STM32刚上电的瞬间GPIO默认状态是浮空输入继电器可能误触发导致门锁突然打开。我的解决办法是在GPIO上加上拉电阻并让初始化代码把控制引脚先拉到高电平高电平继电器不动作然后再初始化外设。蜂鸣器和指示灯是报警输出。蜂鸣器用有源蜂鸣器简单可靠GPIO拉高就响。用于非法开门报警、扫码成功提示音等场景。指示灯用来表示系统状态绿色常亮表示系统正常红色闪烁表示异常。2.3 晶振、电源与通信接口的细节这些容易被忽略的参数决定稳不稳定STM32F103C8T6要用两个晶振8MHz主晶振和32.768kHz的RTC晶振。晶振旁边两个负载电容的取值不是随便选的它要根据晶振的负载电容参数计算。常规做法是选两个20pF的贴片电容如果发现时钟不准再根据实际频率偏差调整。实际项目中我直接用了芯片数据手册推荐的参数没有去精确计算精度完全够用。不过如果你想深究一下晶振电容的计算方法公式是CL (C1 * C2) / (C1 C2) Cstray其中Cstray是PCB走线寄生电容一般取3-5pF然后反推C1和C2的值。这个知识点笔试和面试经常考了解一下不吃亏。供电方案上整个系统外部用12V直流电源供电经过LM2596降压模块转成5V给扫描枪和继电器模块5V再经过AMS1117-3.3转成3.3V给STM32最小系统板和HX711模块。注意一点电磁锁最好独立供电不要和单片机的电源混在一起否则电磁锁动作瞬间的大电流会导致单片机复位。通信接口方面STM32的USART1连接扫描枪USART2连接上位机通过USB转TTL模块如果你串口不够用可以用USART3做备用调试口。还有一个常用手势是板载一个CH340 USB转串口芯片直接把STM32的串口通过USB接到电脑这样既供电又通信开发阶段特别方便。3. 上位机方案选型C#、Qt、Python、LabVIEW到底怎么选上位机是这个项目最容易出彩、也最容易卡住的地方。很多嵌入式方向的同学写单片机代码很溜一到上位机就头皮发麻不知道从哪里下手。这里我把我试过的几种方案都列一下方便你根据自己的基础来选。3.1 不同方案的优缺点对比别被“工具信仰”绑架C#WinForms / WPF是最推荐的入门方案。WinForms学习曲线平缓拖控件就能画界面SerialPort类封装得很好三五行代码就能实现串口收发。而且C#语法和Java非常接近如果你之前学过Java转过来几乎没有障碍。网上有人问“Java转上位机难吗”我负责任地说如果你会Java的Swing或者JavaFX那么C# WinForms你半天就能上手两个生态的编程思维基本是相通的。QtC / Python绑定是跨平台利器界面比WinForms现代适合有C基础的人。缺点是环境配置复杂很多信号槽机制需要一点学习成本。PythonPyQt5 / Tkinter开发速度最快适合做原型验证但打包发布的exe体积大串口实时性也稍逊一筹。LabVIEW是图形化编程工业测试领域用得多做数据采集面板很合适但做业务逻辑比如连接数据库、处理支付状态机非常别扭。GRBL、CAN上位机这种专业工具不在讨论范围内那是特定设备场景下的垂直应用。3.2 我为什么最终选了C# WinForms而不是其他选择理由可以归纳成两句话开发效率高资料多到爆炸。WinForms的串口通信写起来是极其爽快的。你在工具箱里拖一个SerialPort控件设置好串口号和波特率然后订阅DataReceived事件在事件里读取数据、解析数据帧、更新UI整个过程一气呵成。数据库用SQLite或者MySQLC#里都有成熟的ORM框架几行代码就能完成增删改查。如果你是第一次做上位机我强烈建议用WinForms跑通整个流程你会发现原来“上位机开发”并没有想象中那么高不可攀。WPF比WinForms更现代一些界面可以做得很漂亮支持XAML描述UI数据绑定机制也更强大适合做有一定美感的成品。但WPF的学习曲线略陡如果你时间紧或者目标是先跑通项目而不是打磨UIWinForms已经足够了。两个都用过之后你会对C#生态有一个更完整的认识。3.3 上位机后台的逻辑模块设计不只是画个窗口那么简单一个合格的上位机界面只是冰山一角藏在底下的是这么几个功能模块数据接收与解析模块负责从串口读取原始数据按照协议解析出帧头、指令、数据、校验位。这里有一个接口设计的细节解析要在后台线程做不要在DataReceived事件里直接操作UI控件否则会出现跨线程访问异常。解决办法是用Invoke或者BeginInvoke把更新UI的操作切换到UI线程。这个坑我当年踩了不止一次现在写出来希望你能绕开。数据库管理模块负责商品信息条码、名称、价格、库存、用户信息IC卡号、余额、交易记录流水号、商品、金额、时间的增删改查。交易记录表是后面做对账的基础字段一定要提前设计好比如加上交易状态成功/失败/退款不然上线之后想加字段就得改表结构非常被动。业务逻辑模块管理整个消费流程的状态机。空闲状态、扫描状态、支付状态、放行状态每个状态之间怎么跳转异常情况怎么回滚这些逻辑集中在一个类里管理可读性和可维护性都会好很多。日志模块记录软件运行过程中的关键事件比如启动、停止、串口异常、支付失败、用户操作等。日志格式尽量统一后面排查问题就靠它了。4. 上下位机通信协议设计与数据帧格式是怎么定下来的下位机和上位机各干各的活但必须通过一套双方都认可的“语言”来交流。这套语言就是通信协议。通信协议设计得好不好直接决定系统稳不稳定、排查问题快不快。4.1 自定义协议简单、可控、零依赖比MODBUS更适合这个场景工业上更常见的做法是MODBUS协议FreeModbus是嵌入式里应用最广的移植方案网上有大量的FreeModbus STM32移植教程。但我的实际体会是在这样一套只有几条指令的系统中直接引入MODBUS多少有点“杀鸡用牛刀”的意思。MODBUS确实强大支持多种功能码有成熟的异常处理机制但协议解析和状态机的复杂度也上去了。所以这里采用自定义的轻量帧协议格式简单明了。当然如果你的系统未来要接入PLC、组态软件或者第三方网关MODBUS就是必须的。三菱QJ71E71、串口服务器等工业设备基本上都默认支持MODBUS这时候FreeModbus移植方案就派上用场了。项目里我留了一个协议适配层的接口就是为了在自定义协议和MODBUS之间无痛切换。4.2 数据帧设计示例帧头、命令、数据、校验一个都不能少自定义协议我定义为如下格式帧头1字节固定0xAA 命令字1字节 数据长度1字节 数据域N字节 校验和1字节前面所有字节累加取低八位典型指令上位机发送“开锁指令”数据帧是 AA 01 01 01 03。0xAA是帧头0x01表示“控制电磁锁”0x01表示数据长度是1个字节0x01表示“开锁”0x00是关锁校验和就是0xAA0x010x010x010xAD取低八位是0x03。上位机还要向STM32查询状态比如门锁当前状态、传感器触发情况。这条查询指令的数据帧是 AA 02 00 00 AC。STM32收到后会回传状态数据帧例如门锁状态、红外传感器状态、称重值等打包在数据域里。回到上位机后上位机再把二进制数据翻译成人类可读的信息显示在界面上。STM32端收到数据帧后先判断帧头再解析命令字再根据数据长度读取数据域最后校验总和全部通过才算一帧有效数据。任何一步不对直接丢弃。这里有个细节串口接收是流式的一个数据帧可能被分两次收到也可能一次收到两帧所以必须在接收端维护一个缓冲区用状态机的方式逐字节处理而不是一收到中断就当成完整帧。状态机处理看起来麻烦实际上是所有串口通信的基础C#上位机和STM32两端都要这么写。4.3 串口调试工具调试阶段的好帮手写完了协议解析两边联调之前强烈建议先用串口调试工具把两端的收发逻辑分别验证好。上位机写完后如果还没有接STM32可以用虚拟串口工具比如VSPD创建一对互联的虚拟串口然后用两个串口助手分别接这两个口把一端当成STM32把另一端当成上位机模拟完整的收发交互。STM32端则可以把printf重定向到串口先用电脑串口助手手动发送数据帧看MCU的解析结果是否正确。这样的话两边独立验证通过之后再联调问题会少很多。5. 从零到一完整开发流程实录这部分把整个开发过程的步骤和工具链完整顺一遍。如果你是新手照着这个流程走能少走很多弯路。5.1 环境搭建CubeMXKeil的组合还是VSCodeCMakeSTM32的工程创建方式主要有三种标准库手动建工程、HAL库CubeMX自动生成、以及VSCodeCMake这种极客玩法。小白朋友注意网上经常有人在问“Keil5兼容C51和STM32安装”的问题其实这类问题最多的原因就是没有搞明白KEIL的包管理和设备库是两个不同的东西都装好就不存在所谓兼容问题。我推荐用STM32CubeMX初始化工程生成HAL库代码然后配合Keil5做编译调试。CubeMX最大的优势是可视化配置时钟树、GPIO和串口代码生成后你不用去记那些烦琐的寄存器操作把精力放在业务逻辑上。工程师语言里常说“像填空一样写代码”CubeMX就是典型的例子。不过建议至少要知道标准库手动新建工程是怎么回事因为网上很多老项目还是标准库写法的遇到老代码不至于看不懂。VSCodeCMakeGCC的路线现在也越来越成熟适合喜欢折腾并且深度使用代码补全、Git等功能的开发者。不过在毕设这类时间敏感的项目里尽量不要“从入门到放弃”KeilCubeMX是效率最高的选择。5.2 ST-LINK的烧录与调试比串口下载靠谱一百倍STM32的下载调试有两种常见方案串口ISP下载需要BOOT0拉高和ST-LINK SWD下载。新手往往嫌ST-LINK贵想省这几十块钱但实际体验下来你会明白ST-LINK的仿真能力是串口ISP完全替代不了的。它可以在线打断点、看变量值、单步执行遇到死循环或者逻辑错误时这种能力能救你命。接线方式非常简单ST-LINK的SWDIO接STM32的PA13SWCLK接PA14GND接GND3.3V接3.3V如果板子独立供电可以不接3.3V。然后用STM32 ST-LINK Utility或者Keil自带的下载按钮烧录。这里顺便提醒一句如果下载时报错“error: no stm32 target found! if your product embeds debug authentication, pl...”大概率是接线不对、芯片没供上电或者SWD引脚被程序占用。排查思路是检查供电、检查连接线、按住复位键再点下载基本能解决。5.3 上位机与下位机联调从串口参数到业务逻辑的完整闭环硬件先上电确认STM32的串口2通过USB转TTL连接到PC安装好CH340驱动。打开设备管理器查看串口号是多少比如COM5。再打开上位机在设置界面选择COM5、波特率115200、数据位8、停止位1、无校验。联调时先做最基础的数据通路测试上位机发一条查询状态指令看STM32是否回传正确的数据帧。通了之后再做完整的业务流程上位机点击“开门”→STM32继电器动作→电磁锁打开→红外检测到人通过→STM32上报状态→上位机显示“已关门”每一步都可以在界面上直观看到。这时候你会发现之前的协议设计和日志模块让联调变得非常轻松——任何一步出问题打开日志看一眼就知道卡在哪个环节。6. 实操中踩过的坑常见问题与排查技巧实录最后这部分整理了我在开发这套系统时遇到的高频问题全部来自真实调试经历按“现象—原因—解决办法”整理成表格方便你遇到类似问题时快速对照。6.1 现象设备管理器里STM32虚拟串口出现黄色叹号电脑无法识别USB转串口设备设备管理器里出现黄色感叹号。常见原因CH340驱动没装或者驱动版本太老或者USB线质量不好导致供电不稳定。解决办法重新安装CH340驱动去官网下载最新版本换一根短一点的USB线插在机箱后置USB口而不是前置口。如果驱动装了还是叹号试一下检查USB转串口芯片型号——有些劣质模块用的是国产仿制芯片需要装对应的兼容驱动。6.2 现象Keil下载时提示error: no stm32 target found这是新手最容易碰到的问题。原因之一是SWD接线错误或者芯片没有供电原因之二是芯片的SWD引脚被程序复用为普通GPIO导致调试器无法连接原因之三是芯片读保护被打开。解决办法检查接线和供电按住复位键的同时点击下载多试几次如果是因为程序锁死了SWD引脚用ST-LINK Utility的Connect under reset模式擦除芯片后再下载如果是读保护执行解除读保护操作。6.3 现象上位机偶尔收不到数据或者收到的数据乱码大概率是波特率不匹配。STM32端串口初始化时设置的波特率必须和上位机SerialPort控件设置的完全一致。另外USB转TTL模块质量参差不齐115200这种较高波特率在一些劣质模块上会丢字节。解决办法把波特率统一降到9600或者19200对于这种几百字节一帧的数据量低速波特率完全够用。如果你用了无线串口模块还要检查模块两边配对是否正确。6.4 现象电磁锁偶尔自动弹开上电瞬间继电器误触发。解决办法在前面已经提过GPIO初始化为高电平继电器不动作加上拉电阻先初始化GPIO再初始化外设。还有一点如果继电器的控制信号线和电磁锁的电源线在布线时靠得太近会造成电磁干扰把这个控制线尽量远离强电部分情况会好很多。6.5 现象称重模块读数漂移非常严重HX711模块的供电不够干净。排查思路给HX711单独加一个100uF电解电容和104陶瓷电容并联进行电源滤波确保称重传感器和HX711模块之间的接线长度不要太长最好在20cm以内初始化时做一次去皮操作然后用标准砝码标定比例参数。记住一点硬件上的“玄学”问题百分之八十都是电源问题先从电源查起准没错。6.6 现象上位机界面卡死点按钮没反应在DataReceived事件里直接处理耗时操作阻塞了UI线程。解决办法串口事件只负责接收数据并放入缓冲区解析和处理放到后台线程或使用System.Threading.TasksUI更新用BeginInvoke封送。说白了一句话不要在UI线程里做串口读写也不要在串口线程里做UI更新两端分开各干各的。最后分享一个经验这个项目做下来我最深的一个体会是嵌入式项目真正难的不是单片机编程本身而是“系统思维”。你既要懂STM32的GPIO、串口、中断也要懂上位机的线程、数据库、状态机还要搞定中间的通信协议和联调排错。这种跨界能力不是看几篇教程就能练出来的必须在完整的项目里亲手踩坑、亲手解决才能长到身上。如果你拿这个项目做毕设或者练手项目最后再给三个建议第一先别急着写代码花两天时间把系统架构图和数据流图画清楚这个时间花得值第二把通信协议文档写出来哪怕就一张A4纸后面联调会感谢你自己第三开发过程坚持写日志不只是代码注释而是记录每天的进度、问题和解决办法答辩或者写技术博客的时候这就是你的第一手素材。这套系统后续还有很多可以扩展的方向把PC上位机换成手机小程序、加入云端同步、用K210做视觉识别商品K210与STM32通讯可以用SPI或串口、用ESP8266做远程预警等等。每一个方向都能单独开一个项目来做。做技术的乐趣就在于永远有下一个坑等着你去踩也永远有下一个解决方案等着你去想。本文还有配套的精品资源点击获取