mavgen_lua.py: copy with MAV_BOOL / int8 type bitmask

[peterbarker]

This looks like it would die any time you have an enumeration which isn't of type float, double or int32.... no idea why you would have enumerations in those first two types...

Closes #1133

@shancock884 does this look like it might work to you?

[yonatan8070]

Tested with my dialect, looks like it works perfectly.
Thank you!

[shancock884]

@shancock884 does this look like it might work to you?

I'll make a quick test for this later today to cover the range of data types - for example, I wonder whether INT16/64 should be included too, given that INT32 and INT8 both are.

Having FLOAT can make sense because some MAV_CMD params are float enums, but not sure I've seen any double enums - although if its not explicitly disallowed by Mavlink rules, parser should be able to cope with it.

[shancock884]

I added a suggestion so that it should be able to handle any cases of bitmasks being attached to any sort of signed integer types in the future.

It seems very odd to me that MAV_BOOL is a bitmask rather than a straight-up enum... but given that there seems to be lots of discussion about this on the original PR (mavlink/mavlink#2242), I will leave that can of worms alone!

The net result of that decision is that it looks kind-of silly in Wireshark, as it is extracted like this:

param1: Arm (MAV_BOOL): 0x00000000 (0)
    ...0 = MAV_BOOL_TRUE: False

Instead of a normal enum, which would look like this:

param1: Arm (MAV_BOOL): MAV_BOOL_FALSE (0)

[peterbarker]

@yonatan8070 @shancock884 I've applied Simon's suggestions here. What sort of testing needs to be done here, @shancock884 ?

@yonatan8070 could you at least test this patch still solves your problem, please?

[shancock884]

I've applied Simon's suggestions here. What sort of testing needs to be done here, @shancock884 ?

I have checked this out, and tested locally with a selection of recorded files and it looks good from what I have tested.

As a aside, I was thinking it would be good to update the WLua test cases to be using the latest Mavlink XML - which I think would have caught the error in CI. I've starting this in a new branch, which I could PR after this one is in.

[peterbarker]

Thanks @shancock884 , merging!