Reorder the bits in can_fd_frame_id

[bondus]

By ordering (and possibly) inverting the bitfields it may be possible to utilize the CAN bus priority system to make sure more important messages gets delivered first. Such as making non-first message fragments higher prio than first fragment.

At least we could organize the bits in a way that the lowest CAN IDs are reserved for future low latency messages.

It probably makes a very small difference and will only have any effect if the bus is near full.

[arsi-apli]

I think it will be better this way:

struct can_fd_frame_id { //message ID = 29-bits
                //CAN FD only supports specified message lengths, so we need to know the real length.
                uint32_t msglen : 8; //[8] - current message size,
                //Ready for the future, not currently implemented
                uint32_t msg_part_counter : 2; //[10] - Multipart MCU protocol data, countdown counter up to 4 pars (256 bytes)
                uint32_t mcu_address : 7; // [17] 0-127
                uint32_t msg_type : 3; //[20] - can_fd_msg_type
                uint32_t sequence : 8; //[28] - Klipper message sequence
                uint32_t response : 1; // [29] - if response from MCU
                //***********************************************************************************************************************
                uint32_t can_flag1 : 1; //[30] CAN stack flags
                uint32_t can_flag2 : 1; //[31] CAN stack flags
                uint32_t can_flag3 : 1; //[32] 4byte - CAN stack flags
                //The CAN protocol has an integrated CRC, so it is not necessary to transmit it. 
                //It will be added to the serial stream by the CANtoSerial application on the RPI side
            } id;

Currently the most important is the sequence and I reworked the addressing, it will be just the MCU address and whether it is a request or a response.

You wrote about sending the limit switch trigger between the boards via CAN, but I'm afraid it won't be accurate. I would have to evaluate the received messages directly in the ISR and this would not have a good effect on timing. Otherwise, if it is evaluated in that task, the tasks are called sequentially and may take different lengths of time.