search

BossHobby / QUICKSILVER

Flight Controller Firmware
MIT License
171 stars 40 forks source link

feature-looptime-autodetect todo list #26

Closed NotFastEnuf closed 3 years ago

NotFastEnuf commented 4 years ago

  1. 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

  2. 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

bkleiner commented 4 years ago

concerning 2) i think i'm in favor of adding a osd warning. probably alongside a gyro temperature warning.

NotFastEnuf commented 4 years ago

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

NotFastEnuf commented 3 years ago

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

NotFastEnuf commented 3 years ago

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.