BetaFlight统一硬件资源抽象设计

Posted 2023-02-05 lida2003

BetaFlight统一硬件资源抽象设计

• 1. 源由
• 2. 资源配置注意事项
• 3. 资源配置文件修改验证步骤
• • Step 1：确认硬件修改内容
  • Step 2：资源配置文件修改
  • Step 3：验证配置文件
  • Step 4：提交资源配置文件PR
• 4. 参考资料

就笔者接触嵌入式设计以来，简单的来说可以分为几个阶段：

1. MCS51汇编语言应用编程
2. 单片机C语言应用编程
3. 基于微系统C语言应用编程
4. 基于(微、宏、混合)内核C语言驱动和应用编程
5. 基于Unix like(Linux)应用系统的Python/Scripts/OpenCV/QT/C/C++/Java等等应用、算法编程

• 1. 2)通常是面向过程的开发，更多专注于业务的过程化设计；
• 3. 4)系统架构设计上已经面向对象，OS设计层面已经面向对象(驱动)，模块化(内存管理，任务管理等)设计；
• 5. 已经非常上层的应用编程，注重业务，算法，逻辑；计算机科学学科在这方面有大量内容，百花齐放百家争鸣；

这里说了这么多阶段性的东西，整体上还是想简单捋一下，从嵌入式的角度，如何将业务层层设计，并最终一步一步的落实到物理世界的。

很多问题的分析不仅仅要从局部入手，更要从全局，甚至要有长期布局的思路。

这里就不展开，否则话太多，离题了。通常来说，从设计角度看：

1. 紧耦合：高复杂度；强依赖性；全局性资源；占用资源最少；
2. 松耦合：模块化接口；弱依赖性；资源独立；占用资源一般；
3. 不耦合：高度抽象模块；设计独立；接口标准；占用资源一般；

1. 源由

BetaFlight的代码最初clone过来时，也是继承了嵌入式代码一贯的target目标板设计思路；也就是说，针对每个板子有一份对应的目录，有对应的target代码，比如：芯片、板子初始化等代码。

但是从实践的角度看，会存在以下一些问题：

1. 硬件目标板需要通过代码适配；
2. 硬件制造厂家不一定具备软件开发人员(业务上决定)；
3. 硬件设计人员不接触或者非常少接触代码，不具备或者不习惯软件开发环境和技能；
4. 硬件制造厂家很多，而软件代码开发维护人员数量有限；
5. 为保证开发团队对代码设计全局把控和掌控能力；并要求设计简洁且易于维护，需要减少由于操作异常而投入的额外维护工作量；
6. 事实上硬件厂家也已经加入到开源社区(虽然他们的硬件设计资料并不一定开源，但是需要从某种角度与开源软件一起携手并进)；

鉴于上面诸多因素(有些可能我也没有概括全，也许说的也不够到位)，BetaFlight开发团队与2019年开始引入硬件资源描述配置文件与软件代码进行抽象和解耦，详见4.0.0发布信息。

注：鉴于目前BetaFlight的设计都是基于STM32系列的MCU，所以从工程框架的角度来看，并没有支持其他MCU的工程结构目录，比如：AT32（雅特力芯片）。鉴于国际市场芯片短缺问题，开发团队确实已经开始类似准备工作。
【1】 Source file re-arrangement for better separation of MCU types #12268
【2】AT32 development, introduction of AT32F435 target #12247
【3】AT32F435/7 Libraries (#12158) #12263

鉴于软件代码成熟度的提高，其应用范围日益扩大，当前SITL/STM32可能并不能完全满足要求，后续对硬件仿真HITL(Hardware in The Loop) simulation #12212的支持也需要纳入考虑，以便更广泛的应用。

2. 资源配置注意事项

1. 飞行控制器制造商设计指南
2. 新增或更新硬件资源配置文件方法

注1：截止目前BF 4.4版本，所有BetaFlight现有STM32板子已经全部支持统一硬件资源抽象(如下图所示，BetaFlight飞控代码仅与MCU型号挂钩，而硬件设计被解耦到unified-targets硬件资源配置文件中。

注2：具体内容大家就看链接，不做翻译了。

3. 资源配置文件修改验证步骤

目前，BetaFlight上有大量的硬件设计厂家，以及各种STM32的飞控板子，因此通常来说新设计的硬件也是在原有基础上进行修改。

这里基于这种思路我们整理下资源配置文件修改的步骤，关于PR合入请详细阅读新增或更新硬件资源配置文件方法里面关于“如何与开源BF开发人员合作事宜”。

Step 1：确认硬件修改内容

与硬件设计人员确认硬件上修改的内容，获取相应格式文档交付件。

1. PDF原理图
2. 硬件改动说明（芯片改动，pin脚改动，IMU方向等）
3. 参考飞控型号、规格书

Step 2：资源配置文件修改

根据Step 1的交付件和 新增或更新硬件资源配置文件方法修改资源配置文件

1. 确认当前产品型号、规格
2. 确认当前产品型号需要兼容的规格（比如：后续硬件可能的改动）
3. 找到参考飞控资源配置文件，针对改动修改配置文件

Step 3：验证配置文件

根据Step 2的交付件和测试样机进行功能验证

1. 当前产品飞控内部芯片功能验证
2. 当前产品飞控引出pin脚功能验证
3. 当前产品飞控飞行性能测试验证
   提供最终测试结果：若测试不合格返回Step 1 or Step 2；

Step 4：提交资源配置文件PR

根据 新增或更新硬件资源配置文件方法提交PR

4. 参考资料

【1】BetaFlight开源代码框架简介
【2】Betaflight硬件产商指南
【3】Betaflight 4.0.0 Release Note