interesting pics nexulm. One thing seems to be still not solved from the SPI driver: during SPI transfer the CS line is still low a long time after the the last bit clock (1st pink -> CS , 2nd pink SCLK):

There is a flag for the SPI-DMA transfer which should raise the CS line automatically after
last bit was transfered. Does the new SPI driver use DMA with this flag on?
The async MCP2515 code from Andre B. Olivera wasn't tested a lot. Do you see the same problems with the mcp251x.c from a brand new kernel ? The latest mcp251x driver was been fixed some time ago; don't know if this will fix your problem. The vanilla mcp251x driver may not be the fastest but the most tested version.
BTW: Do you use this version form Andre B. Olivera: http://lnxpps.de/rpie/mcp2515_mod.c ?
IMO 30us is excellent, but you can't rely on this value. Plain vanilla Linux isn't a realtime system.nexulm wrote:Two question from my side regarding the measurments are:
1. Why is there a delay of round about 30us between Interrupt Low of MCP2515 and SPI-Chip Enable?
And the RaspberryPi needs to do lots of things in the background, e.g. the USB/Ethernet Bridge
generates 8000 interrupts per second. You don't see them because they are done with FIQ.
You are right: the missing system speed shouldn't break the functionality. There should be only missing frames.Zeta wrote:I agree the processing power is not the only problem here. Even if we miss some frames, which would be directly related to some "horse power" and architecture (our choice of using MCP2515 with only 2 buffers, and using 2 of them on the same SPI bus) limitations, it shouldn't simply stop working.nexulm wrote:For me that's not a problem of the "horse power" of BCM2835. Maybe it's more a general linux driver structure and interrupt priority questions, or? But I don't know th linux driver achitecture good enough so far. Furthermore IMO it doesn't depend directly on one-shot-irq because I've seen the same problem with Kernel 3.2.27 with Level-triggerd interrupt.
Could you get the MCP2515 register values after the controller stopped transmitting frames ?
Would it be possible, that you adapt (vcanx -> canx and loopback the physical interfaces) my code above an try to run it with 1Mbps ? I'm interested which load this will generate on the CAN bus with the Olivera driver and the normal code.
Regards
Gerd