Originally Posted by DroneBuilder
The firmware files were named "TGYPxxA2007v0100TwiNoCalM01.hex" and went through "TGYPxxA2007v0100TwiNoCalM08.hex" (of course, I only used 1 - 6).
The question I have is:
If you implement TC's i2c patch into your newer code (and maybe provide some hex files) would an improvement be realized? if so, I'd be glad to re-program mine. (I have not yet mounted them to a bird to test them in flight, I have only connected them and tested them in MKtools.)
If it starts properly and runs without timing loss, you don't care about the 8kHz PWM whine, and the 100 PWM (POWER_RANGE) steps aren't causing an issue (due to INT RC jitter or other noise that causes dithering anyway), then it may not matter.
I have made a few other changes, like always going with the latest received PWM instead of the first since the last check (slightly less lag), and it runs at 16MHz now even on the 8MHz boards, which doubles the PWM clock, allowing for ~10-bit PWM at 18kHz / ~11-bit PWM at 9kHz. This only matters if your flight controller outputs more steps, though.
The original kapteinkuk code works with -100 to 100 in 16.16, now 16.8 with the latest release, and then scales up to round microseconds without throwing away bits. Mike's C port just did all of the mixing with integers but still the same range, so was (is?) much more granular (steps of 4 microsconds during output). My fork does it in microseconds (steps of 1 microsecond) with 16-bit and 32-bit integer math, but hasn't been updated with the PI stuff yet, so kapteinkuk's assembler versions should be as good or better than this: https://github.com/sim-/kk