Bosch BMI160 gyro support + BrainFPV Radix

[digitalentity]

• Add a new F446 CPU family
• Clean up F4 clock PLL_M divisor calculation
• Moved decision about gyro update rate to gyro driver
• Add support for Bosch BMI160 gyro/acc sensor
• Add initial support for Radix FC (incomplete)

[mluessi]

Hi, this is Martin from BrainFPV. I actually also just started working on this a few days ago :)

To make the OSD work, it will need quite a few changes to the existing code, e.g., the RT OSD needs to be added to support preempting the OSD when the gyro loop runs, etc.

From our side (BrainFPV), we would prefer to maintain the RADIX target and associated code in it's own iNav fork, like we currently do with betaflight. Naturally, I can't prevent you from adding support to iNav proper, but just wanted to give you a heads up.

[digitalentity]

@mluessi thanks for chiming in!

You are welcome to maintain your own version of INAV, but in such case I can't list RADIX as supported by INAV.

Regarding OSD. I'm not sure that RTOS is a requirement for RADIX OSD, but I might be wrong since I didn't start looking into it yet. If you can send me schematics for RADIX board to konstantin (dot) sharlaimov (at) gmail (dot) com it will certainly make things easier.

[digitalentity]

There's also an issue with I2C. As far as I can tell there is no I2C breakout on RADIX which is a pity since it considerably limits use cases for this board.

[mluessi]

@digitalentity it would be OK for us if RADIX isn't listed from your side.

Some graphical OSD items can take a few ms to draw. It could be done without using the RTOS, but one would need to break the drawing operations into smaller parts, etc, which IMO would be harder than using an RTOS.

You are correct, RADIX doesn't have I2C. The UART1 pins could be used, but they don't have pullup-resistors, so it may not work reliably. We are primarily targeting RADIX to be used for fixed wings with iNav, which don't really need a mag.

Unfortunately at this time we can't share the schematics, as they contain information that we consider proprietary.

[digitalentity]

Some graphical OSD items can take a few ms to draw. It could be done without using the RTOS, but one would need to break the drawing operations into smaller parts, etc, which IMO would be harder than using an RTOS.

Ok, I get it now. I'll see what could be done without going into all this RTOS stuff.

The UART1 pins could be used, but they don't have pullup-resistors, so it may not work reliably

So, the UART1 is not routed through the FPGA. This is something we can work with. Lack of pull-ups is an issue, but not a major one. Some GPS modules have them and this is usually good enough.

Unfortunately at this time we can't share the schematics, as they contain information that we consider proprietary.

Pity. I'm looking for some basic details - how CPU pins are mapped, what functions are delegated to FPGA etc. Not that it couldn't be figured out by reverse engineering the board or reading through your code, but I would prefer to have this info right from the board manufacturer.

[digitalentity]

Will have to be rebased on top of #2958