buscan
I have to send periodic frames with high frequency on a CAN bus. When I do that, the bus load becomes more than 60%, which causes delay with the received frames.
Per Olin Lathrop's suggestion, I'll expand on bit-stuffing.
CAN uses NRZ coding, and is therefor not happy with long runs of ones or zeroes (It loses track of where the clock edges ought to be). It solves this potential problem by bit-stuffing. When transmitting, if it encounters a run of 5 successive ones or zeros it inserts a bit of the other polarity, and when receiving, if it encounters 5 successive ones or zeroes it ignores the subsequent bit (unless the bit is the same as the previous bits, in which case it issues an error flag).
If you are sending all zeroes or all ones for your test data, a string of 64 identical bits will result in the insertion of 12 stuffed bits. This will increase total frame length to 140 bits, with a best-case frame rate of 874 frames / sec. If the data bits are the same as the MSB of the CRC, you'll get another stuffed bit there, and the frame rate drops to 868 frames/ sec. If the CRC has long runs of ones or zeroes, that will reduce the frame rate even further. The same consideration applies to your identifiers.
A total of 16 stuffed bits will produce an ideal frame rate of 850.3 frames/sec, so you ought to consider it. A quick test would be to use test data with alternating bits, and see what happens to your frame rate.
You already wrote that the maximum data rate is 1Mbit/s, but this is the raw rate.
A CAN message (data frame) looks like this on the scope:
(Source)
and consists of this sections with their length in bits:
Start-of-frame 1
Identifier (green) 11
Remote transmission request (RTR) (blue) 1
Identifier extension bit (IDE) 1
Reserved bit (r0) 1
Data length code (DLC) (yellow) 4
Data field (red) 0–64
CRC 15
CRC delimiter 1
ACK slot 1
ACK delimiter 1
End-of-frame (EOF) 7
Inter-frame bits 3
(Source)
i.e. there are 46 "management" bits for up to 64 data bits. This reduces your net data rate to about 580kBit/s.
The sender sends a recessive 0 in the ACK slot, and the receiver will pull it to a dominant 1 when the message was received correctly. This means the acknowledge mechanism already is part of this data frame, and doesn't cost additional bandwidth.
The Inter-frame bits are the minimum distance between two frames, so the next frame can follow directly. However, if there is more traffic on the bus, the data rate can be drastically reduced. Keep in mind: Whoever has to send a message checks if someone else is talking and if not, starts to talk. If two devices start to talk at the same time, they will notice this, abort, wait a little and try again. (It's really like several people talking to each other. Some tend to say just a few words, pause for a second, and speak again. You sometimes can't jump in to say what you want...)
Finally, all devices must be set to 1MBit/s, and the maximum length of the cable is limited to 40m.
Apart from this, you need to find out what data rate your MCU can handle. It's possible that the CAN module of the MCU can handle a bus speed of 1MBit/s, but that the MCU can not copy the data from the module before the next module arrives. In this cases, you need to implement pauses between the frames.
Best Answer
CAN bus can only carry one message at a time.
Even when a collision occurs, the arbitration protocol guarantees that the higher-priority message succeeds.
Therefore, as long as the bus bandwidth is not over-subscribed, there will be a fixed upper bound on the delivery delay of any message.
If that bound is higher than what your system can tolerate, then you need to redesign your system.
If you want a more specific answer, then you'll have to provide more details about your system.