Add protected ID buffers/zones

[simoneruffini]

Like Germany after the WW1 id's want a protected zone too. This regions will contain a pool of ids that the generator will not use for id-gen.

Why we need that? Because Germany needed it too. Or because some peripherals on the bus have fixed id's that cannot be easily changed. Chose the one that fits you better. Anyway this will standardize the canbus messaging system across all devices.

Example The secondary network is full of sensors with fixed id's that can all be grouped in only one buffer/zone. Those id's can be changed (I think) but it's tedious and if we do that it will be better to keep them in one contiguous zone. With this constraint the other messages that are described in network.json will need to find proper id's that are not the ones in the buffer zone.

Syntax and end result/ What we want The description of the fixed id's can be the same of network.json. Maybe we can have messages[] array and fixed-messages[] array. In the latter one every mesage will have the id specified. The mesage content will have his own encoding so expect a lot fo uint8 single uint32 fields. All this mesages probably will have the same topic. The end result will not be serialized by flatbuffers, so an additional code-generation stage will be needed. Structs for this messages are needed too.

[bonnee]

Is it worth it to have automatic code generation for messages that never change? I thing this feature should be about avoiding the usage of certain IDs to avoid id collisions, but the serialization/deserialization of those messages should be kept separate and hardcoded

[zabealbe]

I and the fenice-can-cicd team will think about the generation of the code for the deserialization. Talking about ids, I can tell you already that the fixed ids is a feature that will be implemented in the near future.

[simoneruffini]

Is it worth it to have automatic code generation for messages that never change? I thing this feature should be about avoiding the usage of certain IDs to avoid id collisions, but the serialization/deserialization of those messages should be kept separate and hardcoded

Yes but all this can be done inside the definition of the network so that there is a central spot where all messages defintions can be read and understood. There will not be any serialization process because messages are already predefined by the peripheral but it's handy to know which id is associated to which message and what it will contain (not with the same detail of normal messages but at least size of the message and where to find stuff in it).

None the less for the near future it's more important to have buffer zones so that at least the canbus can be tested without intrinsic bugs.

[bonnee]

Yes, this should be addressed by the message name and description (if gets implemented) in the JSON schema. Then the include generator spits out the correct #define statement for the particular id like it does for every other message. The content of the message can be defined in the description with a link to the datasheet maybe

What do you mean by buffer zones?

[zabealbe]

feature added in branch feature/fixed_ids, needs testing

[simoneruffini]

Document somewhere the process on how to add this messages with fixed id's

[zabealbe]

Add field fixed_id to the message in network.json, must be an integer. I will document everything when we have the final version