Bug

The fmap implementation in crsf_protocol.h is at risk of underflow errors when the x is fed less than in_min.

static uint16_t ICACHE_RAM_ATTR fmap(uint16_t x, uint16_t in_min, uint16_t in_max, uint16_t out_min, uint16_t out_max)
{
    return ((x - in_min) * (out_max - out_min) * 2 / (in_max - in_min) + out_min * 2 + 1) / 2;
}

For example, calling fmap(5, 10, 20, 100, 200) will be result in:
(5-10)*(200-100)*2 ...

However, as the variables are defined as unsigned types, 5-10 = -5 will be wrapped into 65535-5 = 65530, which gives an erroneously large value.

With some old PPM handset, the values could be go outside the defined range.

Fix

Straightforward, constrain the x within in_min -- in_max range.

Story

The bug was discovered when testing an old PPM radio with an ELRS TX; the control surfaces are flipped all the way to the other side when the stick was deflected to its minimum position.

Close investigation revealed that the PPM signal from the radio was outside the hard-coded range of (988, 2012) in PPMHandset.cpp, causing the underflow.

PS. ELRS module installation on an old Futaba radio which discovered this defect: