Version 1.0.0 is just around the corner

[ZZ-Cat]

Holy shit, this has been a journey and a half! =/)/,..,(\=

#61 is nearly complete.
Now, all that's left to do is write the documentation of CRSF for Arduino in the Wiki, update the README.md to reflect all the latest changes.
Yes, this includes the removing the long-standing joke about the pigeon flying by swinging their head around in circles, because CRSF for Arduino has evolved to the extent that the pigeon is now flying by using their wings.

CRSF for Arduino trivia

When I first started CRSF for Arduino, I did it out of pure spite.
I had an idea for several RC projects, and the only options what were available to me at the time were only variations of extrapolating signals from PWM receivers, using pulsein() or pin-change interrupts (which took up valuable pin real-estate) and hoping for the best.

There were (and still are) other CRSF implementations, including the one that ExpressLRS developers themselves recommend to anyone and everyone in their Discord server. However, many of these implementations focus exclusively on the RC channels aspect of The Crossfire Protocol and seemingly nothing else.
Even then, the implementations were 4~5+ years old - IE Their last commit was c.2019 or older, and didn't support newer hardware.

Advantages CRSF for Arduino brings to the table

CRSF for Arduino has numerous advantages over other implementations

The biggest advantage here is the use of telemetry, flight modes, and custom flight modes.
The telemetry implementation uses every telemetry packet in The Crossfire Protocol.
Flight modes are based on the Flight Modes from Betaflight 4.3.
Custom flight modes allows you to create a custom mode and you provide the name as a text-based string, then send that back to your controller.

Every effort has gone in to making CRSF for Arduino operate as fast as it can

This is why I have elected to make the entire library "Event-based" using callback functions for RC channels and Flight Modes as opposed to variations of the read() function after polling for whether-or-not the thing was updated.

This is also why I highly recommend you place CRSF for Arduino's update() function into either a timer interrupt service routine that takes priority above others, and is called as quickly as possible.
If that is not possible, you can place update() in your main loop().
However, if you do this, you MUST avoid the use of delay() and delayMicroseconds() functions in the main loop().
Failure to do this will cause unpredictable behaviour, and it will have a negative impact on the performance of CRSF for Arduino.

CRSF for Arduino is kinder on hardware and memory resources

When you do something like this:

#include "Arduino.h"
#include "CRSFforArduino.hpp"

CRSFforArduino *crsf = nullptr;

void setup()
{
    crsf = new CRSFforArduino();
}

You have just allocated the memory that CRSF for Arduino requires to function.
This will hold until you free that memory up again, by doing something like this:

void loop()
{
    if (crsf != nullptr)
    {
        /* Do something interesting for about ten iterations... */
        for (int executions = 0; executions < 10; executions++)
        {
            delay(100);
        }

        /* It is time to delete CRSF for Arduino, because we are finished with it,
        and its memory MUST be freed. */
        delete crsf;
        crsf = nullptr;
    }
}

Doing this is a more efficient way of managing your hardware's memory footprint. In the context of embedded systems, this memory footprint is often constrained - EG 32 KB of flash memory.

Now, let's put hardware allocation into the mix, by doing something like this:

#include "Arduino.h"
#include "CRSFforArduino.hpp"

CRSFforArduino *crsf = nullptr;

void setup()
{
    /* Allocate memory to CRSF for Arduino, by creating an instance of itself using the default constructor. */
    crsf = new CRSFforArduino();

    /* Allocate the necessary hardware and configuration for CRSF for Arduino. */
    if (!crsf->begin())
    {
        /* CRSF for Arduino failed to initialise.
        Free up all resources that were allocated before the initialisation failed. */
        crsf->end();
        delete crsf;
        crsf = nullptr;
    }
    else
    {
        /* CRSF for Arduino initialised successfully. */
    }
}

You have allocated both the memory and hardware resources that CRSF for Arduino requires in order to function.
Once your firmware has finished with CRSF for Arduino, it MUST be "torn down" - IE The hardware and memory that was allocated beforehand MUST be freed up to prevent hardware and memory leaks.
An example tear-down looks like this:

void loop()
{
    if (crsf != nullptr)
    {
        /* Run CRSF for Arduino for ten iterations... */
        for (int executions = 0; executions < 10; executions++)
        {
            crsf->update();
        }

        /* The hardware resources that were allocated to CRSF for Arduino MUST be freed
        BEFORE the memory itself is freed. */
        crsf->end()

        /* Then, free up the memory that was allocated to CRSF for Arduino. */
        delete crsf;
        crsf = nullptr;
    }
}

If you tried the above examples with other implementations, your compiler may yell at you for doing so.

A huge thank you to you all

As I have said, this has been one hell of a journey. A project that was started up out of pure spite and in response to the lack of implementations that lined up with the full Crossfire Protocol specifications.

When I first started this project, I had zero clue that anyone would actually use it, let alone see CRSF for Arduino meet milestones such as being the top result in Google, and seeing a 2,000 strong daily user-base.
Seeing this has completely blown me away, and I can't thank you all enough. For real, though. From the bottom of my heart, thank you very much for being here, and using CRSF for Arduino in your projects.
Thank you for all of your feedback, comments, questions, Issues, Pull Requests... it's been an amazing journey so far, and I am excited for what the future of CRSF for Arduino brings.

Here's to a solid future of CRSF for Arduino - Bringing The Crossfire Protocol to the Arduino ecosystem!
...and many more releases and updates to come! Because CRSF for Arduino is here to stay. =^/,..,^=