Support reversible mask in iomcu

[andyp1per]

We were sending the command but not coping when actually sending the dshot packet

[tridge]

I think we also need the armed state? so we can send dshot value 0 when disarmed. Not doing that for 3D ESCs is dangerous
We have the flag P_SETUP_ARMING_FMU_ARMED left over from earlier versions of IOMCU but we don't seem to use it, I think we need to check hal.util->get_soft_armed() and send that flag over to the IOMCU, otherwise reversible ESCs are too dangerous

Note we do this:

so on FMU we do send 0 always when not armed, on IOMCU we don't as far as I can see

[andyp1per]

I think we also need the armed state? so we can send dshot value 0 when disarmed. Not doing that for 3D ESCs is dangerous We have the flag P_SETUP_ARMING_FMU_ARMED left over from earlier versions of IOMCU but we don't seem to use it, I think we need to check hal.util->get_soft_armed() and send that flag over to the IOMCU, otherwise reversible ESCs are too dangerous

Note we do this: so on FMU we do send 0 always when not armed, on IOMCU we don't as far as I can see

Good catch! Now I understand why @bugobliterator commented this out on IOMCU. It's a little more subtle as the armed state needs to be propagated as well, but certainly doable.

[andyp1per]

I verified with a Saleae that:

• disarmed + safety - no output
• disarmed + safety disabled - zeros output
• armed - zero throttle output

[tridge]

minor changes, but main problem is that the resulting DShot signal is wrong on IOMCU, it is idle high whereas DShot is supposed to be idle low

[tridge]

testing on Pixhawk6x-bdshot with Sub, with 10% throttle:

OUT1 is IOMCU, OUT9 is FMU
note that the signal is idle-high on IOMCU, and AM32 doesn't recognise it:

[andyp1per]

I have now tested this successfully on a CubeOrangePlus

[tridge]

@andyp1per I've been testing this with both BLHeli32 and AM32 ESCs on a Pixhawk6X-bdshot board, testing with rover
It all works on FMU, but on IOMCU we never send the command code to set the ESC to 3D mode.

[rmackay9]

I discussed with @andyp1per and it only affects rover and sub and he thinks it's best that we wait for 4.6 which will start beta testing soon anyway

[xfacta]

I've got a result and a fail - the SERVO_BLH_RVMASK now works BUT the bitmask seems to be mapped randomly to servo channels or motor positions. Using a Quad X8 I couldnt tell what bit would affect which motor without first testing all individually.
When I last used SERVO_BLH_RVMASK it was on a FC without IOMCU and I seem to remember the "bitmask channels" aligned to the Servo channels regardless of which motor function was assigned to which servo channel.

RCOut: DS300:1-8 PWM:9-13
IOMCU: 420 1001 411FC231
CubeOrange 00330033 3131510E 31363832
ChibiOS: 88b84600
ArduCopter V4.6.0-beta1 (8d4976c)

I am using the standard Octaquad (X8) motor positions and wiring, to the Main Out servo connections as follows:

Letter Servo Dir needs reversing
A 1 CCW
B 6 CW reverse
C 4 CW reverse
D 7 CCW reverse
E 3 CCW
F 8 CW
G 2 CW
H 5 CCW

Tests of each bitmask value produced:
bitmask "channel" (decimal value) => letter/servo ch
1 (1) => D 7
2 (2) => C 4
3 (4) => E 3
4 (8) => F 8
5 (16) => G 2
6 (32) => H 5
7 (64) => A 1
8 (128) => B 6
which appears to have no relationship, such as bit 0 mapping to Servo 1 would be nice and logical.

I had to use this bitmap to reverse motors B/6 , C/4 , D/7, => 1,2,8 bitmask for SERVO_BLH_RVMASK,131

I would have expected 4,6,7 = SERVO_BLH_RVMASK,104 decimal