Re: Linux board with 10 CANs

[Tom Evans <tom_usenet@optusnet.com.au>]

On 18/05/2015 7:40 PM, Gerhard Bertelsmann wrote:
> Hi Francois,
> Am Mo, 18.05.2015, 11:25, schrieb François Beaulier:
>> I know the MCP2515 may work in some situation but it depends on kernel
>> latency and that is very unpredictable.

You can always try running RT or Xenomai. I wouldn't recommend that.

We had trouble with Linux kernel latency, until I found our supplier had 
shipped Linux with a whole bunch of debugging turned on. We got rid of 
CONFIG_DEBUG_PAGEALLOC, SPIN, MUTEX, and SLUB debugging and it got a lot 
more responsive. I had to trace the kernel to find out where it was 
spending all its time (in SLUB debugging mainly).

We're running two FlexCAN ports, each with a 6-deep FIFO at 1MHz each. 
We're not having any problems now [1]. You're wanting to run at 1/20 of 
that data rate with 1/3 of the FIFO depth. That should work, even with 
10 of them running.

Note 1: The CAN driver deferred reading data to NAPI, the debugs were on 
and the (old non-NAPI) Ethernet driver happily kept pulling hundreds of 
Ethernet packets in during one interrupt, so I was getting CAN overruns. 
I rewrote the CAN driver to read message data during Interrupts, 
throttled Ethernet and added interrupt priority and turned the debugs 
off. Now it is fine.

>> What is helping in QSPI ?

Instead of your GHZ CPU having to wait for a 10MHz SPI bus to send a 
byte, or be interrupted once per byte, it can load up 16 multi-byte 
transactions and be interrupted when the whole thing is complete. I 
don't know how good the SPI drivers are and how well the Linux MCP2515 
driver supports this (if it supports the hardware queue). It looks like 
it reads a whole CAN message in a single SPI transaction though.

>> the main problem beeing latency between
 >> MCP irq and effective SPI transfer ?

Go Multicore and spread the load, or keep long latency stuff of the CAN 
core.

> The only concern that I have is the latency/overhead of the SocketCAN
> API with 10 CANs at high packet rates on 1 GHz ARM ...

The interrupts, NAPI and SocketCAN switches and code all add about the 
same overhead to each message processed. Multiple interrupts, a NAPI run 
and SocketCAN context switch for 8 bytes of user data (or maybe even one 
or no bytes) is a pain. CAN and Linux really weren't mean to get on and 
it shows.

Or you could run 5 complete CPUs, networked via Ethernet.

The USB solution looks good, as long as the USB is reliable.

Tom