Interrupt Handling

[electronicsLearner]

Hi,

Suppose if i am transmitting a number of CAN messages both cyclic and event. Should I do this by setting the interrupt and leave it to the controller to transmit the messages. Does this method not an open loop type of transmission? Is it recommended?Or suppose if i check the message is successfully transmitted by some means of interrupt, does it not burden the controller? And how to keep track of the message and the interrupt for a huge number of messages. which is the best method? I am asking this question since when i tried to transmit the cyclic messages continuously i could not see all the messages getting transmitted then i had to give a dummy delay using a for loop to transmit all the messages so how to know these delay timings.

Thanks in advance.

 

[hevans1944]

What are you transmitting the CAN messages to? Is this a full-duplex or half-duplex communications link? Does the receiver of the CAN message implement either software or hardware flow control? Do you have the capability to implement either software or hardware flow control? Interrupts are usually used, with an interrupt handler or driver, to indicate when a transmit buffer is empty and ready to accept the next byte of a message. Similarly, the receive buffer can also generate an interrupt when a byte has been received. Either software or hardware flow control can be implemented, with or without interrupts, depending on data rate. The CAN bus usually uses software flow control since it is a two-wire multi-drop bus.

And of course the controller is burdened with all this housekeeping, but what do you care as long as it can keep up? Sending messages into the wind with no provision for acknowledgement of "message received" and no provision to allow the receiver to ask for a re-transmission if the message is corrupted, or for the sender to wait, is just asking for trouble. Each message is transmitted with a check-sum so the receiver can authenticate the message, right? See this Wikipedia article for information on the CAN standard.

Using "for loops" for communication timing (or any other timing) is not good programming practice. How can you know what hardware the "for loop" will execute on, or whether the operating system will suspend the thread while it allows another higher priority thread to run? It's semi-okay for embedded processor applications where you have complete control of the processor, but a real hardware timer running from a real clock oscillator is the right way to generate time delays. If you need to generate time delays for CAN bus communication, you have not properly implemented message flow-control.

Hop

 

[electronicsLearner]

Thank you very much for the quick response. I am using freescale controller which has in built CAN controller and it is a full duplex. I am transmitting the message to an ECU. I will modify the code to remove for loop and the modifications suggested by you.

 

[hevans1944]

That sounds good. Just make sure both the Freescale controller and the ECU implement a CAN flow-control protocol: each tests the check-sum on each received message, asks for a re-transmission if there is a check-sum error, and that both have adequate speed to process each message received (preventing receive buffer over-run) before the next message transmission begins.

 

[electronicsLearner]

The problem is i have no control on the other ECU messages but through a protocol message i can request for time delay in messages. The problem i am facing is I have to take messages from one channel and gateway to other channel without missing the sequence, but i am not able to maintain the sequence. This, as i said i set the transmit interrupt for the three received messages to transmit on other channel but somehow it is missing the sequence. i am not able to get the reason behind it. I am only setting the transmit interrupt of the three messages in the sequence but i am not actually verifying whether the message is on the bus. Is that the problem?

 

[hevans1944]

Sounds to me like you need some test equipment, such as a CAN bus monitor, to see what is actually going on.