MCP2515 implementation is slow

MCP2515 implementation is slow

[Pankajkumar Misra (RBEI/EEA2)]

Hello Guys,

I have compiled MCP251x.c kernel driver module for Olimex A20-Olinuxino Micro.

The device is working fine for one frame at a time at 500ms. If I send two or more frame at the same time,
CAN is going to bus-off due to overrun errors.
Even if I send one frame at faster rate say, 100ms,results in bus-off.

I am communicating with module with ip commands, cansend & candump.
Also my SPI module is working only at 250K baud, not any other baud.

Any suggestions.

Best Regards,
Pankaj

Re: MCP2515 implementation is slow

[gianluca]

On 11/25/2014 05:19 PM, Pankajkumar Misra (RBEI/EEA2) wrote:
> Hello Guys,
>
> I have compiled MCP251x.c kernel driver module for Olimex A20-Olinuxino Micro.
>
> The device is working fine for one frame at a time at 500ms. If I send two or more frame at the same time,
> CAN is going to bus-off due to overrun errors.
> Even if I send one frame at faster rate say, 100ms,results in bus-off.
>
> I am communicating with module with ip commands, cansend & candump.
> Also my SPI module is working only at 250K baud, not any other baud.
>
> Any suggestions.
>
> Best Regards,
> Pankaj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Once upon a time there were a custom mcp2515.c driver rewritten by 
Oliveira and modified by myself to obtain the maximum performance 
possible with this VERY POOR chip.

http://clientes.netvisao.pt/anbadeol/mcp2515.html

If you are interested, please feel-free to contact me to obtain a 
modified version (maybe better? :-P ) of this driver.

Actually it runs on a 2.6.27 kernel with a Samsung S3C2442 SoC. It runs 
without any problem running @ 250Kbit/s and 125Kbit/s with some burst of 
a frame every 2 or 4 msecs. For sure your application has to be 'niced' 
to a be almost-real-time over other processes and the socket receive 
queues have to be increased a little bit.
But it works good over the past 3 years with approx. 1k custom boards 
batch worldwide sold.

It would not so difficult to adapt it to run over a 3.x kernel and maybe 
in a near future I will add a DEVICE TREE support for it.

Best regards,
-- 
            ,,,
           (o o)
======oOO==(_)==OOo======

Gianluca Renzi
R&D
phone: +39.0542.609120
fax:   +39.0542.609212

       .oooO  Oooo.
======(   )==(   )=======
        \ (    ) /
         \_)  (_/

===================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
  \ source code!  /
   ---------------
     ¯\_(".)_/¯

RE: MCP2515 implementation is slow

[Pankajkumar Misra (RBEI/EEA2)]

Thanks Gianluca,

But we are doing it on Kernel version 3.4.

Lets see what is possible.

Best Regards,
Pankaj

-----Original Message-----
From: gianluca [mailto:gianlucarenzi@eurekelettronica.it] 
Sent: 25 नवम्बर 2014 22:18
To: Pankajkumar Misra (RBEI/EEA2)
Cc: linux-can@vger.kernel.org
Subject: Re: MCP2515 implementation is slow

On 11/25/2014 05:19 PM, Pankajkumar Misra (RBEI/EEA2) wrote:
> Hello Guys,
>
> I have compiled MCP251x.c kernel driver module for Olimex A20-Olinuxino Micro.
>
> The device is working fine for one frame at a time at 500ms. If I send two or more frame at the same time,
> CAN is going to bus-off due to overrun errors.
> Even if I send one frame at faster rate say, 100ms,results in bus-off.
>
> I am communicating with module with ip commands, cansend & candump.
> Also my SPI module is working only at 250K baud, not any other baud.
>
> Any suggestions.
>
> Best Regards,
> Pankaj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Once upon a time there were a custom mcp2515.c driver rewritten by 
Oliveira and modified by myself to obtain the maximum performance 
possible with this VERY POOR chip.

http://clientes.netvisao.pt/anbadeol/mcp2515.html

If you are interested, please feel-free to contact me to obtain a 
modified version (maybe better? :-P ) of this driver.

Actually it runs on a 2.6.27 kernel with a Samsung S3C2442 SoC. It runs 
without any problem running @ 250Kbit/s and 125Kbit/s with some burst of 
a frame every 2 or 4 msecs. For sure your application has to be 'niced' 
to a be almost-real-time over other processes and the socket receive 
queues have to be increased a little bit.
But it works good over the past 3 years with approx. 1k custom boards 
batch worldwide sold.

It would not so difficult to adapt it to run over a 3.x kernel and maybe 
in a near future I will add a DEVICE TREE support for it.

Best regards,
-- 
            ,,,
           (o o)
======oOO==(_)==OOo======

Gianluca Renzi
R&D
phone: +39.0542.609120
fax:   +39.0542.609212

       .oooO  Oooo.
======(   )==(   )=======
        \ (    ) /
         \_)  (_/

===================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
  \ source code!  /
   ---------------
     ¯\_(".)_/¯

Re: MCP2515 implementation is slow

[gianluca]

On 11/26/2014 06:02 AM, Pankajkumar Misra (RBEI/EEA2) wrote:

> But we are doing it on Kernel version 3.4.
>
>>
>> http://clientes.netvisao.pt/anbadeol/mcp2515.html
>>
>> Actually it runs on a 2.6.27 kernel with a Samsung S3C2442 SoC. It runs
>> without any problem running @ 250Kbit/s and 125Kbit/s with some burst of
>> a frame every 2 or 4 msecs. For sure your application has to be 'niced'

I've told you it runs for sure on 2.6.27.

> Lets see what is possible.

I think with some minor changes to the SPI API it is a viable way to do.

If you reach a working driver why not including it in the -next linux 
merge window??

Regards,
-- 
            ,,,
           (o o)
======oOO==(_)==OOo======

Gianluca Renzi
R&D
phone: +39.0542.609120
fax:   +39.0542.609212

       .oooO  Oooo.
======(   )==(   )=======
        \ (    ) /
         \_)  (_/

===================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
  \ source code!  /
   ---------------
     ¯\_(".)_/¯

RE: MCP2515 implementation is slow

[Rost, Martin]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

Hi all,

> this VERY POOR chip.
As the mcp251x is voted down by the list members regularly, is there an alternative you guys would recommend?


Best regards

Martin Rost

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2015 bytes --]

Re: RE: MCP2515 implementation is slow

[Andri Yngvason]

Quoting Rost, Martin (2014-11-26 12:02:13)
> Hi all,
> 
> > this VERY POOR chip.
> As the mcp251x is voted down by the list members regularly, is there an alternative you guys would recommend?
> 
Well, sja1000 is pretty solid. They're used for example in the peak_pci.

--
Andri

Re: MCP2515 implementation is slow

[David Jander]

On Wed, 26 Nov 2014 12:32:42 +0000
Andri Yngvason <andri.yngvason@marel.com> wrote:

> Quoting Rost, Martin (2014-11-26 12:02:13)
> > Hi all,
> > 
> > > this VERY POOR chip.
> > As the mcp251x is voted down by the list members regularly, is there an
> > alternative you guys would recommend?
> > 
> Well, sja1000 is pretty solid. They're used for example in the peak_pci.

It is actually pretty sad that one still tends to mention this old dinosaur.
It has a terribly slow parallel multiplexed bus-interface that works on 5V. If
you want to connect it to a modern ARM SoC, you will have to implement some
quite expensive level-shifting and then probably bit-bang the interface via
GPIO's or use an (even more expensive and complicated) CPLD or FPGA to do the
bus-translation. You are kidding, right?

To go back to the sad reality of CAN interfaces: No, there seems to be no
good alternative whatsoever.

If you want SocketCAN on an embedded system, choose a SoC that has built-in CAN
controllers or connect a supported commercial CAN interface via USB or (if you
have it) PCIe. Please note that many commercial (USB-) CAN-interfaces are not
capable of producing 100% bus load at higher bitrates. USB has too much
latency and the dongles tend to have too little buffer-space (there's often a
SJA1000 crammed up inside).

Best regards,

-- 
David Jander
Protonic Holland.

Re: MCP2515 implementation is slow

[David Jander]

On Tue, 25 Nov 2014 16:19:33 +0000
"Pankajkumar Misra (RBEI/EEA2)" <Pankaj.Kumar@in.bosch.com> wrote:

> I have compiled MCP251x.c kernel driver module for Olimex A20-Olinuxino
> Micro.
> 
> The device is working fine for one frame at a time at 500ms. If I send two
> or more frame at the same time, CAN is going to bus-off due to overrun
> errors. Even if I send one frame at faster rate say, 100ms,results in
> bus-off.

I tend to think there is something other wrong with your setup. Maybe you are
missing bus-termination/biasing? Chip-clock?
The device should never go in bus-off mode if there are RX-overruns. If it
goes into bus-off, there is something wrong in the hardware.

> I am communicating with module with ip commands, cansend & candump.
> Also my SPI module is working only at 250K baud, not any other baud.

We use a MCP2515 with this driver at 250kbit/s receiving back-to-back messages
without loss on a i.MX51. Please note, that it won't work reliably at any
higher bitrate and system load is quite high.

The MCP2515 is a very bad design, but the driver performance has improved a lot
since spi-bitbang started using a kthread instead of a work-queue.

> Any suggestions.
> 
> Best Regards,
> Pankaj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Best regards,

-- 
David Jander
Protonic Holland.