Plane: ensure the dshot type gets set

[andyp1per]

When in plane only mode the dshot type was not getting set late enough meaning that BlueJay ESCs would not work.

I worry that RC speed also does not appear to be being set.

[tridge]

@andyp1per the main thing with the ordering is for IOMCU. Can you please check this works with a plane with Q_ENABLE=0 both on main and aux outputs on a board with an IOMCU?

[andyp1per]

Verified on a CubeOrangePlus MAIN1 with BlueJay

[IamPete1]

Why is the existing setting in AP_BLHeli not sufficient? If it does not work there should we remove it? What about all the other setup that is done in AP_BLHeli init function, does that work correctly?

Setting the same thing in two places seem like a recipe for future bugs to me.

[andyp1per]

Why is the existing setting in AP_BLHeli not sufficient? If it does not work there should we remove it? What about all the other setup that is done in AP_BLHeli init function, does that work correctly?

Setting the same thing in two places seem like a recipe for future bugs to me.

There already were many previous bugs related to this. The blheli stuff was always done lazily which was one of the problems. I really have no interest in trying to prove whether the call is safe to remove in blheli - far too much time spent in those codepaths already!

[IamPete1]

Maybe you could at least explain why this fix works and the current code does not?

[andyp1per]

Maybe you could at least explain why this fix works and the current code does not?

I can tell you the symptoms that this fixes. The current code ends up setting the dshot output frequency using the default bitwidths rather than the blheli_s bitwidths, but at some later(?) point the correct bitwidths are set and you end up in this situation where the bitwidths being used are not the same as the ones that were used for the frequency calculation.

As to the exact interaction that causes this - I have no idea. Note that copter sets the output mode together with this a couple of times - and always has - and that's why it gets the correct values at the right time (see AP_Motors::rc_set_freq).

It's possible that simply by moving the call up in AP_BLHeli that might also work.