Re: AW: Receiving messages issue

[Marc Kleine-Budde <mkl@pengutronix.de>]

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

On 06/25/2013 02:00 PM, Gerhard Bertelsmann wrote:
>>> On 06/24/2013 02:26 PM, Luka Rahne wrote:
>>>> I am using MCP2515 with  i.MX27
>>>
>>> MCP2515 is the second worst CAN hardware I know. Only MCP2510 is worse.

> IMHO the controller isn't bad - it's the host interface (SPI).

I see the CAN controller as a black box, I don't care if it doesn't
perform under Linux due to the host interface or the fact that it has a
rather shallow FIFO.

> The MCP2515 based capes are using the BB SPI bus. As already stated before,
> the CAN controller is not read-out fast enough. Root cause of this is mainly
> the latency between MCP2515 interrupt and the SPI commands. I have seen
> this on different platforms: there are gaps sometimes in the 100usec range.
> The BBB is fast but there will be still gaps between MCP2515 attention needed
> and SPI transfers and on heavy loaded links there will be reordered packets
> or packet losts.
> One solution could be running the SPI with higher priority. Second one would
> be to tie SPI and MCP2515 driver together, but this is a quite dirty hack.

You probably don't want to do this.

> But the Beaglebone-CPU has a nifty thing: the PRUSS - 2x200 MHz CPUs
> independantly running from the main CPU. Coupling one or more MCP2515s
> to the appropiate pins could be easily served. The PRUSS doesn't have a
> hardware SPI interface, but with old school bitbanging you could get  all
> CAN packets even on fully loaded 1MBit link.

You can port the existing CAN driver (note it's GPL'ed) or write a new
one for the PRUSS and design a proper memory mapped interface interface
to the CPU.

> There is shared memory region between main and PRUSS CPU. Both CPU
> domains could generate an interrupt for the other domain. So the data
> could be easily exchanged - without any lost or reordered packets.

> BTW: Which structure would be the best for this kind of data transfer ?

IANAL: If you design the PRUSS firmware to be compatible to an existing
driver e.g. a SJA10000 you don't have to write a new driver under Linux.
However I'm not sure about the legal consequences of this.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]