CAN - Burst of CAN messages

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CAN - Burst of CAN messages

Jump to solution
8,133 Views
freescale_satya
Contributor III
Hi, I have the following requirement where I have to transmit around 14 messages for every 10ms. Is it possible to achieve the strict timing requirements without time delays, I mean to say all the 14 messages being transmitted at a periodicity of 10ms? I am not successful in achieving this. What is the strategy I need to follow to achieve a very low error in transmission periodicity? Can somebody guide me on this? i have receiving messages as well which needs to be processed. thanks and regards, Satya
Labels (1)
0 Kudos
Reply
1 Solution
5,697 Views
Lundin
Senior Contributor IV

You will first of all need a reliable clock source, ie an external crystal or external oscillator. Then setup either the RTC or one of the other hardware timers ("ECT" on S12). You may have to pick an oscillator frequency that is both suitable for the timer prescalers and the CAN baudrate prescaler. Any multiple of 10MHz should do the trick (personally Im using a 20MHz pierce oscillator for very similar applications).

 

Once you are sure of the clock, you will need to setup the timer to a given interval (either interrupts or polling should work). You may or may not be able to have the timer flag after 10ms. If you can't pick that long a time, the software will need to count the number of timer completions until you've had the correct amount equal to 10ms.

 

When you have reached the 10ms, execute the transmission code. For the simplest way of doing this, have your main() loop wait & poll until it receives the timer flag.

 

Naturally you can't send all 14 messages at once, as the CAN bus is serial. You will need to calculate how long it takes to send them. For example: With minimum overhead (11-bit identifier) and 8 bytes of data in each CAN frame, you'll get 47+8*8=111 bits of data per package, counting intermissions between messages. Ie 14*111 = 1554 bits. With baudrate 125kbps, it would take 12.43ms to send them all, assuming you have free reign over the bus. In other words, in this case you wouldn't be able to send them all before 10ms have ellapsed.

View solution in original post

8 Replies
5,698 Views
Lundin
Senior Contributor IV

You will first of all need a reliable clock source, ie an external crystal or external oscillator. Then setup either the RTC or one of the other hardware timers ("ECT" on S12). You may have to pick an oscillator frequency that is both suitable for the timer prescalers and the CAN baudrate prescaler. Any multiple of 10MHz should do the trick (personally Im using a 20MHz pierce oscillator for very similar applications).

 

Once you are sure of the clock, you will need to setup the timer to a given interval (either interrupts or polling should work). You may or may not be able to have the timer flag after 10ms. If you can't pick that long a time, the software will need to count the number of timer completions until you've had the correct amount equal to 10ms.

 

When you have reached the 10ms, execute the transmission code. For the simplest way of doing this, have your main() loop wait & poll until it receives the timer flag.

 

Naturally you can't send all 14 messages at once, as the CAN bus is serial. You will need to calculate how long it takes to send them. For example: With minimum overhead (11-bit identifier) and 8 bytes of data in each CAN frame, you'll get 47+8*8=111 bits of data per package, counting intermissions between messages. Ie 14*111 = 1554 bits. With baudrate 125kbps, it would take 12.43ms to send them all, assuming you have free reign over the bus. In other words, in this case you wouldn't be able to send them all before 10ms have ellapsed.

5,697 Views
freescale_satya
Contributor III
Hi Lundin, Thankyou for the reply. The last paragraph was very useful and informative for me. Just I was also thinking i can some how use Xgate to reduce the time. Thanks once again, regards, Satya
0 Kudos
Reply
5,697 Views
Lundin
Senior Contributor IV

The calculation is on bus load only: the time it takes to send the messages over the copper wires on the CAN bus.

 

So an X-gate won't solve anything. This is very fundamental physics... distance = speed * time, where the distance in this case is the number of bits that needs to be spitted out.

0 Kudos
Reply
5,697 Views
freescale_satya
Contributor III
Hi Lundin, I was speaking about the xgate only because if the core S12x has started transmitting the first of the 14 messages let us say and then at the same time if it starts receiving messages then the S12x would be interrupted and it would start processing the received messages instead of transmitting messages and delay would happen depending on the number of received messages. so i want to separate the tx and rx parts. Please let me know if iam correct in my understanding. thanks and regards, Satya
0 Kudos
Reply
5,697 Views
kef
Specialist I

With adequate software, interrupts should not delay transfer times a lot. Even at 1Mbps single CAN message takes about 0.1ms. That's plenty of CPU time even at minimum required oscilator/PLL clock (16MHz is enough, not sure about less than that).

While your messages are being transferred you can't receive other messages, unless your node loses arbitration because other node is sending higher priority messages, which will delay you much more than CPU interrupt processing time.

 

0 Kudos
Reply
5,697 Views
Lundin
Senior Contributor IV

Also, MSCAN has 5 RX buffers. Depending on how many messages you expect to receive during a certain time period, this may be enough. And unless they need to be served right away, there is perhaps no need for interrupts either.

0 Kudos
Reply
5,697 Views
freescale_satya
Contributor III
Yeah, I understood that Xgate is not required (big relief i need not program it!!). My only concern is that the first message with a periodicity of 20ms takes a min time of 23msec and max of 30msec and the message with a periodicity of 1000ms takes a minimum of 1257 and maximum of 1267ms. I think i have to now look into my RTOS scheduler whether it is working properly or not? Thanks once again, regards, Satya
0 Kudos
Reply
2,257 Views
PU1
Contributor II
Hi Satya,
I am also facing same problem.
How you solved this?
0 Kudos
Reply