BetaFlight飞控启动&运行过程简介疑问跟踪
BetaFlight飞控启动&运行过程简介疑问跟踪
- 1. 源由
- 2. 【已解+存疑】问题一：6.1 Why desiredPeriodCycles is so important to Betaflight task?
- 3. 【已解】问题二：6.2 What root cause has made gyro task to been overrun, so scheduler has to skip a gyro cycle?
- 4. 【已解】问题三：6.3 What if serial task is running quite long, which corrupt gyro cycle, is it a problem?
- 5. 【已解+存疑】问题四：6.4 What does the condition of "scheduleCount & SCHED_TASK_DEFER_MASK == 0" stand for in scheduler?
- 6. 总结
- 7. 参考资料
1. 源由
之前研读BetaFlight飞控启动&运行过程简介提出了四个问题，该问题也在BetaFlight开发组内进行了咨询和讨论。
针对这些问题，这里做一个统一的进度跟踪和答案的整理。
2. 【已解+存疑】问题一：6.1 Why desiredPeriodCycles is so important to Betaflight task?
Let’s say default desiredPeriodCycles is about 8K, which 125us. And the code still check desiredPeriodCycles by GYRO_RATE_COUNT interrupts, what’s the story here?
If sample rate is NOT sync with gyro task, there might be dirty/invalid data, is there any bad thing happens if just missed 1 or 2 valid samples?
Or this code only tends to logically eliminate this effective data sampling bias?
目前获取gyro数据大致有两种方式
- CPU控制的SPI总线通信
- DMA控制器SPI总线通信
总体来说，DMA控制器可以节省系统资源(CPU,总线,内存等)。
注：这里通过CPU控制的SPI总线通信来获取gyro数据的过程我们就不在赘述，因为那比较容易理解。
为了更好的利用DMA控制器，scheduler做了一个精准对时的操作。
其有以下几个主要动作：
- 通过物理中断记录传感器数据有效时间: mpuIntExtiHandler/gyro->gyroLastEXTI/GYRO_RATE_COUNT(25000)
- 通过DMA回调记录内存数据有效时间: mpuIntcallback/gyro->gyroDmaMaxDuration
- 通过terminalGyroRateCount(GYRO_RATE_COUNT)更新一次desiredPeriodCycles
- 通过terminalGyroLockCount/GYRO_LOCK_COUNT(50)做了一个指数级时刻同步回归
- 通过SCHED_START_LOOP_MIN_US/SCHED_START_LOOP_MAX_US/schedLoopStartCycles(SCHED_START_LOOP_MIN_US)做一个弹性边界控制
目前从提供的逻辑分析仪给出的有限时间分析看mpuIntExtiHandler/mpuIntcallback/mpuGyroReadSPI的时刻点没有太多问题。
疑问：
从实际截图看，gyro中断mpuIntExtiHandler并不规则等时间段分布，存在较大的偏差。
是否可能存在desiredPeriodCycles存在偏差时正好出现mpuGyroReadSPI在mpuIntcallback时刻之前。
鉴于目前gyro数据尚不是double buffer配置，所以如果出现上述情况，可能导致gyro脏数据或者前一次采样数据的情况发生。
注：截图来自参考资料【2】。
3. 【已解】问题二：6.2 What root cause has made gyro task to been overrun, so scheduler has to skip a gyro cycle?
As scheduler comments "A task has so grossly overrun that at entire gyro cycle has been skipped, especially via USB as the serial.
Is there too much serial communication through bf configurator and FC or just USB-VCP code on FC side take a lot of resources?
It’ll be the same issue when switching to TTL comunication with FC (suggest test bf-configurator <> usb_serial convertor <> FC(UART1 for example)?
该情况主要出现在USB VCP数据传输导致的问题。主要场景是电脑配置工具通过USB与飞控相连进行配置。
当仅仅使用串口进行通信无上述问题。
4. 【已解】问题三：6.3 What if serial task is running quite long, which corrupt gyro cycle, is it a problem?
As previous discussion on “Why desiredPeriodCycles is so important during Betaflight task?”
e.g. use MSP protocol as communication channel with companion computer
==> there are lots of packets, result in long time processing.
==> if this happens, it seems mess up with the gyro cycle, am i right? is there any solution or way to overcome this issue?
Code
如前面问题二所述，目前看上述情况不存在问题。
5. 【已解+存疑】问题四：6.4 What does the condition of “scheduleCount & SCHED_TASK_DEFER_MASK == 0” stand for in scheduler?
Code
There are three scenarios for normal(except gyro/acc/pid) tasks to execute:
- taskRequiredTimeCycles < schedLoopRemainingCycles // there is time for task to execute.
- scheduleCount & SCHED_TASK_DEFER_MASK == 0 //???
- (task - tasks) == TASK_SERIAL // ok, special case for serial
So what’s for case #2 “scheduleCount & SCHED_TASK_DEFER_MASK == 0”
为了处理RC代码表现不佳的事实，花了很多时间在它的检查程序上，时间非常不可预测。
疑问：
该具体场景为给出答复。显然可能存在一些异常问题，需要更加明确澄清。
6. 总结
上述问题基本已经得到回复，虽然有些问题尚有存疑部分。显然很多历史的问题，并不一定都是能寻根究底的。我们暂且考一段落，希望能有更加明确的场景和rootcause给出，以便工程角度更好的分析和定位问题。
这也是我通常比较强调的为什么很多事情要搞清楚rootcause的原因。相信上面的问题是有这些内容的，但是需要挖掘出来，需要和真正处理的当事人非常紧密和深入的探讨。当然这样也就为后面设计和重构提供了基础。
7. 参考资料
【1】BetaFlight飞控启动&运行过程简介
【2】Perform SPI read of gyro/acc using DMA triggered by EXTI interrupt #10573