Really long spiService call


#1

Hello everyone,

I’m using the iot card extension for can bus develops for Legato, for that I set up the SPI connection with the spiService.
But I’m having an issue : the time to recover the interruption from the iot card (when a CAN message is receive) and to get the CAN message through the SPI interface is really really long.

I measured with an oscilloscope the different signals on the card and the time needed to get the CAN message is 2000 us on average. With this value I can’t expect to read a CAN bus faster than 500Hz … this is far too low.

I measured with a c function the time to execute 2 spi instructions (read , read/write) and it’s 1200us (833 Hz)… this is absurd because an SPI connection is supposed to go to 1 MHz at least.

I suppose the delay com from the event Loop that call the differents functions (interruption,spiService). Is there a way to reduce this delay and alloy my connection to be quicker ?


#2

You could use the spiLibrary component directly rather than interacting with spiService. Take a look at the Component.cdef for spiService to see an example of how to reference spiLibrary directly. The interface presented by spiLibrary is nearly identical to spiService except that you have to obtain the file descriptor to the SPI device yourself and you pass around the fd instead of a le_spi_DeviceHandleRef_t.

The advantage of using spiLibrary directly instead of going through spiService is that you won’t pay IPC overhead for each SPI function called. Having said that, I’m not sure if IPC is the limiting factor. If you get a chance to try it and measure the results, please post a reply.


#3

Thank you very much dfrey, It works far better now !

I created my own unsandboxed application (to be able to read the file) then I created a component where I put le_spiLibrary.c and le_spiLibrary.h. I added my own files (main.c …).

At the beginning the execution time was even worse than before : 3000us (for one le_spiLib_WriteReadHD instruction). But then I commented all the LE_DEBUG and LE_ERROR in le_spiLibrary.c. And now my app runs faster: 500us (for one le_spiLib_WriteReadHD instruction).

(Note that the SPI communication itself is about 130 us long)

Here is the modified le_spiLibrary.c:
le_spiLibrary.c (9.2 KB)

Regards.
Guillaume


#4

But i still have a delay problem …

The CAN controller interruption (when a CAN message is receive) is process by Legato , and it’s too long : 700us.

  1. Legato see the interruption
  2. Legato put the handler associate to the interruption in the event_Loop
  3. The handler is on top of the loop and begin
  4. I use the SPI to look the message …

It’s really long and not natural because the interruption go up in the framework and then go down (from hardware to software).

I don’t understand why the SPI driver isn’t able to register a handler on an interruption, to be able to stay at the same hardware level and ignore the framework …