1. 项目概述为什么我们需要一个SPI FLASH烧写器最近在做一个基于RT-Thread的物联网设备项目遇到了一个挺典型的问题产品批量生产时怎么快速、可靠地把固件、文件系统甚至是一堆配置参数烧录到板载的SPI NOR FLASH里用J-Link配合调试口固然可以但效率太低而且产线工人操作起来也麻烦。用市面上的通用编程器要么太贵要么对RT-Thread特有的文件系统分区格式支持不好。于是一个念头就冒出来了能不能自己动手基于我们熟悉的RT-Thread操作系统做一个专门针对自家产品的、低成本、高可靠性的SPI FLASH烧写器这个“基于RT-Thread的SPI FLASH烧写器”本质上是一个运行在特定硬件我们称之为“烧写器主机”上的RT-Thread应用程序。它的核心功能是通过某种通信方式比如USB-CDC、UART或者以太网接收来自上位机通常是一台PC的指令和数据包然后解析这些指令精准地操作连接到其SPI接口上的目标FLASH芯片完成擦除、编程、校验等一系列操作。它把复杂的底层SPI时序、FLASH指令集封装起来对上提供一个简洁的“烧录协议”大大降低了生产环节的技术门槛和工具成本。这个项目非常适合已经有一定RT-Thread和嵌入式开发经验并且面临产品化生产问题的工程师。通过实现它你不仅能解决一个实际的生产痛点还能深入理解SPI FLASH的底层操作、RT-Thread的设备驱动框架、以及如何设计一个稳定可靠的上下位机通信协议。下面我就把自己从设计到实现再到调试优化的全过程经验分享出来里面有不少踩过的坑和总结的技巧希望能帮你少走弯路。2. 整体设计与核心思路拆解2.1 系统架构与角色定义首先我们要明确整个烧写系统的构成。它不是一个孤立的嵌入式程序而是一个由“上位机软件”、“烧写器固件”和“目标板”三部分构成的协同系统。上位机软件运行在Windows/Linux/Mac上的控制程序。它的职责是提供用户界面可以是GUI也可以是命令行工具管理要烧录的镜像文件如RT-Thread的rtthread.bin、文件系统镜像filesystem.img按照我们定义的协议将文件数据和控制指令打包通过串口或USB发送给烧写器固件。我选择用Python来开发上位机因为它跨平台性好开发效率高库丰富非常适合做这种工具类软件。烧写器固件本项目的主角运行在烧写器主控MCU上的RT-Thread应用程序。它需要完成以下核心任务协议解析实时解析上位机发来的数据流提取出正确的命令和数据。FLASH驱动通过SPI总线与目标FLASH芯片通信实现读ID、擦除扇区/块/整片、编程写、读取、校验等底层操作。任务调度合理使用RT-Thread的线程、信号量等机制确保通信处理和FLASH操作不阻塞并能响应可能的取消命令。状态反馈将操作结果成功、失败、进度实时反馈给上位机。目标板就是我们需要烧录的产品板。它通过SPI接口与我们的烧写器主机连接。这里有一个关键点为了避免目标板上的MCU干扰SPI通信在烧录时目标板MCU必须处于断电、复位或者完全释放SPI总线引脚配置为高阻输入的状态。通常我们会设计一个简单的烧录夹具由烧写器主机控制给目标板供电并在烧录前将其MCU复位。2.2 硬件平台选型与考量烧写器主控MCU的选择直接决定了成本和性能。我的选型思路如下核心需求需要至少1个高速SPI接口支持4线模式即Quad SPI可以大幅提升读写速度1-2个UART一个用于调试输出一个用于与上位机通信足够的RAM用于缓存数据包以及充足的GPIO用于控制目标板电源、复位等。性价比之选对于大多数NOR FLASH如W25Q系列GD25系列使用标准SPI1线模式或Dual/Quad SPI即可。常见的Cortex-M系列MCU都能胜任。例如STM32F4系列主频高有QSPI外设性能强劲适合追求速度的场景。STM32F1/GD32F1系列成本低使用标准SPI模拟Quad时序软件bit-bang虽然速度慢点但对于小容量FLASH或对烧录时间不敏感的生产线完全足够。这是我最初原型的选择因为便宜且熟悉。ESP32系列自带Wi-Fi/蓝牙如果想做无线烧录或网络化烧录产线这是个有趣的方向但复杂度会提高。我的选择我最终选择了GD32F303CCT6与STM32F103系列兼容但主频更高资源更丰富。理由价格比ST便宜有144MHz主频256KB RAM足够用标准SPI性能不错且社区支持好。我使用它的SPI1连接目标FLASHUSART1通过USB转串口芯片如CH340连接电脑USART2用于调试输出。另外用两个GPIO口控制目标板的电源和复位引脚。注意硬件设计时一定要在烧写器主机与目标板SPI接口之间串联22Ω-100Ω的电阻。这不是用于限流而是为了阻抗匹配抑制信号振铃尤其在连接线较长时能显著提高通信稳定性避免出现偶尔读写失败的问题。这是我踩过的一个坑。2.3 软件框架设计RT-Thread的威力为什么选择RT-Thread因为它提供的组件和框架能让我们快速搭建一个稳定、可扩展的系统。设备驱动框架RT-Thread的rt_device框架让我们可以用统一的方式操作SPI和UART。我们只需要在rtconfig.h中开启相关驱动并在board.c中完成引脚初始化就可以用rt_device_find(),rt_device_open()等标准API来使用它们无需直接操作寄存器代码可移植性更好。FinSH控制台这是RT-Thread的“神器”。在开发调试阶段我们可以通过FinSH命令行直接输入命令来测试SPI FLASH的读写、擦除功能无需每次都编译上位机软件极大提升了调试效率。线程与同步机制我们将设计两个主要线程协议解析线程负责从UART设备中循环读取数据解析成完整的命令帧。使用rt_sem_take等待数据用rt_sem_release通知处理线程。命令处理线程负责执行具体的FLASH操作命令。它等待解析线程的信号量拿到命令帧后执行并将结果通过UART发送回上位机。 这种生产者-消费者模型避免了在中断服务程序中进行复杂的FLASH操作这是大忌会导致系统不稳定。软件包生态RT-Thread的falFlash Abstraction Layer软件包本来是个很好的选择它提供了分区管理和操作接口。但经过评估我决定在V1.0版本中不直接使用fal。原因是我们的烧写器需要极高的可靠性和对底层操作的完全掌控fal的某些抽象层在极端情况下的错误处理可能不够透明。我选择直接基于FLASH芯片的Datasheet实现最核心的驱动这样虽然工作量稍大但心里更踏实也便于后续针对特定芯片做极致优化。不过fal的设计思想如分区表非常值得借鉴。3. 核心细节解析与实操要点3.1 SPI FLASH驱动实现不仅仅是读写驱动是烧写器的基石。实现一个健壮的SPI FLASH驱动需要注意以下几点初始化与探活上电后第一步是发送0x9F(Read JEDEC ID)命令。正确读取到厂商ID和设备ID如Winbond的0xEF, 0x4019是后续所有操作的前提。这里有个坑有些FLASH芯片上电后默认处于“写保护”或“深度掉电”状态需要先发送0xAB(Release Power-down)或0x06(Write Enable)命令唤醒或解除保护。我的做法是在初始化序列里依次发送Release Power-down - Read JEDEC ID - Write Enable为后续擦写做准备。擦除操作的艺术NOR FLASH必须先擦除变为0xFF才能写入。擦除单位有三种扇区Sector通常4KB、块Block通常32KB/64KB和整片Chip。策略选择为了速度我们当然想用64KB块擦除甚至整片擦除。但整片擦除风险极高一旦中途断电整个芯片数据全丢无法恢复。因此生产工具中绝对禁止使用整片擦除。我的策略是根据上位机下发的烧录区间计算覆盖了哪些扇区只擦除这些必要的扇区。这需要驱动实现扇区擦除0x20和块擦除0xD8两种命令并由上层逻辑智能选择。等待忙状态擦除和写入后FLASH内部需要时间完成操作期间读取状态寄存器SR1的BUSY位bit0为1。必须轮询等待该位变为0才能进行下一步操作。轮询间隔建议在1-10ms不要用rt_thread_delay(1)死等可以用rt_tick_get()计算超时时间通常扇区擦除超时设为100ms块擦除设为1s编程设为10ms超时则报错防止程序卡死。编程写入操作NOR FLASH的写入叫“编程”Program它只能将bit从1变为0不能从0变回1所以需要先擦除。编程命令是0x02(Page Program)一次最多写入一页Page通常256字节。关键点页边界处理如果你要写入的数据跨页了驱动必须自动拆分成多次页编程操作。我的驱动里有一个flash_write函数内部会处理地址对齐和分页。写入速度优化在确保稳定的前提下可以使用Quad SPI模式如果芯片和MCU都支持来提升写入速度。对于GD32F303我使用标准SPI但将时钟频率提升到了系统时钟的二分频约72MHz实测写入速度能达到500KB/s以上对于16MB的FLASH全片烧录也在30秒左右可以接受。校验机制烧录完成后校验是必须的。我采用最简单的“读回校验”将刚写入的数据再读出来逐字节与原始缓冲区比较。虽然有些编程器会用CRC32但对于NOR FLASH位翻转概率极低逐字节校验更直接出错信息也更具体能定位到出错的地址和数据。校验失败要立即停止并上报错误。// 驱动函数示例擦除一个扇区 rt_err_t spi_flash_erase_sector(rt_uint32_t addr) { rt_uint8_t cmd[4]; rt_err_t result RT_EOK; // 1. 发送写使能命令 flash_write_enable(); // 2. 发送扇区擦除命令 (0x20) 和24位地址 cmd[0] 0x20; cmd[1] (addr 16) 0xFF; cmd[2] (addr 8) 0xFF; cmd[3] addr 0xFF; spi_send_then_recv(cmd, 4, RT_NULL, 0); // 3. 等待擦除完成带超时检测 rt_tick_t start_tick rt_tick_get(); while (spi_flash_is_busy()) { if (rt_tick_get() - start_tick FLASH_ERASE_SECTOR_TIMEOUT) { LOG_E(Sector erase timeout at 0x%08X, addr); result -RT_ETIMEOUT; break; } rt_thread_delay(1); // 延时1个tick避免过度占用CPU } return result; }3.2 上下位机通信协议设计协议是连接上位机和下位机的桥梁。设计目标是简单、高效、可靠、易于扩展。帧结构设计我设计了一个类似Modbus的简单帧结构。[帧头 2B] [长度 2B] [命令码 1B] [数据域 N B] [CRC16 2B]帧头固定为0xAA55用于在数据流中识别帧的起始。长度从命令码开始到CRC16之前的所有字节数即1 N 2。这样接收方可以根据长度字段准确截取一帧数据。命令码定义各种操作如0x01-连接/断开0x10-读FLASH ID0x11-擦除扇区/块0x12-写数据0x13-读数据0x14-校验0x15-控制目标板电源等。数据域根据命令不同而不同。例如写数据命令的数据域就包含起始地址4字节、数据长度2字节和实际数据N字节。CRC16校验整帧数据的正确性。我采用CRC16-CCITT多项式0x1021初始值0xFFFF。这是工业通信中常用的校验方式比累加和可靠得多。数据分包与流控烧录几十KB甚至上MB的固件一帧发完不现实。需要分包。分包策略上位机将固件按每包512字节或1024字节进行拆分。每包作为一个独立的“写数据”命令帧发送。这个包大小需要权衡太小则协议开销比例大效率低太大则单帧传输时间长易受干扰且下位机需要更大的缓冲区。我选择1024字节是一个较好的平衡点。流控采用“应答-继续”机制。下位机成功处理完一包数据后必须回复一个“ACK”帧包含包序号和状态。上位机收到ACK后才发送下一包。如果超时未收到ACK则重发当前包重试次数可设如3次。这保证了数据传输的可靠性。协议解析状态机在下位机固件中协议解析不能简单地用rt_device_read读固定长度。因为数据是流式的可能半帧、多帧粘在一起。必须实现一个状态机State Machine来解析。// 简化的状态机示例 enum parse_state { STATE_HEADER1, STATE_HEADER2, STATE_LENGTH_H, STATE_LENGTH_L, STATE_CMD, STATE_DATA, STATE_CRC_H, STATE_CRC_L };解析线程循环读取UART数据每次读1字节或若干字节根据当前状态进行判断和跳转。当成功收集到一帧完整数据并CRC校验通过后将其放入一个命令队列并释放信号量通知处理线程。这里的关键是处理超时和残帧如果在一段时间内没有收到完整帧状态机必须重置丢弃不完整的数据避免“死锁”在某个状态。3.3 烧写器固件任务划分与实现在RT-Thread上我们如何组织这些功能线程设计主线程(main_thread)负责硬件初始化SPI, GPIO, UART创建其他线程和信号量、消息队列等资源然后可能挂起或执行一些低优先级任务。协议解析线程(parser_thread)优先级设为较高如8。它阻塞在UART设备的read上一旦有数据就触发状态机解析将完整命令帧入队并释放信号量。它的栈空间要设得足够大比如2KB因为解析过程中会有局部缓冲区。命令处理线程(handler_thread)优先级设为中等如10。它阻塞在信号量上一旦有命令帧需要处理就出队根据命令码调用相应的FLASH操作函数并将执行结果组帧发送回上位机。这是最关键的线程它的栈空间需要更大至少4KB因为FLASH读写操作会使用较大的局部数组。可选监控线程可以创建一个低优先级线程定期打印系统资源内存、线程状态到调试串口方便监控系统健康度。同步与通信命令队列使用RT-Thread的messagequeue。解析线程将命令帧的指针或结构体发送到队列处理线程从队列接收。队列深度设为5-10即可。信号量使用一个计数信号量。解析线程每成功入队一个命令就rt_sem_release一次。处理线程在循环开始处rt_sem_take等待这个信号量。这确保了有命令时才被唤醒节省CPU。互斥锁SPI总线是一个共享资源。当处理线程在执行FLASH操作时必须用互斥锁mutex锁住SPI设备防止其他线程比如你想在FinSH里手动读一下FLASH同时访问造成冲突。内存管理协议数据帧的缓冲区我使用RT-Thread的动态内存管理rt_malloc和rt_free。在解析线程中分配在处理线程中处理完毕后释放。务必注意成对使用避免内存泄漏。也可以使用静态数组池但灵活性稍差。对于要烧录的数据包处理线程中可能会需要一个较大的静态数组如1024字节协议头尾开销作为临时缓冲区。将其定义为线程栈内的局部数组即可操作完成即自动释放。4. 实操过程与核心环节实现4.1 开发环境搭建与工程创建我使用的是RT-Thread Studio基于Eclipse进行开发因为它对RT-Thread的项目管理和包管理支持很好。创建基于芯片的工程选择对应的GD32F3系列BSP。RT-Thread Studio会自动生成基础工程包含rtconfig.hboard.c等文件。配置系统在rtconfig.h中根据需求开启组件。// 开启设备驱动框架 #define RT_USING_DEVICE // 开启SPI设备驱动 #define RT_USING_SPI // 开启串口设备驱动 #define RT_USING_SERIAL // 开启FinSH强烈建议用于调试 #define RT_USING_FINSH // 调整主线程栈大小默认可能不够 #define RT_MAIN_THREAD_STACK_SIZE 2048 // 开启动态内存管理 #define RT_USING_HEAP配置硬件引脚在board.c的rt_hw_board_init()函数中或单独的文件中初始化用到的GPIO、SPI和UART引脚。特别注意SPI的SCK、MISO、MOSI、CS引脚配置以及UART的TX、RX引脚。确保与原理图一致。编写驱动层在drivers目录下创建或修改drv_spi.c和drv_usart.c实现RT-Thread设备驱动框架要求的operate函数如configure,transmit等。对于GD32RT-Thread的BSP通常已经提供了这些驱动我们只需确认它们被正确启用和初始化。4.2 烧写器应用程序编码实现这是核心代码部分。我建议按模块组织代码spi_flash.c/h纯SPI FLASH底层驱动只依赖RT-Thread的SPI设备接口。提供flash_init,flash_read_id,flash_erase_sector,flash_write_page,flash_read等基础API。protocol.c/h协议解析与组帧模块。包含帧结构体定义、CRC16计算函数、状态机解析函数protocol_parse、以及组帧发送函数protocol_send_response。cmd_handler.c/h命令处理模块。包含一个大的switch-case结构根据命令码调用spi_flash.c中的函数并组织回复数据。app_main.c应用主文件。包含main函数和各个线程的入口函数。在这里创建线程、信号量、消息队列并启动调度器。线程入口函数示例// 命令处理线程入口 static void handler_thread_entry(void *parameter) { struct rx_frame *cmd_frame; while (1) { // 等待解析线程的信号量 if (rt_sem_take(handler_sem, RT_WAITING_FOREVER) RT_EOK) { // 从消息队列获取命令帧 if (rt_mq_recv(cmd_mq, cmd_frame, sizeof(void*), RT_WAITING_FOREVER) RT_EOK) { // 获取SPI总线锁 rt_mutex_take(spi_mutex, RT_WAITING_FOREVER); // 根据命令码处理 handle_command(cmd_frame); // 释放命令帧内存 rt_free(cmd_frame-data); rt_free(cmd_frame); // 释放SPI总线锁 rt_mutex_release(spi_mutex); } } } }4.3 上位机软件Python快速开发上位机使用Python的pyserial库进行串口通信tkinter或PyQt做简单界面如果不需要界面用argparse做命令行工具也行。核心流程如下打开串口设置正确的波特率如115200、数据位、停止位、校验位。连接握手发送一个“连接”命令帧0x01等待烧写器回复特定的“就绪”应答。这是确认通信链路和烧写器状态正常的必要步骤。读取FLASH ID发送读ID命令确认连接的目标FLASH型号与预期一致防止烧错芯片。擦除根据待烧录文件的大小和起始地址通常从0x0开始计算需要擦除的扇区范围循环发送擦除命令。这里可以加入进度显示给用户反馈。编程打开二进制文件如.bin按1024字节分块循环发送“写数据”命令帧并等待每一个ACK。必须实现超时重传机制。校验发送“校验”命令下位机会读回数据并比较返回结果。或者上位机也可以主动发送“读数据”命令读回刚写入的区域自己计算CRC比对双重保险。结束发送“断开连接”命令关闭串口。Python发送一帧数据的示例import serial import struct import crcmod def create_frame(cmd, datab): 创建协议帧 header b\xaa\x55 length struct.pack(H, 1 len(data) 2) # 命令码1B 数据 CRC2B frame header length bytes([cmd]) data # 计算CRC16 (CCITT) crc16_func crcmod.mkCrcFun(0x11021, initCrc0xFFFF, revFalse) crc crc16_func(frame[2:]) # 从长度字段开始计算 frame struct.pack(H, crc) return frame def send_cmd(ser, cmd, datab, timeout1.0): 发送命令并等待回复 frame create_frame(cmd, data) ser.write(frame) # ... 等待并解析回复的逻辑 ...4.4 集成测试与生产流程模拟开发完成后不能直接上产线必须进行严格的集成测试。单元测试在FinSH里手动调用驱动函数读写一个测试扇区验证基本功能。协议测试用串口调试助手如SecureCRT, Putty或自己写个简单的Python脚本模拟上位机发送各种命令帧观察烧写器返回是否正确。端到端测试准备一块已知好坏的目标板。使用完整的Python上位机烧录一个已知正确的rtthread.bin镜像。烧录完成后通过J-Link或其他方式读取目标FLASH的内容与原始bin文件进行二进制比较必须100%一致。进行压力测试连续烧录-擦除循环100次观察是否有失败、内存泄漏通过RT-Thread的list_mem命令监控或系统死机。异常处理测试模拟各种异常情况通信中断在烧录过程中拔掉串口线系统应能检测到超时并进入安全状态。数据错误上位机发送CRC错误的帧烧写器应丢弃并可能请求重发取决于协议设计。FLASH操作失败可以临时将FLASH的WP写保护引脚拉低使擦写命令失败测试下位机的错误处理和上报机制。生产流程固化测试通过后将整个流程脚本化。上位机软件最好能读取一个配置文件config.ini或config.json里面定义好要烧录的多个文件、各自的起始地址、是否需要擦除等。这样产线工人只需要点击一个“开始”按钮或者运行一条命令就能完成整个产品的烧录。5. 常见问题与排查技巧实录在实际开发和后续使用中我遇到了不少问题这里总结一下希望能帮你提前避坑。5.1 通信不稳定数据丢包或错帧现象烧录过程中偶尔失败上位机提示超时或CRC错误。排查检查硬件这是首要怀疑对象。测量SPI和UART的波形看是否有过冲、振铃。确保串联了匹配电阻22-100Ω。检查电源是否干净MCU和FLASH的退耦电容0.1uF是否靠近引脚焊接。降低波特率如果UART通信在115200下不稳定尝试降到57600或38400。虽然速度慢了但稳定性优先。优化下位机解析检查协议解析状态机是否有漏洞特别是在处理残帧时。一个常见错误是在STATE_DATA状态如果数据长度很长UART接收中断或读取函数可能分多次才收完状态机必须能正确处理这种“分段到达”的情况。确保你的rt_device_read调用和状态机逻辑能应对任意字节数的数据块。增加上位机重试在上位机代码中对于重要的命令如写数据包增加重试机制比如3次。如果连续重试失败再报错。5.2 FLASH操作失败写保护、擦除超时现象擦除或编程命令返回错误读状态寄存器发现写保护位SRP, BPx等被置位或BUSY位超时。排查确认硬件写保护检查FLASH芯片的/WP写保护和/HOLD保持引脚的电平。在烧录时它们通常需要上拉到VCC高电平以禁用硬件保护。我的设计里直接用10k电阻上拉到3.3V。检查软件写保护有些FLASH的某些扇区默认是受软件写保护锁定的。在初始化时发送Write Enable (0x06)命令只能临时使能一次操作。对于需要批量擦写的场景可能需要发送Write Status Register (0x01)命令将状态寄存器中的块保护位BP2, BP1, BP0全部清零。务必先仔细阅读芯片数据手册中关于状态寄存器的说明。超时时间设置不同厂家、不同容量、甚至不同批次的FLASH其擦除和编程时间可能有差异。将驱动中的超时时间设置得充裕一些。例如将扇区擦除超时设为200ms块擦除设为2s。宁可等久一点也别因超时误判失败。电源稳定性FLASH在擦写时功耗会瞬间增大。确保你的电源特别是给FLASH供电的3.3V能提供足够的电流且纹波小。在电源引脚附近增加一个10uF的钽电容或电解电容会有奇效。5.3 系统运行一段时间后死机现象连续烧录多个产品后烧写器无响应。排查堆栈溢出这是RT-Thread多线程编程中最常见的问题。使用ps命令查看各线程的max used栈使用量。确保你为handler_thread等线程分配的栈空间stack_size远大于其max used值至少留出50%余量。我的处理线程栈大小最终设为4096字节。内存泄漏在FinSH中使用list_mem命令在长时间运行前后对比total memory和used memory。如果used memory持续增长说明有动态内存没有释放。重点检查协议解析中rt_malloc和rt_free是否成对出现特别是在错误处理分支上是否也正确释放了内存。中断冲突如果你使用了SPI DMA或者UART DMA并设置了高优先级中断可能会影响RT-Thread的系统滴答定时器SysTick中断导致调度器出问题。检查中断优先级配置确保SysTick中断的优先级不是最低的但也不能最高其他外设中断优先级合理。5.4 烧录速度慢生产效率低现象烧录一个8MB的镜像要两三分钟产线抱怨。优化增大数据包将协议中的数据包长度从512字节提升到1024甚至2048字节减少协议头尾开销和通信往返次数。但要同步增大下位机的接收缓冲区。使用Quad SPI如果MCU和FLASH都支持将SPI切换到4线模式理论上速度可提升近4倍。这需要修改驱动在读写命令前后发送相应的“进入Quad模式”指令如0xEB代替0x03进行快速读。优化擦除策略如果每次烧录的固件都覆盖整个FLASH且FLASH容量不大如8MB以下可以考虑使用“块擦除”64KB代替“扇区擦除”4KB。擦除次数减少总时间会缩短。但前提是固件布局必须对齐到块边界。上位机多线程在上位机可以使用生产者-消费者模型一个线程负责读取文件并分包另一个线程负责发送和接收应答实现“流水线”操作减少等待时间。5.5 量产时的实用技巧烧写器固件版本管理在固件中定义一个版本字符串如Programmer V1.2.1并通过响应“连接”命令返回给上位机。上位机软件可以检查版本号确保与烧写器固件兼容。日志与追溯在上位机软件中为每一次烧录操作生成一个日志文件记录产品序列号如果通过扫码枪输入、烧录的文件、校验结果、开始结束时间等。便于后续质量追溯。夹具与防呆设计制作一个简单的烧录夹具通过探针或顶针连接目标板的SPI和电源引脚。夹具上要有明确的定位槽防止板子放反。烧写器主机通过一个GPIO控制夹具上的电磁铁或锁扣只有板子放到位了才开始供电和烧录。一键烧录将整个上位机操作流程封装成一个批处理脚本.bat或Shell脚本产线工人只需双击脚本插入产品脚本会自动检测串口、执行烧录、显示结果成功/失败。将复杂度隐藏在后台。这个基于RT-Thread的SPI FLASH烧写器项目从构思到稳定运行花了我差不多一个月的业余时间。最大的收获不是做出了一个工具而是在这个过程中对RT-Thread的多任务机制、SPI底层通信、以及如何设计一个可靠的工业通信协议有了更深的理解。现在这个烧写器已经在我们的小批量产线上稳定运行了大半年烧录了上千片板子没出过岔子。如果你也面临类似的需求不妨动手试试这个过程绝对值得。
基于RT-Thread的SPI FLASH烧写器：从设计到量产实践
1. 项目概述为什么我们需要一个SPI FLASH烧写器最近在做一个基于RT-Thread的物联网设备项目遇到了一个挺典型的问题产品批量生产时怎么快速、可靠地把固件、文件系统甚至是一堆配置参数烧录到板载的SPI NOR FLASH里用J-Link配合调试口固然可以但效率太低而且产线工人操作起来也麻烦。用市面上的通用编程器要么太贵要么对RT-Thread特有的文件系统分区格式支持不好。于是一个念头就冒出来了能不能自己动手基于我们熟悉的RT-Thread操作系统做一个专门针对自家产品的、低成本、高可靠性的SPI FLASH烧写器这个“基于RT-Thread的SPI FLASH烧写器”本质上是一个运行在特定硬件我们称之为“烧写器主机”上的RT-Thread应用程序。它的核心功能是通过某种通信方式比如USB-CDC、UART或者以太网接收来自上位机通常是一台PC的指令和数据包然后解析这些指令精准地操作连接到其SPI接口上的目标FLASH芯片完成擦除、编程、校验等一系列操作。它把复杂的底层SPI时序、FLASH指令集封装起来对上提供一个简洁的“烧录协议”大大降低了生产环节的技术门槛和工具成本。这个项目非常适合已经有一定RT-Thread和嵌入式开发经验并且面临产品化生产问题的工程师。通过实现它你不仅能解决一个实际的生产痛点还能深入理解SPI FLASH的底层操作、RT-Thread的设备驱动框架、以及如何设计一个稳定可靠的上下位机通信协议。下面我就把自己从设计到实现再到调试优化的全过程经验分享出来里面有不少踩过的坑和总结的技巧希望能帮你少走弯路。2. 整体设计与核心思路拆解2.1 系统架构与角色定义首先我们要明确整个烧写系统的构成。它不是一个孤立的嵌入式程序而是一个由“上位机软件”、“烧写器固件”和“目标板”三部分构成的协同系统。上位机软件运行在Windows/Linux/Mac上的控制程序。它的职责是提供用户界面可以是GUI也可以是命令行工具管理要烧录的镜像文件如RT-Thread的rtthread.bin、文件系统镜像filesystem.img按照我们定义的协议将文件数据和控制指令打包通过串口或USB发送给烧写器固件。我选择用Python来开发上位机因为它跨平台性好开发效率高库丰富非常适合做这种工具类软件。烧写器固件本项目的主角运行在烧写器主控MCU上的RT-Thread应用程序。它需要完成以下核心任务协议解析实时解析上位机发来的数据流提取出正确的命令和数据。FLASH驱动通过SPI总线与目标FLASH芯片通信实现读ID、擦除扇区/块/整片、编程写、读取、校验等底层操作。任务调度合理使用RT-Thread的线程、信号量等机制确保通信处理和FLASH操作不阻塞并能响应可能的取消命令。状态反馈将操作结果成功、失败、进度实时反馈给上位机。目标板就是我们需要烧录的产品板。它通过SPI接口与我们的烧写器主机连接。这里有一个关键点为了避免目标板上的MCU干扰SPI通信在烧录时目标板MCU必须处于断电、复位或者完全释放SPI总线引脚配置为高阻输入的状态。通常我们会设计一个简单的烧录夹具由烧写器主机控制给目标板供电并在烧录前将其MCU复位。2.2 硬件平台选型与考量烧写器主控MCU的选择直接决定了成本和性能。我的选型思路如下核心需求需要至少1个高速SPI接口支持4线模式即Quad SPI可以大幅提升读写速度1-2个UART一个用于调试输出一个用于与上位机通信足够的RAM用于缓存数据包以及充足的GPIO用于控制目标板电源、复位等。性价比之选对于大多数NOR FLASH如W25Q系列GD25系列使用标准SPI1线模式或Dual/Quad SPI即可。常见的Cortex-M系列MCU都能胜任。例如STM32F4系列主频高有QSPI外设性能强劲适合追求速度的场景。STM32F1/GD32F1系列成本低使用标准SPI模拟Quad时序软件bit-bang虽然速度慢点但对于小容量FLASH或对烧录时间不敏感的生产线完全足够。这是我最初原型的选择因为便宜且熟悉。ESP32系列自带Wi-Fi/蓝牙如果想做无线烧录或网络化烧录产线这是个有趣的方向但复杂度会提高。我的选择我最终选择了GD32F303CCT6与STM32F103系列兼容但主频更高资源更丰富。理由价格比ST便宜有144MHz主频256KB RAM足够用标准SPI性能不错且社区支持好。我使用它的SPI1连接目标FLASHUSART1通过USB转串口芯片如CH340连接电脑USART2用于调试输出。另外用两个GPIO口控制目标板的电源和复位引脚。注意硬件设计时一定要在烧写器主机与目标板SPI接口之间串联22Ω-100Ω的电阻。这不是用于限流而是为了阻抗匹配抑制信号振铃尤其在连接线较长时能显著提高通信稳定性避免出现偶尔读写失败的问题。这是我踩过的一个坑。2.3 软件框架设计RT-Thread的威力为什么选择RT-Thread因为它提供的组件和框架能让我们快速搭建一个稳定、可扩展的系统。设备驱动框架RT-Thread的rt_device框架让我们可以用统一的方式操作SPI和UART。我们只需要在rtconfig.h中开启相关驱动并在board.c中完成引脚初始化就可以用rt_device_find(),rt_device_open()等标准API来使用它们无需直接操作寄存器代码可移植性更好。FinSH控制台这是RT-Thread的“神器”。在开发调试阶段我们可以通过FinSH命令行直接输入命令来测试SPI FLASH的读写、擦除功能无需每次都编译上位机软件极大提升了调试效率。线程与同步机制我们将设计两个主要线程协议解析线程负责从UART设备中循环读取数据解析成完整的命令帧。使用rt_sem_take等待数据用rt_sem_release通知处理线程。命令处理线程负责执行具体的FLASH操作命令。它等待解析线程的信号量拿到命令帧后执行并将结果通过UART发送回上位机。 这种生产者-消费者模型避免了在中断服务程序中进行复杂的FLASH操作这是大忌会导致系统不稳定。软件包生态RT-Thread的falFlash Abstraction Layer软件包本来是个很好的选择它提供了分区管理和操作接口。但经过评估我决定在V1.0版本中不直接使用fal。原因是我们的烧写器需要极高的可靠性和对底层操作的完全掌控fal的某些抽象层在极端情况下的错误处理可能不够透明。我选择直接基于FLASH芯片的Datasheet实现最核心的驱动这样虽然工作量稍大但心里更踏实也便于后续针对特定芯片做极致优化。不过fal的设计思想如分区表非常值得借鉴。3. 核心细节解析与实操要点3.1 SPI FLASH驱动实现不仅仅是读写驱动是烧写器的基石。实现一个健壮的SPI FLASH驱动需要注意以下几点初始化与探活上电后第一步是发送0x9F(Read JEDEC ID)命令。正确读取到厂商ID和设备ID如Winbond的0xEF, 0x4019是后续所有操作的前提。这里有个坑有些FLASH芯片上电后默认处于“写保护”或“深度掉电”状态需要先发送0xAB(Release Power-down)或0x06(Write Enable)命令唤醒或解除保护。我的做法是在初始化序列里依次发送Release Power-down - Read JEDEC ID - Write Enable为后续擦写做准备。擦除操作的艺术NOR FLASH必须先擦除变为0xFF才能写入。擦除单位有三种扇区Sector通常4KB、块Block通常32KB/64KB和整片Chip。策略选择为了速度我们当然想用64KB块擦除甚至整片擦除。但整片擦除风险极高一旦中途断电整个芯片数据全丢无法恢复。因此生产工具中绝对禁止使用整片擦除。我的策略是根据上位机下发的烧录区间计算覆盖了哪些扇区只擦除这些必要的扇区。这需要驱动实现扇区擦除0x20和块擦除0xD8两种命令并由上层逻辑智能选择。等待忙状态擦除和写入后FLASH内部需要时间完成操作期间读取状态寄存器SR1的BUSY位bit0为1。必须轮询等待该位变为0才能进行下一步操作。轮询间隔建议在1-10ms不要用rt_thread_delay(1)死等可以用rt_tick_get()计算超时时间通常扇区擦除超时设为100ms块擦除设为1s编程设为10ms超时则报错防止程序卡死。编程写入操作NOR FLASH的写入叫“编程”Program它只能将bit从1变为0不能从0变回1所以需要先擦除。编程命令是0x02(Page Program)一次最多写入一页Page通常256字节。关键点页边界处理如果你要写入的数据跨页了驱动必须自动拆分成多次页编程操作。我的驱动里有一个flash_write函数内部会处理地址对齐和分页。写入速度优化在确保稳定的前提下可以使用Quad SPI模式如果芯片和MCU都支持来提升写入速度。对于GD32F303我使用标准SPI但将时钟频率提升到了系统时钟的二分频约72MHz实测写入速度能达到500KB/s以上对于16MB的FLASH全片烧录也在30秒左右可以接受。校验机制烧录完成后校验是必须的。我采用最简单的“读回校验”将刚写入的数据再读出来逐字节与原始缓冲区比较。虽然有些编程器会用CRC32但对于NOR FLASH位翻转概率极低逐字节校验更直接出错信息也更具体能定位到出错的地址和数据。校验失败要立即停止并上报错误。// 驱动函数示例擦除一个扇区 rt_err_t spi_flash_erase_sector(rt_uint32_t addr) { rt_uint8_t cmd[4]; rt_err_t result RT_EOK; // 1. 发送写使能命令 flash_write_enable(); // 2. 发送扇区擦除命令 (0x20) 和24位地址 cmd[0] 0x20; cmd[1] (addr 16) 0xFF; cmd[2] (addr 8) 0xFF; cmd[3] addr 0xFF; spi_send_then_recv(cmd, 4, RT_NULL, 0); // 3. 等待擦除完成带超时检测 rt_tick_t start_tick rt_tick_get(); while (spi_flash_is_busy()) { if (rt_tick_get() - start_tick FLASH_ERASE_SECTOR_TIMEOUT) { LOG_E(Sector erase timeout at 0x%08X, addr); result -RT_ETIMEOUT; break; } rt_thread_delay(1); // 延时1个tick避免过度占用CPU } return result; }3.2 上下位机通信协议设计协议是连接上位机和下位机的桥梁。设计目标是简单、高效、可靠、易于扩展。帧结构设计我设计了一个类似Modbus的简单帧结构。[帧头 2B] [长度 2B] [命令码 1B] [数据域 N B] [CRC16 2B]帧头固定为0xAA55用于在数据流中识别帧的起始。长度从命令码开始到CRC16之前的所有字节数即1 N 2。这样接收方可以根据长度字段准确截取一帧数据。命令码定义各种操作如0x01-连接/断开0x10-读FLASH ID0x11-擦除扇区/块0x12-写数据0x13-读数据0x14-校验0x15-控制目标板电源等。数据域根据命令不同而不同。例如写数据命令的数据域就包含起始地址4字节、数据长度2字节和实际数据N字节。CRC16校验整帧数据的正确性。我采用CRC16-CCITT多项式0x1021初始值0xFFFF。这是工业通信中常用的校验方式比累加和可靠得多。数据分包与流控烧录几十KB甚至上MB的固件一帧发完不现实。需要分包。分包策略上位机将固件按每包512字节或1024字节进行拆分。每包作为一个独立的“写数据”命令帧发送。这个包大小需要权衡太小则协议开销比例大效率低太大则单帧传输时间长易受干扰且下位机需要更大的缓冲区。我选择1024字节是一个较好的平衡点。流控采用“应答-继续”机制。下位机成功处理完一包数据后必须回复一个“ACK”帧包含包序号和状态。上位机收到ACK后才发送下一包。如果超时未收到ACK则重发当前包重试次数可设如3次。这保证了数据传输的可靠性。协议解析状态机在下位机固件中协议解析不能简单地用rt_device_read读固定长度。因为数据是流式的可能半帧、多帧粘在一起。必须实现一个状态机State Machine来解析。// 简化的状态机示例 enum parse_state { STATE_HEADER1, STATE_HEADER2, STATE_LENGTH_H, STATE_LENGTH_L, STATE_CMD, STATE_DATA, STATE_CRC_H, STATE_CRC_L };解析线程循环读取UART数据每次读1字节或若干字节根据当前状态进行判断和跳转。当成功收集到一帧完整数据并CRC校验通过后将其放入一个命令队列并释放信号量通知处理线程。这里的关键是处理超时和残帧如果在一段时间内没有收到完整帧状态机必须重置丢弃不完整的数据避免“死锁”在某个状态。3.3 烧写器固件任务划分与实现在RT-Thread上我们如何组织这些功能线程设计主线程(main_thread)负责硬件初始化SPI, GPIO, UART创建其他线程和信号量、消息队列等资源然后可能挂起或执行一些低优先级任务。协议解析线程(parser_thread)优先级设为较高如8。它阻塞在UART设备的read上一旦有数据就触发状态机解析将完整命令帧入队并释放信号量。它的栈空间要设得足够大比如2KB因为解析过程中会有局部缓冲区。命令处理线程(handler_thread)优先级设为中等如10。它阻塞在信号量上一旦有命令帧需要处理就出队根据命令码调用相应的FLASH操作函数并将执行结果组帧发送回上位机。这是最关键的线程它的栈空间需要更大至少4KB因为FLASH读写操作会使用较大的局部数组。可选监控线程可以创建一个低优先级线程定期打印系统资源内存、线程状态到调试串口方便监控系统健康度。同步与通信命令队列使用RT-Thread的messagequeue。解析线程将命令帧的指针或结构体发送到队列处理线程从队列接收。队列深度设为5-10即可。信号量使用一个计数信号量。解析线程每成功入队一个命令就rt_sem_release一次。处理线程在循环开始处rt_sem_take等待这个信号量。这确保了有命令时才被唤醒节省CPU。互斥锁SPI总线是一个共享资源。当处理线程在执行FLASH操作时必须用互斥锁mutex锁住SPI设备防止其他线程比如你想在FinSH里手动读一下FLASH同时访问造成冲突。内存管理协议数据帧的缓冲区我使用RT-Thread的动态内存管理rt_malloc和rt_free。在解析线程中分配在处理线程中处理完毕后释放。务必注意成对使用避免内存泄漏。也可以使用静态数组池但灵活性稍差。对于要烧录的数据包处理线程中可能会需要一个较大的静态数组如1024字节协议头尾开销作为临时缓冲区。将其定义为线程栈内的局部数组即可操作完成即自动释放。4. 实操过程与核心环节实现4.1 开发环境搭建与工程创建我使用的是RT-Thread Studio基于Eclipse进行开发因为它对RT-Thread的项目管理和包管理支持很好。创建基于芯片的工程选择对应的GD32F3系列BSP。RT-Thread Studio会自动生成基础工程包含rtconfig.hboard.c等文件。配置系统在rtconfig.h中根据需求开启组件。// 开启设备驱动框架 #define RT_USING_DEVICE // 开启SPI设备驱动 #define RT_USING_SPI // 开启串口设备驱动 #define RT_USING_SERIAL // 开启FinSH强烈建议用于调试 #define RT_USING_FINSH // 调整主线程栈大小默认可能不够 #define RT_MAIN_THREAD_STACK_SIZE 2048 // 开启动态内存管理 #define RT_USING_HEAP配置硬件引脚在board.c的rt_hw_board_init()函数中或单独的文件中初始化用到的GPIO、SPI和UART引脚。特别注意SPI的SCK、MISO、MOSI、CS引脚配置以及UART的TX、RX引脚。确保与原理图一致。编写驱动层在drivers目录下创建或修改drv_spi.c和drv_usart.c实现RT-Thread设备驱动框架要求的operate函数如configure,transmit等。对于GD32RT-Thread的BSP通常已经提供了这些驱动我们只需确认它们被正确启用和初始化。4.2 烧写器应用程序编码实现这是核心代码部分。我建议按模块组织代码spi_flash.c/h纯SPI FLASH底层驱动只依赖RT-Thread的SPI设备接口。提供flash_init,flash_read_id,flash_erase_sector,flash_write_page,flash_read等基础API。protocol.c/h协议解析与组帧模块。包含帧结构体定义、CRC16计算函数、状态机解析函数protocol_parse、以及组帧发送函数protocol_send_response。cmd_handler.c/h命令处理模块。包含一个大的switch-case结构根据命令码调用spi_flash.c中的函数并组织回复数据。app_main.c应用主文件。包含main函数和各个线程的入口函数。在这里创建线程、信号量、消息队列并启动调度器。线程入口函数示例// 命令处理线程入口 static void handler_thread_entry(void *parameter) { struct rx_frame *cmd_frame; while (1) { // 等待解析线程的信号量 if (rt_sem_take(handler_sem, RT_WAITING_FOREVER) RT_EOK) { // 从消息队列获取命令帧 if (rt_mq_recv(cmd_mq, cmd_frame, sizeof(void*), RT_WAITING_FOREVER) RT_EOK) { // 获取SPI总线锁 rt_mutex_take(spi_mutex, RT_WAITING_FOREVER); // 根据命令码处理 handle_command(cmd_frame); // 释放命令帧内存 rt_free(cmd_frame-data); rt_free(cmd_frame); // 释放SPI总线锁 rt_mutex_release(spi_mutex); } } } }4.3 上位机软件Python快速开发上位机使用Python的pyserial库进行串口通信tkinter或PyQt做简单界面如果不需要界面用argparse做命令行工具也行。核心流程如下打开串口设置正确的波特率如115200、数据位、停止位、校验位。连接握手发送一个“连接”命令帧0x01等待烧写器回复特定的“就绪”应答。这是确认通信链路和烧写器状态正常的必要步骤。读取FLASH ID发送读ID命令确认连接的目标FLASH型号与预期一致防止烧错芯片。擦除根据待烧录文件的大小和起始地址通常从0x0开始计算需要擦除的扇区范围循环发送擦除命令。这里可以加入进度显示给用户反馈。编程打开二进制文件如.bin按1024字节分块循环发送“写数据”命令帧并等待每一个ACK。必须实现超时重传机制。校验发送“校验”命令下位机会读回数据并比较返回结果。或者上位机也可以主动发送“读数据”命令读回刚写入的区域自己计算CRC比对双重保险。结束发送“断开连接”命令关闭串口。Python发送一帧数据的示例import serial import struct import crcmod def create_frame(cmd, datab): 创建协议帧 header b\xaa\x55 length struct.pack(H, 1 len(data) 2) # 命令码1B 数据 CRC2B frame header length bytes([cmd]) data # 计算CRC16 (CCITT) crc16_func crcmod.mkCrcFun(0x11021, initCrc0xFFFF, revFalse) crc crc16_func(frame[2:]) # 从长度字段开始计算 frame struct.pack(H, crc) return frame def send_cmd(ser, cmd, datab, timeout1.0): 发送命令并等待回复 frame create_frame(cmd, data) ser.write(frame) # ... 等待并解析回复的逻辑 ...4.4 集成测试与生产流程模拟开发完成后不能直接上产线必须进行严格的集成测试。单元测试在FinSH里手动调用驱动函数读写一个测试扇区验证基本功能。协议测试用串口调试助手如SecureCRT, Putty或自己写个简单的Python脚本模拟上位机发送各种命令帧观察烧写器返回是否正确。端到端测试准备一块已知好坏的目标板。使用完整的Python上位机烧录一个已知正确的rtthread.bin镜像。烧录完成后通过J-Link或其他方式读取目标FLASH的内容与原始bin文件进行二进制比较必须100%一致。进行压力测试连续烧录-擦除循环100次观察是否有失败、内存泄漏通过RT-Thread的list_mem命令监控或系统死机。异常处理测试模拟各种异常情况通信中断在烧录过程中拔掉串口线系统应能检测到超时并进入安全状态。数据错误上位机发送CRC错误的帧烧写器应丢弃并可能请求重发取决于协议设计。FLASH操作失败可以临时将FLASH的WP写保护引脚拉低使擦写命令失败测试下位机的错误处理和上报机制。生产流程固化测试通过后将整个流程脚本化。上位机软件最好能读取一个配置文件config.ini或config.json里面定义好要烧录的多个文件、各自的起始地址、是否需要擦除等。这样产线工人只需要点击一个“开始”按钮或者运行一条命令就能完成整个产品的烧录。5. 常见问题与排查技巧实录在实际开发和后续使用中我遇到了不少问题这里总结一下希望能帮你提前避坑。5.1 通信不稳定数据丢包或错帧现象烧录过程中偶尔失败上位机提示超时或CRC错误。排查检查硬件这是首要怀疑对象。测量SPI和UART的波形看是否有过冲、振铃。确保串联了匹配电阻22-100Ω。检查电源是否干净MCU和FLASH的退耦电容0.1uF是否靠近引脚焊接。降低波特率如果UART通信在115200下不稳定尝试降到57600或38400。虽然速度慢了但稳定性优先。优化下位机解析检查协议解析状态机是否有漏洞特别是在处理残帧时。一个常见错误是在STATE_DATA状态如果数据长度很长UART接收中断或读取函数可能分多次才收完状态机必须能正确处理这种“分段到达”的情况。确保你的rt_device_read调用和状态机逻辑能应对任意字节数的数据块。增加上位机重试在上位机代码中对于重要的命令如写数据包增加重试机制比如3次。如果连续重试失败再报错。5.2 FLASH操作失败写保护、擦除超时现象擦除或编程命令返回错误读状态寄存器发现写保护位SRP, BPx等被置位或BUSY位超时。排查确认硬件写保护检查FLASH芯片的/WP写保护和/HOLD保持引脚的电平。在烧录时它们通常需要上拉到VCC高电平以禁用硬件保护。我的设计里直接用10k电阻上拉到3.3V。检查软件写保护有些FLASH的某些扇区默认是受软件写保护锁定的。在初始化时发送Write Enable (0x06)命令只能临时使能一次操作。对于需要批量擦写的场景可能需要发送Write Status Register (0x01)命令将状态寄存器中的块保护位BP2, BP1, BP0全部清零。务必先仔细阅读芯片数据手册中关于状态寄存器的说明。超时时间设置不同厂家、不同容量、甚至不同批次的FLASH其擦除和编程时间可能有差异。将驱动中的超时时间设置得充裕一些。例如将扇区擦除超时设为200ms块擦除设为2s。宁可等久一点也别因超时误判失败。电源稳定性FLASH在擦写时功耗会瞬间增大。确保你的电源特别是给FLASH供电的3.3V能提供足够的电流且纹波小。在电源引脚附近增加一个10uF的钽电容或电解电容会有奇效。5.3 系统运行一段时间后死机现象连续烧录多个产品后烧写器无响应。排查堆栈溢出这是RT-Thread多线程编程中最常见的问题。使用ps命令查看各线程的max used栈使用量。确保你为handler_thread等线程分配的栈空间stack_size远大于其max used值至少留出50%余量。我的处理线程栈大小最终设为4096字节。内存泄漏在FinSH中使用list_mem命令在长时间运行前后对比total memory和used memory。如果used memory持续增长说明有动态内存没有释放。重点检查协议解析中rt_malloc和rt_free是否成对出现特别是在错误处理分支上是否也正确释放了内存。中断冲突如果你使用了SPI DMA或者UART DMA并设置了高优先级中断可能会影响RT-Thread的系统滴答定时器SysTick中断导致调度器出问题。检查中断优先级配置确保SysTick中断的优先级不是最低的但也不能最高其他外设中断优先级合理。5.4 烧录速度慢生产效率低现象烧录一个8MB的镜像要两三分钟产线抱怨。优化增大数据包将协议中的数据包长度从512字节提升到1024甚至2048字节减少协议头尾开销和通信往返次数。但要同步增大下位机的接收缓冲区。使用Quad SPI如果MCU和FLASH都支持将SPI切换到4线模式理论上速度可提升近4倍。这需要修改驱动在读写命令前后发送相应的“进入Quad模式”指令如0xEB代替0x03进行快速读。优化擦除策略如果每次烧录的固件都覆盖整个FLASH且FLASH容量不大如8MB以下可以考虑使用“块擦除”64KB代替“扇区擦除”4KB。擦除次数减少总时间会缩短。但前提是固件布局必须对齐到块边界。上位机多线程在上位机可以使用生产者-消费者模型一个线程负责读取文件并分包另一个线程负责发送和接收应答实现“流水线”操作减少等待时间。5.5 量产时的实用技巧烧写器固件版本管理在固件中定义一个版本字符串如Programmer V1.2.1并通过响应“连接”命令返回给上位机。上位机软件可以检查版本号确保与烧写器固件兼容。日志与追溯在上位机软件中为每一次烧录操作生成一个日志文件记录产品序列号如果通过扫码枪输入、烧录的文件、校验结果、开始结束时间等。便于后续质量追溯。夹具与防呆设计制作一个简单的烧录夹具通过探针或顶针连接目标板的SPI和电源引脚。夹具上要有明确的定位槽防止板子放反。烧写器主机通过一个GPIO控制夹具上的电磁铁或锁扣只有板子放到位了才开始供电和烧录。一键烧录将整个上位机操作流程封装成一个批处理脚本.bat或Shell脚本产线工人只需双击脚本插入产品脚本会自动检测串口、执行烧录、显示结果成功/失败。将复杂度隐藏在后台。这个基于RT-Thread的SPI FLASH烧写器项目从构思到稳定运行花了我差不多一个月的业余时间。最大的收获不是做出了一个工具而是在这个过程中对RT-Thread的多任务机制、SPI底层通信、以及如何设计一个可靠的工业通信协议有了更深的理解。现在这个烧写器已经在我们的小批量产线上稳定运行了大半年烧录了上千片板子没出过岔子。如果你也面临类似的需求不妨动手试试这个过程绝对值得。
