Since we currently don't have per gyro configuration, trying to use two different gyro types simultaneously may not provide good results or lead to other unforeseen situations like attempting to initialize with settings not applicable to both hardware types.
This logic looks at the detected gyro types and resets to use only the first one if the user selected "BOTH" and they're different hardware types.
With the changes to add dual gyro support and the SPRACINGF7DUAL target, the defaulting logic of which gyro(s) to use was changed. The logic defaulted to using "BOTH" unless the target specifically selected a gyro.
I think this logic is backwards in that the first gyro should be selected by default unless the target specifies something different. The previous logic would cause all of the previous dual-gyro targets to default to "BOTH" even though they have different gyro types. This is probably not a good idea and definitely would cause an unexpected change for the users.
The SPRACINGF7DUAL target has two of the same gyro so defaulting to "BOTH" is appropriate. So now the target specifies that both gyros should be used in this case as the default.
The osd_esc_current_alarm was added but never assigned a default value. Therefore it defaulted to 0 instead of off (-1). This resulted in OSD warnings if the ESCs weren't providing current data as the test looked for values >= the warning setting.
The for loop variable was being erroneously double incremented when a character was updated. This would cause fewer characters to be checked/updated during each cycle based on how many were found to be updated.
The 0xFF character is used as an "escape" character by the MAX7456 when using auto-increment mode. The last byte of the characters used for the logo is the 0xFF character and this was causing the version and CMS instructions to not display.
Changed the logic to avoid the 0xFF character during the auto-increment phase and added a second pass if needed to update those characters in direct addressing mode.