v0.21.0

ATTENTION: Setting up min/max startup power is crucial to protect hardware as best as possible, please refer to our startup power setup guide.

Quality of life improvements

Massive code refactoring, everything has been refactored into smaller, more readable modules. (#99, #103, #104, #107, #116, #117, #119, #128)
Auto formatting has been applied and preparations have been made to check for proper formatting in PRs. (#93)

EDT safety arm ensures that the ESC will only arm after a valid EDT handshake. This will only work with flight controller firmware that support EDT functionality.
Temp protection is disabled by default: Since temp protection has effectively not been working for a long time (probably ever), the default is no to be disabled to prevent users from running into issues where they are "losing power". If temp protection is enabled, make sure that the "power rating" setting is set correctly and best verify via EDT and temperature readout on Betaflight, that the Temperature values are in a sane range (around 50). (#95)
Improved defaults for min/max startup power

Since the current dithering implementation does not do what it is promising to do, we opted to remove it
New layouts have been added. We were running out of letters for new ESC layouts and thought we might just make it if no new layouts pop up, but this of course is not the case - so we future proofed this and added functionality for ESC layouts to have 2 characters instead of one. (#113)
Add supporter section. (#85, #89, #139)

Bootloader was using wrong keys leading to at state where it would not be possible to save settings or flash firmware. This was only an issue after flashing v0.20.0 via C2 interface. During regular updates via esc-configurator.com the bootloader is not written and people will not be affected.
When fixing 3D mode, startup motor protection was inadvertently disabled which unfortunately lead to a couple fried ESCs and AIOs.
There was a bug where max startup power has been ignored. This is now fixed and will help prevent damage to motors/ESCs in cases where the motors are stuck. This bug is present in BlheliS and Bluejay up to 0.20.0. It has special relevance in crashes, where the motors can get stuck and power is high. This is especially true for various FC related crash Recovery features after for example clipping a gate.

A lot of the planned features for 0.20/0.21 needed to be postponed to a later release since they are not working in a satisfactory way:

Dynamic and variable PWM has been somewhat successful but not fully satisfactory to us. It is wasting a lot of CPU cycles, CPU cycles we do not have
The current dithering implementation is eating up a lot of CPU cycles and is a bit flawed since it is only applied to every DSHOT package instead of every PWM cycle. Testing has shown that there is little to no difference in having vs. not having dithering in the current implementation. We might in the future ditch dithering in favor of gaining some CPU cycles to get some other - for us - more important features implemented
In process of experimenting with dynamic PWM we came to the conclusion that 96kHz mode is pretty much useless and we might get rid of it in the future. The resolution on 96kHz is 256 steps in the best case. Considering deadtime, (which needs to be subtracted) - having high dead times reduces this even further.