what cleanflight firmware for seriously dodo fc

What cleanflight firmware for seriously dodo fc serial#
What cleanflight firmware for seriously dodo fc full#
What cleanflight firmware for seriously dodo fc code#
What cleanflight firmware for seriously dodo fc plus#

To this end, some developers have been discussing Taylor approximations of our trigonometry routines over on the Cleanflight issue tracker. The default implementation is extremely pedantic about being precise and handling error conditions in order to conform to IEEE floating point standards, but in a noisy system like a quadcopter that precision isn’t noticeable. One way of doing this is to use routines which are slightly less precise than the default implementation, which can bring large speedups. One option is to speed up the floating point routines themselves. But can I squeeze more speed out the Naze32? There are two main approaches here. So, the SPRacingF3 is likely faster than the Naze32 because its floating point operations are faster. This information is a win for developers because we don’t need to waste our time on something that isn’t going to make a difference to looptimes! Speeding up the Naze32 It’s clear that it’s not worth speeding up any other part of the code, because the remainder accounts for such a small percentage of the total runtime.

What cleanflight firmware for seriously dodo fc code#

I haven’t examined this code before, but from a quick glance it appears that the CPU performs a busy-wait while it waits for a response to be received from the gyroscope. If this task could be handed off to the DMA controller, which would perform the read in the background, it could potentially free up to 36% of the CPU time for other tasks. Of the remaining time, 36% is spent just waiting to receive data from the gyroscope over the I2C bus.

This is great news for the SPRacingF3 because these are precisely the routines that will be sped up by its hardware floating point unit!

What cleanflight firmware for seriously dodo fc plus#

You can see that the majority of runtime is spent on floating point routines (48%) plus trigonometry routines (5%), which are the likely callers of most of the floating point routines.

What cleanflight firmware for seriously dodo fc full#

I was running a Naze32 Full with a PPM receiver, PID controller 0, looptime set to 0 and all other features disabled, so pretty much a barebones system. You can see the raw output from the profile log decoder here. I configured it this way because of the I2C documentation’s warning that the interrupt handlers should not themselves be interrupted (I assume they’re too timing sensitive). This is because the profiler is not high priority enough to interrupt them. The very highest priority interrupt handlers (I2C EV and ER interrupt handlers) are not measured by the profiler. It also means that functions which mostly just call other functions to do their work for them will have very low execution times as measured by the profiler. This can make it harder to work out which parts of the code are the culprits for slowdowns, because some routines are shared by many parts of the program. This profiler is somewhat limited because it can only see the top function that was executing when it takes a sample. It doesn’t currently have the ability to look up the stack and see which functions were responsible for calling the function that was interrupted. Our results will be the same, and CPU sampling overhead will decrease. If the profiler slows down the CPU too much, we only have to reduce our sampling rate and sample for longer. In this way we can construct an accurate picture of the program with a nice constant overhead. If one piece of code accounts for 30% of the execution time of the program, then we should expect 30% of our random samples to end up seeing that line of code being run. The checks can be used to measure what percentage of the time is spent on each line of code in the program.

What cleanflight firmware for seriously dodo fc serial#

The profiler makes 1000 of these checks per second and sends the results out to a serial port to be logged. A sampling profiler works by periodically interrupting the program’s execution to check what code is currently running. In order to find out, I built a Sampling Profiler feature for Cleanflight. It’s not heavily used in any other parts of the code.īut how much time does the Naze32 spend doing floating point operations anyway? What is the total possible speedup available from just adding a hardware floating point unit? Could I speed my Naze32 up some other way? Floating point support is used in the IMU (which is responsible for estimating the craft’s attitude) and also as part of some PID controllers such as the new Harakiri controller. One major difference between these CPUs is that the F3 has a hardware floating point unit, while the F1 must emulate its floating point support using some very large software routines.

I found this interesting because the F3’s CPU isn’t clocked any faster than the F1 processor that is used on the Naze32 and compatibles. With the recent release of the SPRacingF3 flight controller and the Seriously Dodo flight controller, both based on the newer STM32 F3 CPU, users have been posting great Blackbox flight logs demonstrating very fast and consistent looptimes.