1、双Bank架构概述：什么是双Bank Flash、为什么需要双Bank、双Bank与单Bank的对比
大家好，我是你们的嵌入式Bootloader课程讲师。今天咱们来聊聊双Bank架构。
说实话，我刚入行那会儿，用的都是单Bank Flash。那时候做OTA升级，心里总是悬着一块石头——万一升级过程中断电了，设备就成砖了。后来接触到双Bank架构，才算是找到了一个靠谱的解决方案。
什么是双Bank Flash？
双Bank Flash，说白了就是把一块Flash存储空间，从逻辑上分成两个独立的区域。每个区域叫做一个Bank。
举个例子，你有一块2MB的Flash。单Bank模式下，它就是一块完整的2MB空间。双Bank模式下，它被分成两个1MB的Bank——Bank A和Bank B。
这两个Bank有什么特点呢？
- 独立可寻址：每个Bank都有自己的起始地址和结束地址
- 独立可擦写：擦除一个Bank时，不会影响另一个Bank的数据
- 独立可执行：CPU可以从一个Bank运行代码，同时往另一个Bank写入数据
核心要点：双Bank Flash的本质，就是「读写分离」和「备份机制」的结合。一个Bank跑程序，另一个Bank做升级，互不干扰。
为什么需要双Bank？
你想想看，嵌入式设备最怕什么？最怕升级失败变砖头。
单Bank模式下，升级流程是这样的：
- 擦除整个Flash
- 写入新固件
- 校验新固件
- 重启运行
问题出在哪？如果第2步写到一半断电了，或者校验失败了，你的设备里就只剩下一堆乱码。设备再也起不来了。
双Bank架构就是为了解决这个问题而生的。它的核心思想是：永远保留一个可运行的固件副本。
我在一个智能家居项目中就遇到过这种情况。客户的产品部署在偏远地区，OTA升级失败率高达5%。用了双Bank方案后，失败率降到了0.1%以下。那些失败的案例，设备也能自动回滚到旧版本，完全不需要人工干预。
双Bank与单Bank的对比
咱们用一张表格来直观对比一下：
| 对比维度 | 单Bank Flash | 双Bank Flash |
|---|---|---|
| 升级安全性 | 低，升级失败可能变砖 | 高，失败可回滚 |
| 可用存储空间 | 100% | 约50%（另一半做备份） |
| 升级流程复杂度 | 简单 | 中等，需要管理Bank切换 |
| 固件回滚能力 | 不支持 | 支持，硬件级回滚 |
| 硬件成本 | 低 | 略高（需要更大Flash或双Flash） |
| 典型应用场景 | 一次性烧录、无需升级 | OTA升级、远程维护 |
我的建议：如果你的产品需要远程升级，别犹豫，直接上双Bank。省下来的售后成本，远比你多花的那几毛钱Flash成本要多得多。
双Bank的两种实现方式
嗯，这里要注意，双Bank不是只有一种玩法。根据硬件支持程度，我把它分成两类：
1. 硬件双Bank
有些MCU内部Flash本身就支持双Bank模式。比如STM32L4系列、NXP的LPC55系列。你只需要配置一个寄存器，Flash就自动分成两个Bank。切换Bank时，硬件自动处理地址映射。
这种方案最省心，代码量也最少。我建议能用硬件双Bank就用硬件双Bank。
2. 软件双Bank
如果你的MCU不支持硬件双Bank，也别灰心。我们可以用软件模拟：把Flash分成两个逻辑区域，自己管理Bank切换逻辑。
我曾经在一个STM32F103的项目上就这么干过。F103不支持硬件双Bank，我就把512KB Flash分成两个256KB的区域。虽然代码复杂了点，但效果一样好。
避坑指南：软件双Bank要注意地址映射问题。切换Bank后，中断向量表、链接脚本都需要相应调整。我曾经因为忘了改中断向量表，调试了整整两天才发现问题。
什么时候该用双Bank？
我个人的经验是，满足以下任意一条，就该考虑双Bank了：
- 产品需要远程OTA升级
- 设备部署在难以现场维护的地方
- 升级失败会造成严重损失（比如医疗设备、工业控制器）
- 客户对设备可靠性有明确要求
反过来，如果你的产品是一次性烧录、永远不升级的，或者升级失败影响不大，那单Bank完全够用。没必要为了用双Bank而用双Bank。
好了，这一章的内容就到这里。下一章咱们会深入讲解双Bank的硬件设计细节，包括Bank划分、地址映射、以及如何选择合适的分区大小。到时候我会分享一些我在实际项目中踩过的坑，希望能帮大家少走弯路。