Clean up the box identification code to use a table

[dustin]

I've not tested this on hardware yet, but when I was doing some work in flight modes, it seemed that this structure simplified things a bit.

---

This change is

[ShikOfTheRa]

yep - like structs.

its forced to enable though? Assume from testing and can be removed?
I think its only used by very old multiwii and Hariki now?

[dustin]

Yes, it's for testing. I didn't get a good test last night due to hardware
problems.

It seemed like a good idea for reporting modes. I did notice the limited
use. How are modes such as acro plus discovered in general?

On Thu, Apr 28, 2016, 04:40 ShikOfTheRa notifications@github.com wrote:

yep - like structs.

its forced to enable though? Assume from testing and can be removed?
I think its only used by very old multiwii and Hariki now?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#223 (comment)

[ShikOfTheRa]

BOXNAMES is still valid approach, but is the older way. CF,BF and multiwii now all use BOXID

MSP_BOXID
Basically the FC send a series of 8 bit values which represents the various modes in use. It varies between FC depending upon version and what is in use.
The order defines the bit used to flag when a sensor is enabled.
It was done this way to enable future expansion of modes without impacting MSP compatibility.

MSP status
Within this is a 32 bit value (MwSensorActive) that specifies which sensors/modes are enabled or not
This is the one used to determine if a mode is enabled or not by a bitwise OR with the different modes to see if they are enabled.

The trick is to understand how boxid works then it all becomes straightforward!