I2C SPI USB CAN eSPI Cable Testing View All Videos Quick Start Guides Software Downloads App Notes White Papers User Manuals Knowledge Base Sales Support About Us
Products Blog Sales Support Contact Search
How Can I Set a Timeout to Minimize OS Latency when Interfacing on the CAN Bus?
Rena Ayeras

Question from the Customer:

I am using the Komodo CAN Duo Interface with Komodo Software API. My understanding is that the timeout of the command km_latency() should be set to less than the timeout value used in the command km_timeout(). However, setting the value to KM_TIMEOUT_IMMEDIATE, or 1ms – I don’t see how it is possible to fulfill this timing requirement.

My questions:

  • What is the correct usage of latency when using KM_TIMEOUT_IMMEDIATE for km_timeout()?
  • What are the interactions with timeout?
Response from Technical Support:

Thanks for your questions! The following sections, show the recommended methods for your setup, and describe the relationship of the operating system (OS) latency and timeout.

Setting Latency for the Desired Timeout

We have two recommendations for setting the latency value for your setup.

Set the Latency to 0

When the latency is set to 0 (zero), the function sends the appropriate value for the firmware to terminate the USB Request Blocks (URB) for each CAN packet to be sent back to the OS. This method ensures the smallest latency possible.

Set the Latency Relative to Measured Time

Measure the time it takes for your CAN packet read in km_can_read() to execute, and then set the latency for less than that measured time.

The Relationship of the Operating System and Timeout

There is an inherit latency that occurs when managing USB traffic as asynchronous URBs on the host PC. This latency occurs because the OS only sees data when an URB is either entirely filled, or the USB packet is short (terminated before the URB size is reached).

How the Timeout Command Works

Here is an example of how timeout works.

In this scenario, the USB Request Blocks (URB) are sized to 100 bytes, and each CAN packet only consumes 20 bytes of USB data.

In this case, you would need to see five packets to get any USB data back to the OS. However, seeing five packets may take some undefined period of time. For a controlled latency, the Komodo interface issues a short packet after the latency timeout has elapsed. This allows the data to become visible to the OS, and to the API script.

Timeout Values

Here is some information about the effects of timeout values:

  • When timeout_ms is set to the value KM_TIMEOUT_IMMEDIATE, timeout_ms becomes non-blocking and immediately returns
  • When timeout_ms is set to the value KM_TIMEOUT_INFINITE, then km_can_read is blocking until some data is received.

For more information, please refer to the API Documentation chapter of the Komodo CAN Interface User Manual

Additional resources that you may find helpful include the following:

We hope this answers your questions. If you have other questions about our CAN interfaces or other Total Phase products, feel free to email us at sales@totalphase.com. You can also request a demo that applies to your application.