Buffer size in relation to the cycle time

You will have to estimate how big the buffer has to be or how fast the task time must be. The following table will help you to define this in advance.

The CCAT CAN master has a memory for 512 messages, the EL6751 for 150 messages (RxMessages). The data will be lost if they are not fetched quickly enough from the memory. No indication is given, therefore the worst case should or must be estimated, or the variable NoOfRxMessages should as far as possible be smaller than the maximum buffer value. If this is always or in almost every cycle at the maximum value, then this indicates that more data are being received than can be recorded per cycle. Remedy: Shorten the task cycle time or enlarge the buffer of the CAN queue.

Example

A CAN telegram with 11-bit identifier and 8 bytes of user data needs about 260 µs at 500 Kbit/s. If one assumes a 100% bus load in the worst case, it would be maximally 3 telegrams with 1 ms. This means that a buffer of maximally 4 would be adequate in this case. If a task time of 5 ms is used instead of 1 ms, the buffer should be at least 20 (5000 µs / 260 µs). It must be remembered here that in this study only the data in one direction are considered and that the CAN data always have 8 bytes. Since a 100% bus load is not usually assumed, one can also evaluate the variable NoOfRxMessages and see whether it lies in most cases below the maximum number of buffers created. If NoOfRxMessages is often at the maximum value, the task time should be shortened or the buffer enlarged.

Worst case

However, the CAN interface is designed such that, as a rule, the data can always be fetched faster than they run into the buffer.

Example

1 MBaud data length 0 means 50 µs per CAN message. With a 1 ms task time this would be
1000 µ / 50 µs = 20
This means that even in this extreme worst case a buffer of 20 would be adequate to receive all CAN telegrams.