rm5248 / trainutils Goto Github PK

CAN frame transfer: section 6.2

Currently, LibLCC fails the test of an AMR frame when running with the OlcbChecker.

Since an LCC checker already exists, we should integrate that into the build process to make sure that LibLCC behaves appropriately.

Source: https://github.com/bobjacobsen/OlcbChecker

If we are already in the middle of a datagram transaction, send back an error to a node that requests us to do a new transaction. This helps to ensure that the response to the previous transaction has been sent before we try to process a new one.

if datagram too big (more than 8 events), datagram is cut in parts, but each part starts from 0
in LCC_memory.c, at line 240:

memcpy(response + start, data, data_len);
====>
memcpy(response + start, data + starting_address, data_len);

thank you for the wonderfull job.

The alias generation for nodes should be randomly generated over the 12-bit alias space. It probably isn't at the moment.

The API of the write callback on LCC is defined as "fire and forget":
https://github.com/rm5248/TrainUtils/blob/master/LCC/examples/simple-node/simple-node.ino#L28C1-L28C1

This API assumes that any time that the stack decides to call this function, the bus is free. This is not a valid assumption. The LCC stack must be prepared for the bus being busy and stop generating frames until the previously generated frames were transmitted to the bus.

It is important that when the writes to the bus are throttled, the stack must still read and process the incoming traffic. Therefore it is not an OK solution to pause the stack until the output frame was transmitted. It is also true that the new incoming traffic might generate output data, which might seem like a contradiction.
There are four priority bands in OpenLCB, and it is designed such that a request of priority X will generate a response of priority X-1, therefore even in the presence of a fully loaded bus, the responses that are generated will go out.

The way LibLCC is written today, it will lose messages when the output buffer in the CAN controller is occupied. This will cause problems that are hard to recognize and reproduce. The assumption of LCC is that all messages are delivered.

Need to add a function that lets the LCC code know how much space there is in the send queue. For example, if there is not enough space in the send queue for us to do a full datagram transfer(8 packets), then we should send back an error.