Scalability of: Too many message ids

Developers
1

We are facing this situation where we have too many message ids after adding new features to klipper. Is there currently a way to extend the number of message ids? If not, what would be the best approach to scale that functionality?

I was thinking about making a second message/command generator and use a reserved command to access the new command set or messages. ie.: command 127 route messages to the new set of commands. The new commands would use a different macro to expose them in C. But if we could just extend the field to accept more message ids, that would be preferable of course.

2

Is there a limitation why the command id could not be encoded using variable integer? Performance reasons?

3

So I ended up supporting msgid VLQ, it was easier than I thought to implement!

4

Using a VLQ for the command id was just never implemented in the mcu. Implementing it is likely the best long-term scalable solution.

-Kevin

5

can you share your implementation?

6

Yep, here are patches to apply. We have a very customized klipper repo here, so hopefully that integrates well. Might be a good idea to upstream this is you want/can.
klipper_vlq.zip (5.1 KB)

2 Likes