hwdef: add CubeOrangePlus-ODID hwdef

[BryonOI]

Bootloaders:
Add CubeOrangePlus-ODID hardware def bootloader files for remote ID support.

• Follow ./waf board configure instructions to set hardware def for CubeOrangePlus.
• Tested using CubeOrangePlus arduplane firmware

[peterbarker]

Why is this not including CubeOrangePlus/hwdef.dat?

[BryonOI]

I did not change this as this is how the original CubeOrangePlus hwdef file was formatted. This section is identical to the CubeOrangePlus hwdef aside from the updated board id. Does this need to be changed?

[BryonOI]

I have tested this to include CubeOrangePlus/hwdef.dat. These changes cause an error when configuring the board due to PF14 redefinition. I have not changed this file in the PR as it does not seem to reflect the original CubeOrangePlus build configurations. Please let me know if you have further questions or requests for this PR.

[peterbarker]

So the concept is that you include CubeOrangePlus/hwdef.dat and put in just what you need to to do ODID.

Check out how CubeOrange-ODID does it.

[peterbarker]

@BryonOI you still haven't addressed this comment.

The entirety of this file can simply be:

# hw definition file for processing by chibios_hwdef.py

include ../CubeOrangePlus/hwdef.dat

undef APJ_BOARD_ID
APJ_BOARD_ID 11063

define AP_OPENDRONEID_ENABLED 1

Similarly for the -bl file.

[peterbarker]

Please note our requirements on commit history - this should be a single commit titled hwdef: add CubeOrangePlus-ODID hwdef. Currently there are 9 commits in here.

[peterbarker]

Could you outline how this fulfills your needs, please? My concern is that we have dozens of boards that could have ODID variants made for them, but often vendors believe they need to do more to satisfy ODID requirements.

The costs are (a) complication for maintenance of the project and (b) build time on our build server, which generates binaries for commits to our master branch (and for releases).

It's OK to merge this, but we do need to know it's doing someone some actual good.

[BryonOI]

Could you outline how this fulfills your needs, please? My concern is that we have dozens of boards that could have ODID variants made for them, but often vendors believe they need to do more to satisfy ODID requirements.

The costs are (a) complication for maintenance of the project and (b) build time on our build server, which generates binaries for commits to our master branch (and for releases).

It's OK to merge this, but we do need to know it's doing someone some actual good.

Thank you for your reply!

Overhead Intelligence utilizes both the CubeOrange and CubeOrangePlus on our fleet of drones. Including the CubeOrangePlus-ODID firmware to the hwdef boardlist will allow us to quickly access the new firmware from the remote master branch of ArduPilot, which we are already working with. I have implemented the CubeOrangePlus-ODID firmware into many functioning ArduPilot platforms with no errors. Including the CubeOrangePlus-ODID firmware would allow Overhead Intelligence and many others using the CubeOrangePlus to easily upload the new ODID firmware to future drones using ArduPilot software.

[peterbarker]

@Hwurzburg do we need all of the documentation copied over into this new board or not?

@BryonOI you're still interested in chasing this?

[peterbarker]

@BryonOI you still haven't addressed this comment.

The entirety of this file can simply be:

# hw definition file for processing by chibios_hwdef.py

include ../CubeOrangePlus/hwdef.dat

undef APJ_BOARD_ID
APJ_BOARD_ID 11063

define AP_OPENDRONEID_ENABLED 1

Similarly for the -bl file.

[Hwurzburg]

@peterbarker if this is simply an ODID version I don't think we need dup docs from the Plus

[BryonOI]

@Hwurzburg do we need all of the documentation copied over into this new board or not?

@BryonOI you're still interested in chasing this?

Yes it would be very beneficial to our team. I have modified the hwdef.dat and hwdef-bl.dat files accordingly. Please let me know if there is anything else needed for this merge request to be approved.