I’m getting some code going and have triple can interface going , but now I also need to send CAN data over serial for debugging.
For single frame transfers I have this working ok where payload_len data bytes appear in
payload_head array when onreception is called. I can simply add the informatin like trasfer id , data_type_ source and dest and send alll this info over serial and then re transmit it on the CAN bus at the other end to make a CAN bridge over serial.
I hacked libcanard slightly to get the extra info and be able to send messages with a faked source ID. This all works , except for messages with multiple frames.
for example a getnodeinfo response message appears with pointer in payload_head and payload_middle, I can’t tell where all the data actually is to be able to forward it.
I found the first 6 bytes in payload_head, but the data in payload_middle seems to start in the 4th byte (as 6th of whole data) and it doesn’t line up after that although all data appears to be there. If I try and send 6 bytes from head an the rest from middle, it does not read properly in gui tool. In the end I got the rxtransfer message and called uavcan_protocol_GetNodeInfoResponse_decode and then uavcan_protocol_GetNodeInfoResponse_encode to get a clean single buffer back.
That did not work either as I started with a 60 byte length and ended with 61 bytes after decoding and encoding. I saw that the name buffer had a 0 at the front so I moved the pointer forward one byte and reduced the name length by one and voila I got the correct display in the gui tool for my node behind the serial bridge.
So I now have a reference buffer to compare to but I can’t see how this is broken up in the two head and middle buffers? I would like to transmit the data across serial without decoding and encoding every message obviously, so can someone tell me how to find the data in the head middle and tail buffers for multi frame messages?
I do need a bridge in serial , and CAN will not do for this.
It appears as though the decode function and encode do not always work when called after each other to produce the same data.