Closed NotFastEnuf closed 3 years ago
concerning 2) i think i'm in favor of adding a osd warning. probably alongside a gyro temperature warning.
Those both sound good. The entire osd warning function needs a complete rework anyway. It was hastily thrown together to get a rough idea for what we might want in a system status warning feature... and then was ignored cause it sort of worked. I will prioritize cleaning that up and add these two new warnings
Warnings are in place.... Last thing to do is to work in an allowance for blackbox recording once that feature matures and to add any gui warnings/indicators that we might want
Autodetect seems to be doing its job. The last update to this has been muting the osd looptime warnings on the 8k to 4k switch. As it stands right now, the "watchdog" at the end of the loop is a bit more aggressive than the "averaging" we do on a sequence of loops to actually make a change. This is allowing some looptime gitter on boards with less optimal hardware configurations (multi gpio motor ports) who are on the edge of switching. As of now, it seems to be allowing a passable amount of gitter but can always be tightened up for more aggressive drop back to 4k.
looptime autodetect runs on boot and sets the fastest appropriate time for any fc. blackbox is our first upcoming feature which has a significantly different cpu load while armed vs disarmed. The autodetect sequence first runs while disarmed so it would make sense to "estimate" the additional load of blackbox while armed and include it in the autodetect comparison of average load to target looptimes so that we dont have to detect blown loops later and adjust on the fly
aside from the boot up looptime autodetect sequence, there is a second watchdog which is always running to check for blown loops. If 100 loops blow the target looptime by more than 5us .... autodetect will be triggered to run again. When this happens, autodetect may or may not make an adjustment - but if it is ever re-triggered to run, then looptime_warning variable will be incremented. We need to decide what to do with this variable. Put it in the state struct? add osd warnings? Or simply just sleep better cause we know it is there and use it for debugging only if we encounter a problem