Open bondus opened 4 years ago
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.
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.