When adding a new gadget you want to be able to trigger using your TX, you have to add the necessary code to both the copter firmware as well as the GUI - as well as any other GUI in existence (Android, WinGUI etc.).
The other alternative encountered here is hardcoding the function in the code, which is awkward in its own way.
In my opinion, the fixed number of aux switches and subsystem ("boxitems") should be replaced:
The GUI should have no knowledge whether there the copters do have systems called "LEVEL", "ARM", "CAMTRIG" etc., or how many AUX channels are present. Instead, the GUI should request this information from the copter itself.
Code: Select all
(this is a pseudo protocol)
# Request number of AUX/switch channels
GUI: AUX?
MWC: AUX! 4
# Request available subsystems
GUI: SUBSYSTEMS?
MWC: SUBSYSTEMS! (LEVEL, BARO, MAG, CAMSTAB, CAMTRIG, HELLFIRE, AUTODESTRUCT)
# Get switch configuration with bitmask for each AUX switch
GUI: SUBSYSTEM LEVEL?
MWC: SUBSYSTEM LEVEL! (3,0,0,0)
GUI: SUBSYSTEM BARO?
MWC: SUBSYSTEM BARO! (0,4,0,0)
The GUI can then be built from the copter responses as needed by the vehicle. For adding a new gadget, it would be sufficient to add the necessary firmware code without touching any GUI sources.
Configuration data can be exchanged using either the literal name of the subsystem or by using its index. Since the above dialoug will only occur when connecting the the copter, the overhead should be minimal.
Any ideas about that?