Initial vtx support (IRC Tramp)

[bsvdoom]

This PR is based on #159 , adding support for the VTX IRC Tramp protocol.

I could not test it yet, and I need some help first:
-Please review
-How and where to set the _model.config.vtx.protocol from the MSP Ports page?
-Other functions seems to work, but not tested
-Can we move this to optionally use SOFTSERIAL? GPS is better on UART IMO.

[rtlopez]

Cool :)

1. if you split Vtx class into two separate classes VtxSmartAudio and VtxTramp then you won't need protocol parameter
2. MSP protocol paramter is required in MSP_VTX_CONFIG only, this parameter is not sent back in MSP_SET_VTX_CONFIG, you can add variable to ModelState instead and assign value in SerialManager::begin()
3. from what I see, crc8 is equivalent to Utils::crc8_dvb_s2(), I think we can replace it in both versions
4. There is no SoftSerial device implemented yet, there are many imlpementations on the Internet, but all of them uses delay based bitbang busy-loop. But we can't afford to block the thread for so long. We need alternative implementation based on some hardware features like I2S/RMT/SPI or Timer interrupts. Let's leave it for now, as it doesn't seem easy job. On the Esp32-s3 technically we have all 3 uarts available to use, as configuration is done via USB, that is enough to use RX, GPS and VTX at the same time.
5. It would be nice if you test it on some real hardware :)

[bsvdoom]

All done, I will try to test Tramp in the weekend..
Please verify that crc8_dvb_s2 migrations are correct or not.

[rtlopez]

@bsvdoom looks perfect, let me know about test results, thanks a lot :)

[bsvdoom]

@rtlopez so I've tested it, and it does not work.
Attached an analyzer, this is the result:

Any ideas, why the values mismatch?
It is also strange, that the 2nd byte should be 00, but it is 80 instead, but from 4th byte the 00 is correct.

I could not set the stop bits to 2, but I doubt that is the error.

Same goes to the set channel/power:

[rtlopez]

@bsvdoom I think that logic analyzer decoded frames incorrectly, trace looks fine for me. I have no idea why this happens, but options presented on screenshot do not match setting in code. However I compared your implementation with BF, and see some major diferrences

1. your frame structure is diferrent, in BF it is <sync start><command><payload[12]><crc><sync stop> see here https://github.com/betaflight/betaflight/blob/master/src/main/io/tramp_protocol.h#L56
2. also BF uses diferrent crc algorithm, see this https://github.com/betaflight/betaflight/blob/master/src/main/io/tramp_protocol.c#L36

Can you tell which specification or implementation did you based on?

[rtlopez]

@bsvdoom small update, in previous comment I referenced probably dead code. Actuall implementation is here https://github.com/betaflight/betaflight/blob/master/src/main/io/vtx_tramp.c#L143, nevertheless looks identical.