CAN controller


574 posts   Page 4 of 23   1, 2, 3, 4, 5, 6, 7 ... 23
by maddin1234 » Sat Aug 18, 2012 8:19 am
Hi bertr2d2,
two CAN controller on the same interrupt won't work without modifying
the module code. IMHO you need another GPIO for the second interrupt.

I think the second interrupt is the problem. I read in the BCM hardware manual,
that GPIO has only one interrupt per bank. Otherwise I won't have come to the
idea to use the same interrupt.
If it is true with the ONE interrupt line, it could be possible to use the RX0BF and
RX1BF lines from each controller and connect them to normal GPIO inputs as CAN0_RX0BF, ...,CAN1_RX1BF.
The first thing to do in the interrupt service routine would then be to read the GPIO inputs and
decide which Buffer to read.

Or doing it with software, reading the CANINTF registers of both can controllers on receiving
an interrupt. It would be just 3 more bytes to transmit over SPI.
Compared to the 100us that the driver needs to start reading (as you described on your homepage) and the 15 Bytes to read for a message, I think it is not too long.

But I try to avoid changing the module, because I thing it will take very long to understand it.

Changing the board definition will only change the kernel. That's where the structure is stored. Make is smart enough to realize, which code depends on each other and just compile only
which are needed to compile. The mcp251x module asking the kernel for the informations
on startup so it doesn't need to be recompiled if the structure changed. 'make module' should compile the modules.

that the way that I expected it to be, but unfortunatly, it didn't work yesterday.
I changed the board defintion, executed "make; make modules; make modules_install""
copied the kernel into /boot/ and rebooted, but the calculation for CNF1...CNF3 stayed the same.

I will try it again, perhaps I have forgotten a step.
Posts: 68
Joined: Sat Aug 04, 2012 8:33 pm
by bertr2d2 » Sat Aug 18, 2012 3:04 pm
Hi maddin1234,

I think the second interrupt is the problem. I read in the BCM hardware manual,
that GPIO has only one interrupt per bank. Otherwise I won't have come to the
idea to use the same interrupt.


Hmm, tested it with the gpio-test code:
Code: Select all
...
        irq_number = gpio_to_irq(24)
....
[809314.117129] GPIO_RESET: requesting IRQ 109-> fine
[809332.522882] gpio_reset module unloaded


which is different to GPIO 25 IRQ -> 110. Actually I am more than 2000 km away from my RPi
so I can't really test. But it seems that the GPIO 24 uses a different IRQ than GPIO 25.

Regards

bertr2d2
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by maddin1234 » Sat Aug 18, 2012 6:44 pm
That's what the broadcom manual says:
The GPIO peripheral has three dedicated interrupt lines. These lines are triggered by the
setting of bits in the event detect status register. Each bank has its’ own interrupt line with the
third line shared between all bits.

Maybe it's the shared one.
Posts: 68
Joined: Sat Aug 04, 2012 8:33 pm
by kiwi64ajs » Sun Aug 19, 2012 1:48 pm
Hi Guys,

I just got my RPi + MCP2515 working as well after following the instructions here:
http://lnxpps.de/rpie/

Here's a picture:
IMG_1826-Small.jpg
Picture of my RPi + MCP2515 board from: http://www.futurlec.com/Mini_CAN_Board.shtml
IMG_1826-Small.jpg (41.44 KiB) Viewed 1506 times

Many thanks for those who have sorted this out.

Does anyone know if this will be submitted to the Rasbian kernel maintainers so it gets included in the released downloads?

Regards

Alex Shepherd
Posts: 5
Joined: Thu Nov 03, 2011 9:10 pm
by maddin1234 » Thu Aug 23, 2012 4:36 pm
Hi,
I have an idea, how it might work with the interrupts on the GPIO header.

According to the GPIO manual, INT 52 is one of the GPIO Interrupts.
With $ cat /proc/interrupts
we can see what is registered to this interrupt.

52: 2 ARMCTRL BCM2708 GPIO catchall handler

It looks like this "catchall handler" has a look which PIN is the source
of the interrupt an raises a new interrupt with another number for each Pin.
For example 110 for GPIO25 and 109 for GPIO24
Posts: 68
Joined: Sat Aug 04, 2012 8:33 pm
by bertr2d2 » Fri Aug 24, 2012 1:04 pm
Hi,
kiwi64ajs wrote:Hi Guys,

Does anyone know if this will be submitted to the Rasbian kernel maintainers so it gets included in the released download ?


The board specific part differ from the MCP2515 linkage to the RPi - the CAN modules are
independent. I'm working on a solution to avoid recompiling the kernel. If the CAN modules
are part of the distribution there will be only need to redefine the SPI board definition to get
CAN working.

Alex, would you be so kind to contact Raspbian wizards to add the CAN modules to the
distribution ?


Regards

bertr2d2
Last edited by bertr2d2 on Fri Aug 24, 2012 1:16 pm, edited 3 times in total.
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by bertr2d2 » Fri Aug 24, 2012 1:06 pm
Hi maddin1234

maddin1234 wrote:Hi,

For example 110 for GPIO25 and 109 for GPIO24


did you tried to link a second MCP2515 to the RPi ? Any results ?
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by maddin1234 » Fri Aug 24, 2012 4:35 pm
Hi,
yes, I connected the second one yesterday and for a short test, it worked.

ip link set can0 ... and ...can1... was fine
Interrupt 109 and 110 were used.
and sending worked on both CANs.

I didn't check in detail, how it works for example with
logging on both can's, how the interrupts influence
each other, or better the performance of the other.

This was the struct I used to define spi-devices

Code: Select all
    static struct spi_board_info bcm2708_spi_devices[] = {
          {
                .modalias = "mcp2515",
                .max_speed_hz = 10000000,
                .platform_data = &mcp251x_info,
                .irq = 110,
                .bus_num = 0,
                .chip_select = 0,
                .mode = SPI_MODE_0,
          } , {
                .modalias = "mcp2515",
                .max_speed_hz = 10000000,
                .platform_data = &mcp251x_info,
                .irq = 109,
                .bus_num = 0,
                .chip_select = 1,
                .mode = SPI_MODE_0,
          }
    };
Posts: 68
Joined: Sat Aug 04, 2012 8:33 pm
by Benoit » Sun Aug 26, 2012 6:53 pm
Hello,

First thanks for all the work done on getting the MCP2515 working on Raspberry.

After playing with a working home-made extension board, I could see some repeated frames on the CAN bus, which, after debugging my code, were not initiated by me. So I went down to the kernel module, and there also, only one frame was sent where I could see two on the wires (using an oscilloscope, with real time CAN decoding).

Finally, I came on an errata from Microchip:

http://ww1.microchip.com/downloads/en/D ... 80179g.pdf

Section 5 says:
Holding CS low for a long time after an SPI command
which initiates a CAN message may keep the CAN
transmit request “pending”, causing the CAN message
to be repeated.
There are two cases where this happens:
1. Generating an “SPI RTS” command while in SPI Mode 11 (Mode 00 is not affected)
2. Generating an “SPI Byte Write” to set the transmit request (TXREQ) bit directly while in either SPI mode

The current kernel driver for MCP251x uses a TXREQ bit set to initiate the frame transmission. Additionnaly, the driver seems to enforce a mode 0 in mcp251x_can_probe():
Code: Select all
/* Configure the SPI bus */
   spi->mode = SPI_MODE_0;
   spi->bits_per_word = 8;
   spi_setup(spi);
So I replaced the transmission initiation by an RTS instruction as instructed in the Microchip Errata and it seems to solve the problem.

Here is the patch in case someone would like to test it further:

http://www.pouic.info/public/mcp251x.c- ... own+.patch

Kind Regards,

Benoît.
Posts: 10
Joined: Sun Aug 26, 2012 6:18 pm
by Benoit » Mon Aug 27, 2012 5:29 am
Hi,

To illustrate this bug, here are two oscilloscope screenshots:

Image
Image 1: CAN frame is repeated after about 44µs (standard mcp251x.c code)

Image
Image 2: CAN Frame is not repeated anymore, using RTS instruction to initiate the transmission(patched mcp251x.c)

We can correlate the delay stated in the Errata document of 47µs on CS to avoid the problem and the 44µs here.

Kind Regards,

Benoît.
Posts: 10
Joined: Sun Aug 26, 2012 6:18 pm
by bertr2d2 » Mon Aug 27, 2012 7:49 am
Salut Benoit,

a good catch ! There was a patch on the SocketCAN mailing a year ago:
http://old.nabble.com/-PATCH--mcp251x%3 ... 31106.html
but the patch didn't get into the mainline kernel yet - strange.

Regards

bertr2d2
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by Benoit » Mon Aug 27, 2012 7:56 am
Hi bertr2d2,

Thanks for this interesting link, it uses a very similar approach indeed.

Maybe it's time to have it integrated into the kernel: would you know who to contact for this?

Kind Regards,

Benoît.
Posts: 10
Joined: Sun Aug 26, 2012 6:18 pm
by bertr2d2 » Mon Aug 27, 2012 8:37 am
Hi Benoit,

Benoit wrote:Maybe it's time to have it integrated into the kernel: would you know who to contact for this?


IMHO the best place is the SocketCAN mailing list:
http://dir.gmane.org/gmane.linux.can

Regards

bertr2d2
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by Benoit » Mon Aug 27, 2012 1:33 pm
Patch submitted.

Kind Regards,

Benoît.
Posts: 10
Joined: Sun Aug 26, 2012 6:18 pm
by bertr2d2 » Tue Aug 28, 2012 9:15 pm
Hi,

I have tied a LPC1768 board to my RPi + MCP2515 and did some tests.
I've skipped 3.1.9 and using the 3.2.27 kernel now.
AT 33% busload at 1000kb:
Code: Select all
canbusload 2012-08-28 22:39:42
 can0@1000000  2179  335566 139456  33% |XXXXXX..............|

I observe errors due to overruns:
Code: Select all
root@raspberrypi ~/spi/module # ip -s -d link show can0
25: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 10
    link/can
    can state ERROR-ACTIVE restart-ms 0
    bitrate 1000000 sample-point 0.750
    tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
    mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
    clock 8000000
    re-started bus-errors arbit-lost error-warn error-pass bus-off
    0          0          0          0          0          0         
    RX: bytes  packets  errors  dropped overrun mcast   
    18782624   2347828  1315    0       1315    0     
    TX: bytes  packets  errors  dropped carrier collsns
    0          0        0       0       0       0     

The CAN module and friends take 66% percent of the CPU:
Code: Select all
  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                 
 6720 root      20   0     0    0    0 S  33.8  0.0   4:10.92 kworker/u:0                                                                                                             
 8539 root     -51   0     0    0    0 S  30.3  0.0   2:46.42 irq/110-mcp251x                                                                                                         
 8123 root      20   0     0    0    0 S   2.9  0.0   1:37.95 kworker/u:1               

Has anybody else made some tests and would share the results here ?

Regards bertr2d2
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by Benoit » Wed Aug 29, 2012 10:59 am
Hi bertr2d2,

At home I have a test setup with an mbed (LPC1768 flavor) + Raspberry Pi: at the end of the day, I'll try with a bus speed of 1Mbps and post back the results here.

Kind Regards,

Benoît.
Posts: 10
Joined: Sun Aug 26, 2012 6:18 pm
by Benoit » Wed Aug 29, 2012 3:16 pm
Here are some tests:

mbed@1Mbps, Raspberry Pi@1Mbps. mbed floods packets on Raspberry Pi, and the following happens:

mcp251x irq overhead: 24% CPU
Code: Select all
 1820 root     -51   0     0    0    0 D  24,3  0,0   0:12.75 irq/110-mcp251x

CAN bus load:
Code: Select all
canbusload 2012-08-29 17:11:43
 can0@1000000  2667  232029  21336  23% |XXXX................|

link stats:
Code: Select all
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 10
    link/can
    can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 0
    bitrate 1000000 sample-point 0.700
    tq 100 prop-seg 3 phase-seg1 3 phase-seg2 3 sjw 1
    mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
    clock 10000000
    re-started bus-errors arbit-lost error-warn error-pass bus-off
    0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    151820     134666   20544   0       20544   0
    TX: bytes  packets  errors  dropped carrier collsns
    34324      17162    0       0       0       0

When I don't run candump in parallel, bus load increases to 33% also:
Code: Select all
 can0@1000000  3772  328164  30176  32% |XXXXXX..............|

Not playing so nice...

It reminds me about this paper on improving MCP2515 linux driver: http://www.can-cia.org/fileadmin/cia/fi ... unilla.pdf

This WCCD (Wapice Custom Can Driver) definitely seems interesting! LinCAN might also be worth a look.

Kind Regards,

Benoît.
Posts: 10
Joined: Sun Aug 26, 2012 6:18 pm
by bertr2d2 » Wed Aug 29, 2012 4:01 pm
Hi Benoit,

thx sharing your results - they aren't that bad:
Your did the test with more than 3000 packets a second. I've used extended frames
with 8 data bytes - the longest frame size possible. So my error rate is lower.
In normal situation you would apply a filter which will decrease the data and the error rate.

Nevertheless the results are below my expectation but the RPi has some reserves IMHO.
It's not only the MCP2515 which generates a high IRQ rate. The SPI driver doing more
interrupts - im my case a six time fold.
The hardware SPI has FIFOs and can use DMA. I believe that the SPI driver doesn't
use this yet:

https://groups.google.com/forum/?fromgr ... um/bcm2835

maddin (maddin1234?) mentioned some tests there regarding SPI performance
and improvements. Time to delve into the SPI code ...

The WCCD seems to be promising. Did you find the source code anywhere ?


Regards

bertr2d2
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by Benoit » Wed Aug 29, 2012 4:18 pm
bertr2d2,

By curiosity, I ran the mbed with transmission of full extended frames with 8 bytes:
Code: Select all
 can0@1000000  3836  590744 245504  59% |XXXXXXXXXXX.........|
Kind Regards,

Looking at the mcp251x driver, it seems, that hardware filters are not implemented.

Benoît.
Posts: 10
Joined: Sun Aug 26, 2012 6:18 pm
by maddin1234 » Wed Aug 29, 2012 7:19 pm
Hi bertr2d2,
good guess, yes these posts are also from me.
I tried this first, but found out, that it will not work with user software, so I switched to the kernel modules.

I had a short try to change the modules, but found that it will take more time than I'd like to spend.

The first thing I would observe is, what causes the great latency between interrupt and first SPI activity.
I have the sneaking suspicion that it comes from the split into two modules (spidev and mcp251x).
From what I read so far, the sysfs (virtual file system) is very often used for communication between modules and programs in userspace. Maybe, mcp251x and spidev also communicate through this method. To get the maximum performance out of the raspberry pi, it could be a good idea to put all code into the same module.
Posts: 68
Joined: Sat Aug 04, 2012 8:33 pm
by kiwi64ajs » Wed Aug 29, 2012 9:16 pm
These test look to all be at 1Mbps. Can anyone comment on the likely performance at 125kbps?

I'm hoping it will work just fine and easily keep up at that much slower rate, but has anyone got an idea of the load at the bit rate as I don't have any special test gear to measure such things.

Regards

Alex Shepherd
Posts: 5
Joined: Thu Nov 03, 2011 9:10 pm
by bertr2d2 » Thu Aug 30, 2012 7:47 am
Hi,

kiwi64ajs wrote:These test look to all be at 1Mbps. Can anyone comment on the likely performance at 125kbps?

AlexB testeted with 90%@500kbps without errors - 125kbps shouldn't be a problem.
I'm testing with 1Mbps because I want to know where the limit is.

Regards

Gerd
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by bertr2d2 » Thu Aug 30, 2012 7:52 am
Benoit wrote:Looking at the mcp251x driver, it seems, that hardware filters are not implemented.

Ups - thought the driver uses the MCP2515 filter ...
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm
by Benoit » Thu Aug 30, 2012 2:43 pm
kiwi64ajs wrote:These test look to all be at 1Mbps. Can anyone comment on the likely performance at 125kbps?

[...]

Regards

Alex Shepherd


Here are the same tests run at different speeds:
Code: Select all
 can0@1000000  3836  590744 245504  59% |XXXXXXXXXXX.........|
 can0@500000   1312  202048  83968  40% |XXXXXXXX............|
 can0@250000   1303  200662  83392  80% |XXXXXXXXXXXXXXXX....| 
 can0@125000    791  121814  50624  97% |XXXXXXXXXXXXXXXXXXX.|
Best Regards,

Benoît.
Posts: 10
Joined: Sun Aug 26, 2012 6:18 pm
by bertr2d2 » Thu Aug 30, 2012 3:30 pm
Benoit wrote:
kiwi64ajs wrote:These test look to all be at 1Mbps. Can anyone comment on the likely performance at 125kbps?

[...]

Regards

Alex Shepherd


Here are the same tests run at different speeds:
Code: Select all
 can0@1000000  3836  590744 245504  59% |XXXXXXXXXXX.........|
 can0@500000   1312  202048  83968  40% |XXXXXXXX............|
 can0@250000   1303  200662  83392  80% |XXXXXXXXXXXXXXXX....| 
 can0@125000    791  121814  50624  97% |XXXXXXXXXXXXXXXXXXX.|
Best Regards,

Benoît.


Do you see any errors with speeds < 1Mbps ?
97% load is harsh - there might be errors not sourced by the mcp251x module.

Regards

Gerd
Posts: 87
Joined: Wed Aug 08, 2012 10:12 pm