Allows a script to simulate a device attached via any serial protocol.
The script can read and write data and have it handled according to the
protocol as if exchanged over a serial port. The script can then do
protocol translation, data filtering and validation,
hardware-in-the-loop simulation, experimentation, etc., especially in
combination with the scripting protocol which lets the script itself
handle an attached device and so interpose any communication.
Using `luaL_Buffer` avoids the need for any heap allocation in the
common case (count <= 512 bytes) and avoids stressing out the system
heap for large reads, instead using the script heap.
Zero net flash usage change.
Adding another layer instead of just exposing UARTDriver bindings allows
substitution of the different functions for device simulation later.
Also take the opportunity to rework the docs a little.
Passing -1 to the argument count for the `creation` tag (name does not
matter) will stop the generator from giving Lua a function to construct
that userdata. The C `new_<name>` function still works.
Your Copter in stabilize mode can flash rapid-green indicating a good DGPS lock or better, and yet your vehicle still doesn't have a good idea of where it is.
That means that your vehicle may end up RTL'ing onto a point somewhere along your flight path, when you were given an all-green indication by teh vehicle before you armed in stabilize.
Past this PR, we require the same GPS as before, but in addition we must have been happy enough with our location to set the navigation origin, *and* currently be able to get a location.
A user will receive slow-flashing blue lights if they can't currently get a location, or the navigation origin isn't set, even if they've got a "good" fix.
We also require a good location to get a solid green light - you will get a solid blue light if you can't get a location or don't have a navigation origin, even if you have a good GPS lock
setting up a DEFAULTGPIO pulldown in bootloaders is a bad idea as it
overrides any hardware pullups that have been put in place as part of
a "hold in bootloader" mechanism. See discussion in #27360 for ELRS
note that this only impacts one board that I can see, the
BlitzF745AIO, due to the MCU vs DEFAULTGPIO interaction