generator: mavlink_channel_t with correct length

[julianoes]

For cases where more than 4 mavlink channels are required, the mavlink_channel_t does not match. Therefore, I suggest that the enum needs to be provided separately if the default channel number is not used.

[len0rd]

Hey, nice work! This is similar to a PR I opened up a few months ago in response to an issue I made about this ( #404 ). Your change is more along the lines of the fix I was thinking when I made my PR originally.

Unfortunately, to preserve backwards compatibility, it may be necessary to maintain the default definition of mavlink_channel_t somehow. (Perhaps some type of ifndef wrapper similar to my PR)?

[julianoes]

Thanks for the comment @len0rd. I would be happy with either PR.

[hamishwillee]

@peterbarker Could you please review this?

[hamishwillee]

@peterbarker ?

[tridge]

I don't really understand what issue this is solving. Are you really trying to use MAVLINK_COMM_7?
Maybe we should add
#define MAVLINK_COMM_N(n) mavlink_channel_t(MAVLINK_COMM_0+(n))
or we could add:
#ifndef HAVE_MAVLINK_CHANNEL_T
around the enum define, to allow it to be overridden

[julianoes]

@tridge thanks for your answer. You're right that it would break existing users that define MAVLINK_COMM_NUM_BUFFERS.

Maybe we should add
#define MAVLINK_COMM_N(n) mavlink_channel_t(MAVLINK_COMM_0+(n))
or we could add:
#ifndef HAVE_MAVLINK_CHANNEL_T

What about doing both?

[julianoes]

@tridge ok, I've added ifndef HAVE_MAVLINK_CHANNEL_T as you suggested. That should work, and is basically what @len0rd suggested in #426.

[julianoes]

@tridge could you check this again please? Thanks!

[hamishwillee]

Hi @tridge
Can you please re-review?

[julianoes]

Thanks!