BetaFlight统一硬件资源简单配置修改

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

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

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

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

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

1. 源由

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

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

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

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

BetaFlight统一硬件资源简单配置修改_第1张图片
注:鉴于目前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的支持也需要纳入考虑,以便更广泛的应用。

通常情况下,板子之间的差异性不是太大,可以通过现有板子配置文件进行修改。这里就经常使用到的统一硬件资源文件修改步骤做下整理和归纳,以便更好,更快的根据这个checklist进行工作。

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

你可能感兴趣的:(xFlight,stm32,BetaFlight)