To use, include `cli/cli_debug_print.h` in your code and be sure `USE_CLI_DEBUG_PRINT` is defined. Then you'll have access to the following functions to print debugging messages in the CLI:
```
cliDebugPrintLineFeed
cliDebugPrint
cliDebugPrintLine
cliDebugPrintf
cliDebugPrintLinef
```
Output is suppressed when the CLI is not open.
May interfere with the autocomplete initialization when first entering the CLI if your code is outputting data when the CLI first opens. But as this is only meant for debugging it shouldn't be much of a concern.
You may also need to rate limit your messages if printing data in a loop.
All of the debugging code must be removed from any completed code before submission.
NUCLEOF103RG is a target for Nucleo-F103RG (Nucleo-F103RB transplanted
with STM32F103RG which has 1MB of FLASH).
Such hardware with this target comes in handy when a firmware that
doesn't fit in smaller FLASH variant when compiled with DEBUG option.
The target definition files are straight copy of NAZE, except LED0_PIN
has been redefined to use Nucleo's LD2 (User LED).
It is also easy to convert exisiting F1 targets to be built to run on
the Nucleo-F103RG board:
- Add
#define FLASH_PAGE_SIZE 0x800
to target.h
- Also add
#undef USE_DSHOT
#undef USE_LED_STRIP
#undef USE_TRANSPONDER
#undef USE_CAMERA_CONTROL
to target.h to avoid non-F1 compatible code from getting in.
- Add
FLASH_SIZE = 1024
to target.mk
Affected all unified targets as USE_VTX_RTC6705 must be defined to allow supporting that VTX option. Would cause the low power index settings for RTC6705 to override the settings for other VTX type and set the vtxtable power level index to 2 instead of 1.
Adds a fixed delay after the motors are enabled before DSHOT commands can be sent. Fixes a problem caused by sending DSHOT commands too soon and prevent the ESC from properly detecting the protocol.
SPI5 and SPI6 are only available in packages >= 144,
and these are not defined in bus_spi_pinconfig.c either.
Accessing spiInitDevice() with SPIDEV_5 or SPIDEV_6 would cause hard fault.
The maximum power capability supplied from different VTX models is inconsistent. Sometimes correctly representing the VTX's capabilities, while for others not accurate or misrepresentative. So the previously added check is preventing accessing power levels in cases where the VTX doesn't properly report its max limit.
Some VTX don't respond to every request so it's necessary to retransmit. A previous PR fixed a bug that caused more retries than expected and made the actual retries only be 2 as configured. Unfortunately this exposed the problem with the non-responding VTX with cases of it not responding to both retries. The problem was accidentally masked by a previous bug with the retry counter causing many retries to actually occur.
This then exposed a secondary problem in `vtx_common` that lead to a "lockup" condition if the actual VTX channel didn't match our expectation of what the channel should be based on the settings. We were getting into this state because of the (now working) retry limit and cases where the VTX didn't respond and change channels as expected.
Increased the retry count to 20.
Fixed the logic that would prevent subsequent channel changes if the actual VTX channel didn't match the expected value based on the settings. Also fixed a problem where the channel change would not work if the VTX was on a frequency that was not defined in `vtxtable`.
Timeout logic was ignored if the user had the accelerometer enabled and the quad wasn't within the angle limit. This was made doubly troublesome as the angle limit could be set to zero preventing crash recovery from ever deactivating.
Also adjusted the ranges of the parameters to be more rational to avoid invalid configurations.
