Any option to use it with I2C to UART adapter like DFRobot DFR0627?

[OZZYcorexy]

Hello Cassandra,
trying to use you lib in my implementation for robot controlled by ESP8266 which have on fact only one UART used by USB and monitoring.
my current code is:
`
/* Arduino is included here for shits and giggles. */
#include <Arduino.h>

/* 1. Add Cassie Robinson's CRSFforArduino.h library. */
#include <CRSFforArduino.hpp>
#include <DFRobot_IICSerial.h>
DFRobot_IICSerial iicSerial1(Wire, /subUartChannel =/SUBUART_CHANNEL_1,/*IA1 = */1,/*IA0 = */1);//Construct UART1
//DFRobot_IICSerial iicSerial1;//Default constructor, UART1, IA1 = 1, IA0 = 1
DFRobot_IICSerial iicSerial2(Wire, /subUartChannel =/SUBUART_CHANNEL_2, /*IA1 = */1,/*IA0 = */1);//Construct UART2

/* 2. Declare a CRSFforArduino object with your board's default UART port.
You can call it literally anything you want. */
CRSFforArduino crsf = CRSFforArduino(&iicSerial1);

void setup()
{
Serial.begin(115200);
iicSerial1.begin(/*baud = */115200);/UART1 init/
//iicSerial1.begin(/*baud = */115200, /*format = */IICSerial_8N1);

iicSerial2.begin(/*baud = */115200);/UART2 init/
while (!Serial)
{
;
}
Serial.println("Channels Example");

/* 3. Start communicating with a connected ELRS receiver. */
if (!crsf.begin())
{
    Serial.println("CRSF for Arduino initialization failed!");
    while (1)
    {
        ;
    }
}

/* Pro tip: Always show a little message in the Serial Monitor to let you know that your sketch is initialized successfully. */
Serial.println("Ready");
delay(1000);

}

void loop()
{
/* 4. Update the main loop with new RC data. */
crsf.update();

/* 5. Here, you can do whatever you want with your RC channel values.
In this example, your RC channel values are printed to the Serial Monitor every 100 milliseconds. */
static unsigned long lastPrint = 0;
if (millis() - lastPrint >= 100)
{
    lastPrint = millis();

    Serial.print("RC Channels <A: ");
    Serial.print(crsf.readRcChannel(1));
    Serial.print(", E: ");
    Serial.print(crsf.readRcChannel(2));
    Serial.print(", T: ");
    Serial.print(crsf.readRcChannel(3));
    Serial.print(", R: ");
    Serial.print(crsf.readRcChannel(4));
    Serial.print(", Aux1: ");
    Serial.print(crsf.readRcChannel(5));
    Serial.print(", Aux2: ");
    Serial.print(crsf.readRcChannel(6));
    Serial.print(", Aux3: ");
    Serial.print(crsf.readRcChannel(7));
    Serial.print(", Aux4: ");
    Serial.print(crsf.readRcChannel(8));
    Serial.println(">");
}

}
`
and compilation fails on the line
CRSFforArduino crsf = CRSFforArduino(&iicSerial1);
with the errors like
error: no matching function for call to 'sketchLayer::CRSFforArduino::CRSFforArduino(DFRobot_IICSerial*)'
13 | CRSFforArduino crsf = CRSFforArduino(&iicSerial1);
| ^
In file included from C:\RABOCHIJ\nini tank\Arduino kod\CSRF_ZZCAT\CSRF_ZZCAT.ino:5:
c:\RABOCHIJ\nini tank\Arduino kod\libraries\CRSFforArduino\src/CRSFforArduino.hpp:39:9: note: candidate: 'sketchLayer::CRSFforArduino::CRSFforArduino(HardwareSerial*)'
39 | CRSFforArduino(HardwareSerial serialPort);
| ^~~~~~~~~~~~~~
c:\RABOCHIJ\nini tank\Arduino kod\libraries\CRSFforArduino\src/CRSFforArduino.hpp:39:40: note: no known conversion for argument 1 from 'DFRobot_IICSerial' to 'HardwareSerial*'
39 | CRSFforArduino(HardwareSerial *serialPort);

[ZZ-Cat]

Yea, you're trying to use I²C with CRSF for Arduino, which is not yet supported.

Currently, I am cleaning CRSF for Arduino's codebase up, then carrying on with writing documentation, which are the last two things I need to do before I release Version 1.0.0.

In the meantime, can you jump into my Issues tab and submit a feature request for I²C support?

I see you're also compiling for an ESP8266, a target that is not yet supported by CRSF for Arduino.
If you used the default constructor and compile-tested CRSF for Arduino with your ESP8266, the Compatibility Table will cause compilation to fail, due to the architecture not being supported.
If this happens, you may need to submit a compatibility request for your ESP8266, provided it meets the minimum requirements.

Keep in mind that the aforementioned may not make it into the upcoming release of Version 1.0.0, because I am already im the process of finalising its release. Your requests will be included in one of CRSF for Arduino's MINOR releases after I have released MAJOR Version 1.0.0.

[OZZYcorexy]

indeed i got that architecture issue when tried to compile without I2C.
the way how i'm thinking about this library it would be great to have support on other devices even those which can't go to 420k baud on the hardware uart. recently discovered that elrs receivers can be downscaled for example to 115200 which makes a perfect use case for folks who do have typical radio and wants to use it to control some kid toys or custom projects (i.e. like me :) but having some brain in between radio and controlled device.
this is also introduces the reason to be able to pick any defined uart port, software, i2c, spi etc
i have esp32 next to me so will raher port there and leaving those thoughts with you. as i'm not a experienced programmer unfortunately can't contribute much

[ZZ-Cat]

All good. Hardware testing is usually my main port-of-call for most folks, especially when they request new targets.

The amount of targets I have available on hand are all SAMD21 and SAMD51 based.
So, I usually ask for their assistance to help make sure the codebase compiles and works as intended for their new target.

I see that with ExpressLRS receivers, which is fantastic. The other limitation is the memory footprint. Even if your target has 32 KB of flash memory available for uploading your sketches, CRSF for Arduino can take up to a good 55 % of that space, and that's before you bring in stuff like flight modes, and telemetry.
This means that targets with 16 KB of flash memory are off-limits, even with the optimisations that are already in place.

From what I understand of the protocol and the general consensus from developers of ExpressLRS, Betaflight, and TBS' own FreedomTX etc is thar pretty anal about the baudrate. Something to do with latency in the order of one or two milliseconds to a few tens of microseconds. What makes this even more hilarious is, there's a lot of discrepancies between agreed-upon baudrates:

• Betaflight: 420,000
• INAV: 420,000
• RotorFlight: 420,000
• ExpressLRS: 420,000
• EdgeTX: 400,000 (base baudrate, by the way, and can go all the way up to 1,000,000)
• The Crossfire Protocol: 416,666 (Trappy, plus a handful of others claim this is the "official" baudrate)
• Ardupilot: 416,666 (apparently they "worked closely" with Team BlackSheep to get this "correct")
• KISS: 400,000 (Dude. Really?)

The real funny part is, 420,000 talks to 416,666 with impunity, and 400,000 talks to 416,666 and 420,000 with impunity; and none of the developers of the aforementioned can agree upon the baudrate that The Crossfire Protocol (AKA CRSF) is supposed to use.
The only reason why people remember 420,000 as opposed to 416,666 is because it reminds them of the "420. Blaze it!" meme.

It would be all too easy for me to pass in your chosen baudrate as a parameter for CRSFforArduino::begin(), and have that trickle down to about the Serial Receiver Layer where the UART object gets configured. It's literally a 2 minute job, for me; and I don't see any reason why you shouldn't be able to do that.

Fortunately for you, I'm not anal about the baudrate. All I care about is whether-or-not CRSF for Arduino works for you (and everyone else in my userbase) in a meaningful way; and honestly? I'd love for you (and other users of legacy hardware) to have access to this amazing RC and telemetry protocol.
If accommodating that means having a slightly lower baudrate (what makes about 🤏 that much of a difference in terms of "latency" and performance) for those targets? Then, it shall be done.

I²C is an interesting one.
I checked the documentation of CRSF, and currently, the I²C implementation is not well-known beyond having the sender's bus clock speed set to 100 kHz.

SPI isn't even available in the official Crossfire Protocol documentation, yet many all-in-one flight controllers (especially for TinyWhoops) use SPI as the transport layer for CRSF.

[OZZYcorexy]

sounds cool, and really appreciate efforts you doing.
the reason why i can't make changes myself is because i'm not understanding at least half of what is in there :D and googling gives a way too much things which can take learning in opposite direction.
I2C is indeed interesting bus and in theory it can go high clock like 3,4M, and that specific DFRobot converter can go up to 1M baud on output uart, this is why i'm coinsidering super cheap 8266 + I2C->UART converter as a great option even if i have to downscale it to 115k baud. (remember FRSky have only 50hz refresh "LOL" and it's flyable)
as a worse case i always can try to switch elrs receiver to sbus (SUMD) mode or so and try those libs with external I2C to uart
For SPI i was rather meaning another converter like SPI->UART because formal SPI receivers are not much present on market.
I see you're maybe targeting more towards "custom fly controller" -ish thing where many good solutions are already in place and allowing extreme customization out of the box, this is why i'm seeing more usability in custom projects.
anyway, i'm not giving up on this :)