msperl / mcp2515a Goto Github PK

Hi,

I've got several rx-overrun-problems with a MCP2515 board connected to a Raspberry Pi 3 B+.

I've read a lot about this. For example:
https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=19489
https://www.raspberrypi.org/forums/viewtopic.php?t=141052

I wonder that the problem still occurs. Isn't the low latency patch not part of the kernel? I'm using the latest Raspian in headless mode:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux

could you please write a short tutorial how to replace the existing MCP251x driver witht yours?

Thank you!

Hello @msperl,

Thanks for all your work on improving SPI latency in Linux. As you note, the situation in recent Kernel versions is quite different from when you created this patch, and I notice you have made several recent contributions to https://github.com/torvalds/linux too. I have read through these patches as best as I can, but I am struggling to understand what kind of latency I can expect to achieve today?

For example I am using a Raspberry Pi Model 3A+ with an MCP2515, queuing bursts of 6 back-to-back 8-byte EFF frames from the Pi at 1 Mbps, using SocketCAN, and a recent build of https://github.com/raspberrypi/linux. I was hoping to see transmissions at "close" to the best-case 128 us period, but instead observe frames sent every 260-300 us.

I have tried tweaking several parameters, such as fixing the CPU and GPU frequency, assigning SCHED_FIFO priorities to user and kernel threads such as "spi0", and building a custom kernel setting cs_change_delay to 0 ns in mcp251x.c, and ->rt = 1 in mcp251x.c and spi-bcm2835.c, but nothing has made any substantial improvement.

Is this the best latency I can hope to achieve today, or am I missing some setting or patch which I could apply?

All the best,
Matt

I replaced the mcp251x driver with this one and saw that the can_id (extended frame) no more are the same as they were with the stock driver that comes with the linux kernel sources (3.12.35 - raspberry pi).
I could not figure out why the extra shift by 11 bits is necessary.
I also did not check whether the can_id is used correctly when sending messages with extended frames.

A patch would be:
--- mcp2515a/mcp2515a.c 2015-02-26 16:09:16.486369756 +0100
+++ mcp2515a.c 2015-02-26 16:08:10.137055884 +0100
@@ -775,11 +775,11 @@
CAN_RTR_FLAG : 0)
/* the extended Address - top 2 bits */
| ((data[MCP2515_MSG_SIDL]&MCP2515_MSG_SIDL_EMASK)

•                           << (2*8+11))
  

•                           << (2_8))
                  /_ the extended Address EXTH */
  

•                   | (data[MCP2515_MSG_EIDH] << (1*8+11))
  

•                   | (data[MCP2515_MSG_EIDH] << (1_8))
                  /_ the extended Address EXTL */
  

•                   | (data[MCP2515_MSG_EIDL] << (0*8+11))
  

•                   | (data[MCP2515_MSG_EIDL] << (0_8))
                  ;
  } else {
          frame->can_id =
  

  @@ -790,8 +790,8 @@
  }
  /_ and add the standard header */
  frame->can_id |=

•           (data[MCP2515_MSG_SIDH] << 3)
  

•           | (data[MCP2515_MSG_SIDL] >> 5)
  

•           (((data[MCP2515_MSG_SIDH] << 3)
  

•           | (data[MCP2515_MSG_SIDL] >> 5)) << 18)
          ;
  /\* get data length */
  frame->can_dlc = get_can_dlc(