---

Question from the Customer:

I could use some help for improving the CAN bus speed and the bus bandwidth usage. I am working with two devices: a Komodo CAN Duo Interface and a target device as the end point.

Both devices are communicating at the speed of 714 kHz. When I started, the first exchange frames had extra jitter. To resolve that issue, I configured the latency to the minimum value with the Komodo Software API command km_latency_function.  Afterwards, I now write 1 Megabits of data. The recorded timestamp shows a full exchange of about 90 seconds. Here are the details of my configuration for the Komodo CAN interface:

Initialization

1. Km_open (CAN port number used)
2. Define feature: KM_FEATURE_CAN_A_CONFIG + KM_FEATURE_CAN_A_LISTEN  + KM_FEATURE_CAN_A_CONTROL
3. Km_acquire (our features)
4. Km_can_bitrate (our bus speed)
5. Km_timeout (our timeout)
6. Km_can_target_power (set to off)
7. Km_enable (device used)
8. Empty the last received messages in the buffer (loop with km_can_read)

Send the frame:

1. Km_can_asyn_submit (can_handle, channel use, KM_CAN_ONE_SHOT, packet_information, size, the data frame)
2. Waiting acknowledge: km_can_async_collect (can_handle, timeout, arbitration count)

Receive the frame:

1. Km_can_read (can_handle, info, packet_information, size, the data frame)
2. Decode the frame and retrieve information

About the bandwidth occupancy – I am communicating with the end device through the Komodo CAN interface with the software running on the host computer. Using an oscilloscope, I see the bus is used less than 50% when performing a write operation in loop: uploading a large amount of data into the memory the end point device.

Here are my questions:

• How can I speed up the loading process and the bus speed?
• How can improve the bandwidth occupancy?

Response from Technical Support:

Thanks for your questions! To help improve asynchronous messages, we will first describe the buffering within the Komodo DLL. With that understanding, we will then go into optimizing the CAN bus performance.

Device Buffering and Asynchronous Messages

Here is an example of the Komodo CAN interface receiving CAN messages asynchronously.

1. The application calls the function to change the state of a GPIO. However, some unprocessed asynchronous messages are pending,
2. In this case, the Komodo CAN interface modifies the GPIO pin and saves any pending CAN messages internally.
3. As a result, the pending messages are held until the appropriate API function is called.

Active CAN vs. Passive Monitor

The Komodo CAN interface can be configured as an active CAN node or a passive monitor. A CAN channel can receive messages asynchronously with respect to the host computer software. Between calls to the Komodo API, these messages are buffered in memory, which is managed by the operating system of the computer host. The buffer size is limited. If the buffer is full, then bytes will be dropped.

Saturation - What Causes Overflow

An overflow can occur when the Komodo CAN interface receives asynchronous messages faster than the rate that they are processed – the receive link is "saturated". This condition can affect other synchronous communication with the Komodo CAN interface. Listed below are three ways to reduce saturation.

Reduce Traffic: In this case, the goal is reducing the amount of traffic between calls to the Komodo API. This method requires the ability to reconfigure the offending CAN device(s). Polling: In this case, poll the CAN channel to collect pending messages more frequently, which reduces storing messages in memory. API Write: We recommend using the km_can_write API program. This function acts as a wrapper for the asynchronous submit and collect functions. Here is an example:

km_can_async_submit(komodo, channel, flags,
packet, num_bytes, data);
km_can_async_collect(komodo, KM_TIMEOUT_INFINITE,
arbitration_count);

• The CAN packet is submitted asynchronously, and km_can_async_collect is called with KM_TIMEOUT_INFINITE to block indefinitely until a response is received.
• The KM_CAN_ASYNC_PENDING error is returned if there are any uncollected asynchronously submitted packets. Packets submitted with km_can_async_submit should always be collected using km_can_async_collect.

Optimize CAN Bus Speed

We have two suggestions for optimizing the bus speed: cable length and software threading.

Shorter Cables: Reducing the length of the wiring in use can help improve the bus speed. Threading: There are cases where the application requires multi-threading for a single Komodo CAN interface port. Each port of the Komodo CAN Duo Interface is independent - they can be used simultaneously in different threads. The Komodo Software API  that you have been using supports this function.

Each Komodo API call can be wrapped with a thread-safe locking mechanism before and after invoking the command. For details about threading and asynchronous messages, please refer to the Application Notes section of the Komodo CAN Interface User Manual.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Komodo CAN Interface User Manual
• Komodo GUI Software User Manual
• CAN Background

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.