hexfet
commented
5 years ago Thanks. I enabled the feature for all non-modular builds. Had to increase the memory allocation to support the diversity receiver.
Closed hexfet closed 4 years ago
hexfet
commented
5 years ago Thanks. I enabled the feature for all non-modular builds. Had to increase the memory allocation to support the diversity receiver.
The CRSF configuration system works by message exchange between the transmitter (deviation) and the TBS devices. This implementation has been tested with both full-size and micro Crossfire transmitters and Nano RX receiver. Each TBS component supplies parameters defining its configuration options and menu structure.
The CRSF configuration page is started by clicking on the protocol name. One step of the page init function is to send a TBS message to discover available devices. The device names are then shown in a scrollable (currently limited to four entries maximum). The device info response includes the number of parameters associated with the device. Clicking on a device name starts the crsfdevice page, which starts a sequence of messages to retrieve all the device parameters. These are displayed according to the menu structure defined in the parameter information by TBS. When a setting is changed a "set parameter" message is sent to the TBS device, which responds with a parameter info message that includes any changes made. Parameters of type COMMAND open a dialog to show the command status. Some commands require an Ok/Cancel response from the user before proceeding (but whether a command needs this check isn't known until the command is started...).
The TBS menu information takes considerable RAM space (e.g. 2401 bytes for Nano Diversity RX). This implementation does not attempt any compression of the menu info as that will add considerable messiness. A new target definition SUPPORT_CRSF_CONFIG controls whether the code is included in a build. This PR has CRSF configuration enabled for all non-modular builds.