I am working on a project using the CAN library to communicate over the CAN bus, and have successfully ran the CAN demo code to talk CAN over an Apalis and Colibri eval board. I have also successfully ran the interrupt demo code, using GPIO and a pushbutton on Apalis eval board to generate an interrupt.
I would like to be able to use an interrupt when sending/receiving CAN messages,
What is the suggested method to configure an interrupt for this purpose?
Thank you.
CAN controller generates interrupts when messages are sent/received, but this is managed by the CAN library, you can’t attach directly to it.
But returning of send/receive function should mean that message has been sent/received.
Can you provide me a “bigger picture” view of what you are trying to do? We may found a suitable solution using current libraries.
Currently use an interrupt to call CAN read/write with an Atom processor, and will be replacing this older technology with your Apalis iMX6 SoM with WEC7.
Do I need to be concerned about interrupts with the Toradex CAN library?
For example, Can_Read() is called with Timeout set to INFINITE, and just waits for CAN messages. Does this require any additional support?
If you use the libraries, the underlying layers will take care of the interrupts and CAN_Read will return as soon as a packet has been received.
If you receive heavy messages from CAN network, the message will be lost even though the function called in loop.
I think the library have to implement a queue buffer to store received messages temporary before host program call CAN_Read function API. also the API provide function to set the size of buffer up to 1M byte.
It’s very serious issue in automotive solution.
Actually the library has an internal queue of up to 255 messages. IST runs at priority 10, so should be above the priority of most of the threads running on the OS. You can try to increase priority of the thread processing CAN packets to be above that of regular apps.
At what baudrate are you testing? How many packets per second are you sending to the device?
High speeds are needed because many devices are connected to the board.
I usually use either 500MHz or 1 MHz. Also I restrict load to not exceeding 70 per cent.
When I keep 80 percent load, the sometimes boards lose one or two packet even if it is in an infinite loop.
I think the size of queue too small. Typical commercial CAN devices have big buffers.
Would you provide fucntion to change internal buffer size (parameter)
and also function to detect overload
As I said we have an internal queue that is 255 packets long, this should keep packets for a few ms, even at your current speed.
Did you check priorities of your IST (parameter in the library) and application threads?
Do you get any debug message on VS (if you run your application in debug mode) or on the serial port (if you run it in release)? Overrun of internal HW FIFO or software queue are reported on the debug output.