sbus output msp support

[gongtao0607]

Read:

    case MSP_SBUS_OUTPUT_CONFIG:
        for (int i = 0; i < SBUS_OUT_CHANNELS; i++) {
            sbufWriteU8(dst, sbusOutConfigMutable()->sourceType[i]);
            sbufWriteU8(dst, sbusOutConfigMutable()->sourceIndex[i]);
            sbufWriteS16(dst, sbusOutConfigMutable()->sourceRangeLow[i]);
            sbufWriteS16(dst, sbusOutConfigMutable()->sourceRangeHigh[i]);
        }
        sbufWriteU8(dst, sbusOutConfigMutable()->frameRate);
        break;

Write:

    case MSP_SET_SBUS_OUTPUT_CONFIG: {
        // Write format is customized for the size and responsiveness.
        // The first byte will be the target output channel index (0-based).
        // The following bytes will be the type/index/low/high for that channel.
        // `frameRate` is piggyback to any (all) indices for simplicity.
        if (sbufBytesRemaining(src) >= 1) {
            uint8_t index = sbufReadU8(src);
            if (index < SBUS_OUT_CHANNELS && sbufBytesRemaining(src) >= 7) {
                sbusOutConfigMutable()->sourceType[index] = sbufReadU8(src);
                sbusOutConfigMutable()->sourceIndex[index] = sbufReadU8(src);
                sbusOutConfigMutable()->sourceRangeLow[index] = sbufReadS16(src);
                sbusOutConfigMutable()->sourceRangeHigh[index] = sbufReadS16(src);

                // You need to reset FC after updating ->frameRate.
                sbusOutConfigMutable()->frameRate = sbufReadU8(src);
            }
        }
        break;
    }

[rotorflight]

I am not convinced that repeating the framerate parameter with every channel is the right thing to do.

[robthomson]

I have coded the unto deal with it... But maybe a better option is to not do msp frame rate changes.. And make that cli only?

Reality is that the default frame rate is probably perfect in 99.99% of cases.

[rotorflight]

Let's remove the frameRate from this MSP call. It's not correct to do it this way.

[gongtao0607]

I am not convinced that repeating the framerate parameter with every channel is the right thing to do.

It's just a compromise of simpleness and cleanness. I feel it's not super necessary to create a separate protocol for a single uncommon byte.

I have coded the unto deal with it... But maybe a better option is to not do msp frame rate changes.. And make that cli only?

Reality is that the default frame rate is probably perfect in 99.99% of cases.

I think we should keep all tunables available through MSP, so that when ready we can configure everything from the radio.

Remove frameRate from this MSP. Then it does not need reboot either.

This isn't solving the reboot issue. Reboot is not needed if I don't change the frameRate. It is needed when changed, regardless where (other MSP or cli).
This is because frameRate is read on init. The way to improve is to add rescheduleTask here too but this doesn't seem to follow other MSP conventions (MSP shouldn't care how the params are used)

[rotorflight]

Remove frameRate from this MSP.
Then it does not need reboot either.