src: decoder: Fix: Discard higher invalid msg_id

[RaulTrombin]

Actuall Ping protocol messages max possible value is 2903, for ping360 motor_off.

[patrickelectric]

It's not the job of the parser to identify the message id as invalid.
We should be free to specify any message_id, if the message_id does not match any valid message currently in the protocol, this should be done in the deserialization step and not in the decoder.
As I believe the current way.

The reason behind it is that the job of the parser is just to follow the protocol structure specification for a valid message.

Message Format

Each message consists of a header, optional payload, and checksum. The binary format is specified as follows:

Byte	Type	Name	Description
0	u8	start1	Start frame identifier, ASCII 'B'
1	u8	start2	Start frame identifier, ASCII 'R'
2-3	u16	payload_length	Number of bytes in payload.
4-5	u16	message_id	The message id.
6	u8	src_device_id	The device ID of the device sending the message.
7	u8	dst_device_id	The device ID of the intended recipient of the message.
8-n	u8[]	payload	The message payload.
(n+1)-(n+2)	u16	checksum	The message checksum. The checksum is calculated as the sum of all the non-checksum bytes in the message.

If it follow such rules, the parser should return the message as valid. And it's the device that should handle if the message is invalid or not.
We could change the generated code to return a generic message if it does not match any valid message inside the deserialization as well.
It should be around the deserialize_tokens_vec part.

[RaulTrombin]

It's not the job of the parser to identify the message id as invalid. We should be free to specify any message_id, if the message_id does not match any valid message currently in the protocol, this should be done in the deserialization step and not in the decoder. As I believe the current way.

The reason behind it is that the job of the parser is just to follow the protocol structure specification for a valid message.

Message Format

Each message consists of a header, optional payload, and checksum. The binary format is specified as follows:

Byte Type Name Description
0 u8 start1 Start frame identifier, ASCII 'B'
1 u8 start2 Start frame identifier, ASCII 'R'
2-3 u16 payload_length Number of bytes in payload.
4-5 u16 message_id The message id.
6 u8 src_device_id The device ID of the device sending the message.
7 u8 dst_device_id The device ID of the intended recipient of the message.
8-n u8[] payload The message payload.
(n+1)-(n+2) u16 checksum The message checksum. The checksum is calculated as the sum of all the non-checksum bytes in the message.
If it follow such rules, the parser should return the message as valid. And it's the device that should handle if the message is invalid or not. We could change the generated code to return a generic message if it does not match any valid message inside the deserialization as well. It should be around the deserialize_tokens_vec part.

I agree that receive a glitched msg_id isn't a problem, but a unspected higher payload_lenght could keep the decoder adding bytes till receive ~u16_max bytes.