Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Marcus Liebhardt]

Hi everybody!

Looking for a low-cost solution for a real-time Linux system with CAN
bus support, I am currently considering the Beaglebone [1] (similar to
the Beagleboard) with the addition of a CAN bus cape [2]. The later
provides two MCP2515 CAN controller and also allows the use of the
integrated CAN controller [3] of the Beaglebone's ARM microprocessor
(Cortex A8) .

I am thinking about using a Linux kernel plus the RT-patch
(CONFIG_PREEMPT_RT), since it seems to be less work then setting up
Xenomai and the MCP2515 is already supported by SocketCAN. However, I
am not sure, if this set-up will satisfy our real-time constraints,
since SocketCAN is not real-time safe. Furthermore, I couldn't find
information about working solutions of patched Linux kernels on the
Beaglebord besides this paper [4].
Hence, I am also looking into the option of using Xenomai on the
Beaglebone for which I found working examples, such as [4]. However,
according to this list [5] the MCP2515 is not supported by
RTcan/RT-SocketCAN. Is this still true?

Furthermore, is there support for the integrated CAN controller (AM35x
HECC) in SocketCAN and/or RT-SocketCAN?


Best regards,
Marcus Liebhardt

PS: Due to the information about SocketCAN on Gitorious, I also signed
up on linux-can@vger.kernel.org. In which case should one use that
list?
-> This questions got answered the auto-reply from
socketcan-users-bounces@lists.berlios.de (berlios mailing list is
deprecated). :-)

[1] http://beagleboard.org/bone
[2] http://www.towertech.it/en/products/hardware/tt3201-can-cape/
[3] http://processors.wiki.ti.com/index.php/AM35x_High-End_CAN_Controller_%28HECC%29
[4] http://veter-project.blogspot.com/2011/09/real-time-enough-about-pwms-and-shaky.html
[5] http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/README

--
Dipl.-Ing. (M.Sc.) Marcus Liebhardt
Control Engineer
Yujin Robot
주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023.
Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu,
Seoul, 153-023, Republic of Korea
Website: http://www.yujinrobot.com
Email: marcus.liebhardt@yujinrobot.com
Phone: +82-2-2104-0435

Re: Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Marc Kleine-Budde]

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

On 05/02/2012 09:51 AM, Marcus Liebhardt wrote:
> Hi everybody!
> 
> Looking for a low-cost solution for a real-time Linux system with CAN
> bus support, I am currently considering the Beaglebone [1] (similar to
> the Beagleboard) with the addition of a CAN bus cape [2]. The later
> provides two MCP2515 CAN controller and also allows the use of the
> integrated CAN controller [3] of the Beaglebone's ARM microprocessor
> (Cortex A8) .

Don't use mcp2515, you won't have any fun with it. Consider using a SoC
with an integrated CAN controller, like the freescale i.mx family or one
of the TIs with an integrated (and supported) CAN cores.

> I am thinking about using a Linux kernel plus the RT-patch
> (CONFIG_PREEMPT_RT), since it seems to be less work then setting up
> Xenomai and the MCP2515 is already supported by SocketCAN. However, I
> am not sure, if this set-up will satisfy our real-time constraints,
> since SocketCAN is not real-time safe. Furthermore, I couldn't find
> information about working solutions of patched Linux kernels on the
> Beaglebord besides this paper [4].
> Hence, I am also looking into the option of using Xenomai on the
> Beaglebone for which I found working examples, such as [4]. However,
> according to this list [5] the MCP2515 is not supported by
> RTcan/RT-SocketCAN. Is this still true?

If you have realtime contraints, do with mainline Linux + PREEMPT_RT and
use a proper CAN controller.

> Furthermore, is there support for the integrated CAN controller (AM35x
> HECC) in SocketCAN and/or RT-SocketCAN?

The Kconfig says that the TI HECC is supported.

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: 262 bytes --]

Re: Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Wolfgang Grandegger]

Hi Marcus,

On 05/02/2012 09:51 AM, Marcus Liebhardt wrote:
> Hi everybody!
> 
> Looking for a low-cost solution for a real-time Linux system with CAN
> bus support, I am currently considering the Beaglebone [1] (similar to
> the Beagleboard) with the addition of a CAN bus cape [2]. The later
> provides two MCP2515 CAN controller and also allows the use of the
> integrated CAN controller [3] of the Beaglebone's ARM microprocessor
> (Cortex A8) .
> 
> I am thinking about using a Linux kernel plus the RT-patch
> (CONFIG_PREEMPT_RT), since it seems to be less work then setting up
> Xenomai and the MCP2515 is already supported by SocketCAN. However, I
> am not sure, if this set-up will satisfy our real-time constraints,
> since SocketCAN is not real-time safe. Furthermore, I couldn't find
> information about working solutions of patched Linux kernels on the
> Beaglebord besides this paper [4].
> Hence, I am also looking into the option of using Xenomai on the
> Beaglebone for which I found working examples, such as [4]. However,
> according to this list [5] the MCP2515 is not supported by
> RTcan/RT-SocketCAN. Is this still true?

Setup time is not a strong argument for choosing -rt vs. Xenomai. The
latter usually gives you harder real-time behavior and lower
latencies. On the other hand, Xenomai does not yet support the CAN
controllers you are speaking about. If the Beagleboard is supported by
the mainline 2.6.33 or 3.2 kernel, I think there is a good chance that
the -rt patch applies and works. But I personally don't have any
experience. For real-time and high data rate the MCP2515 is not a really
good choice, as it is connected via SPI bus. What are your requirements
concerning latency and data rate?

> Furthermore, is there support for the integrated CAN controller (AM35x
> HECC) in SocketCAN and/or RT-SocketCAN?

The HECC is supported by the mainline kernel (but not Xenomai).

Wolfgang.

RE: [Socketcan-users] Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Gole, Anant]

Marcus,

>Looking for a low-cost solution for a real-time Linux system with CAN bus support, 
>I am currently considering the Beaglebone [1] (similar to the >Beagleboard) with 
>the addition of a CAN bus cape [2]. The later provides two MCP2515 CAN controller 
>and also allows the use of the integrated CAN >controller [3] of the Beaglebone's 
>ARM microprocessor (Cortex A8) .

>Furthermore, is there support for the integrated CAN controller (AM35x HECC) in 
>SocketCAN and/or RT-SocketCAN?

Note that Beaglebone uses TI's AM335x SOC which has D_CAN peripheral vs the Beagleboard 
Which uses TI's AM37x SOC and it does not have CAN peripheral integrated. AM3517 SOC has 
HECC CAN peripheral which is different than D_CAN found on AM335x. Both HECC and D_CAN drivers 
have been submitted to the linux-can list and HECC is already mainline - D_CAN driver has
been submitted to this list and is undergoing review - it will be merged with the C_CAN driver
shortly.

TI's HECC driver: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/can/ti_hecc.c;h=4accd7ec69543facab276fe3d6d2fd8b902c3604;hb=HEAD

D_CAN driver submission: http://www.spinics.net/lists/linux-omap/msg67538.html

Regards,
Anant

Re: [Socketcan-users] Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Marcus Liebhardt]

Hi there!

First of all, thank you for your valuable feedback! I'll combine my
questions and answers in one email.

> Setup time is not a strong argument for choosing -rt vs. Xenomai.
> [...]
> What are your requirements concerning latency and data rate?

Our real-time requirements are 10 ms cycles, latencies around 1000 us
and we plan to use the 1 Mbit/s data rate. Based on what I read so
far, this should be feasible with SocketCAN and a _well-tuned_
RT-Linux.
And yes, set-up time is not the most important part for this decision,
but since I am a beginner it is not totally unimportant either.

> Don't use mcp2515, you won't have any fun with it. [...]

Why exactly is the MCP2515 not suitable for real-time applications? Is
the SPI interface a bottleneck? (Isn't SPI fast?)

> Note that Beaglebone uses TI's AM335x SOC which has D_CAN peripheral vs the Beagleboard
> Which uses TI's AM37x SOC and it does not have CAN peripheral integrated. AM3517 SOC has
> HECC CAN peripheral which is different than D_CAN found on AM335x. Both HECC and D_CAN drivers
> have been submitted to the linux-can list and HECC is already mainline - D_CAN driver has
> been submitted to this list and is undergoing review - it will be merged with the C_CAN driver
> shortly.

Thanks a lot for this clarification! It made me realise that I got
quite confused by those many SoC variations. Hence, I checked the
documents again and I hope I got it right this time:
Neither the Beagleboard (OMAP3530), nor the Beagleboard-xM (DM3730)
offer a CAN bus controller. But the Beaglebone (AM3359) offers the
DCAN controller and the Craneboard (AM3517) the HECC.
Are both controllers suitable for a real-time application with the
mentioned requirements? Is there a performance difference among both
controllers?
And do you think that the whole system consisting of SocketCAN + Linux
+ PREEMPT_RT patch + proper tuning will fulfil the requirements?

About Linux driver support for the DCAN controller: After skimming
through the Linux driver guide on the TI wiki [1] I got the impression
that the DCAN controller is _already_ supported by the kernel. Is the
TI wiki ahead of time?


Regards,
Marcus

--
Dipl.-Ing. (M.Sc.) Marcus Liebhardt
Control Engineer
Yujin Robot
주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023.
Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu,
Seoul, 153-023, Republic of Korea
Website: http://www.yujinrobot.com
Email: marcus.liebhardt@yujinrobot.com
Phone: +82-2-2104-0435

Re: [Socketcan-users] Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Yegor Yefremov]

Am 03.05.2012 07:21, schrieb Marcus Liebhardt:
> Hi there!
> 
> First of all, thank you for your valuable feedback! I'll combine my
> questions and answers in one email.
> 
>> Setup time is not a strong argument for choosing -rt vs. Xenomai.
>> [...]
>> What are your requirements concerning latency and data rate?
> 
> Our real-time requirements are 10 ms cycles, latencies around 1000 us
> and we plan to use the 1 Mbit/s data rate. Based on what I read so
> far, this should be feasible with SocketCAN and a _well-tuned_
> RT-Linux.
> And yes, set-up time is not the most important part for this decision,
> but since I am a beginner it is not totally unimportant either.
> 
>> Don't use mcp2515, you won't have any fun with it. [...]
> 
> Why exactly is the MCP2515 not suitable for real-time applications? Is
> the SPI interface a bottleneck? (Isn't SPI fast?)
> 
>> Note that Beaglebone uses TI's AM335x SOC which has D_CAN peripheral vs the Beagleboard
>> Which uses TI's AM37x SOC and it does not have CAN peripheral integrated. AM3517 SOC has
>> HECC CAN peripheral which is different than D_CAN found on AM335x. Both HECC and D_CAN drivers
>> have been submitted to the linux-can list and HECC is already mainline - D_CAN driver has
>> been submitted to this list and is undergoing review - it will be merged with the C_CAN driver
>> shortly.
> 
> Thanks a lot for this clarification! It made me realise that I got
> quite confused by those many SoC variations. Hence, I checked the
> documents again and I hope I got it right this time:
> Neither the Beagleboard (OMAP3530), nor the Beagleboard-xM (DM3730)
> offer a CAN bus controller. But the Beaglebone (AM3359) offers the
> DCAN controller and the Craneboard (AM3517) the HECC.
> Are both controllers suitable for a real-time application with the
> mentioned requirements? Is there a performance difference among both
> controllers?
> And do you think that the whole system consisting of SocketCAN + Linux
> + PREEMPT_RT patch + proper tuning will fulfil the requirements?
> 
> About Linux driver support for the DCAN controller: After skimming
> through the Linux driver guide on the TI wiki [1] I got the impression
> that the DCAN controller is _already_ supported by the kernel. Is the
> TI wiki ahead of time?

TI wiki speaks about their own kernel repository with DCAN drivers. But the drivers are still not mainlined, i.e. you'll need to patch this repo [1] with RT-patch and I don't know if it works without problems. BTW you'll probably get problems patching kernels with both am33xx and am3517, because they are still not fully supported by mainline kernel and you'll have to do with TI's repos. Please let us know if you had success.

1. http://arago-project.org/git/projects/linux-am33x.git

Yegor

Re: [Socketcan-users] Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Wolfgang Grandegger]

On 05/03/2012 07:21 AM, Marcus Liebhardt wrote:
> Hi there!
> 
> First of all, thank you for your valuable feedback! I'll combine my
> questions and answers in one email.
> 
>> Setup time is not a strong argument for choosing -rt vs. Xenomai.
>> [...]
>> What are your requirements concerning latency and data rate?
> 
> Our real-time requirements are 10 ms cycles, latencies around 1000 us
> and we plan to use the 1 Mbit/s data rate. Based on what I read so
> far, this should be feasible with SocketCAN and a _well-tuned_
> RT-Linux.

Yes, that's feasible, I believe.

> And yes, set-up time is not the most important part for this decision,
> but since I am a beginner it is not totally unimportant either.
> 
>> Don't use mcp2515, you won't have any fun with it. [...]
> 
> Why exactly is the MCP2515 not suitable for real-time applications? Is
> the SPI interface a bottleneck? (Isn't SPI fast?)

For each register access a SPI transfer needs to be setup and handled
and therefore it's much slower than memory mapped I/O. People report
data-losses at high data rates, especially 1MBit/s. Maybe the -rt helps
to avoid them. Also the existing SPI interface is not optimal,
especially for -rt.

>> Note that Beaglebone uses TI's AM335x SOC which has D_CAN peripheral vs the Beagleboard
>> Which uses TI's AM37x SOC and it does not have CAN peripheral integrated. AM3517 SOC has
>> HECC CAN peripheral which is different than D_CAN found on AM335x. Both HECC and D_CAN drivers
>> have been submitted to the linux-can list and HECC is already mainline - D_CAN driver has
>> been submitted to this list and is undergoing review - it will be merged with the C_CAN driver
>> shortly.
> 
> Thanks a lot for this clarification! It made me realise that I got
> quite confused by those many SoC variations. Hence, I checked the
> documents again and I hope I got it right this time:
> Neither the Beagleboard (OMAP3530), nor the Beagleboard-xM (DM3730)
> offer a CAN bus controller. But the Beaglebone (AM3359) offers the
> DCAN controller and the Craneboard (AM3517) the HECC.
> Are both controllers suitable for a real-time application with the
> mentioned requirements? Is there a performance difference among both
> controllers?
> And do you think that the whole system consisting of SocketCAN + Linux
> + PREEMPT_RT patch + proper tuning will fulfil the requirements?

I'm quite optimistic, despite the sub-optimal SPI interface.

> About Linux driver support for the DCAN controller: After skimming
> through the Linux driver guide on the TI wiki [1] I got the impression
> that the DCAN controller is _already_ supported by the kernel. Is the
> TI wiki ahead of time?

The first challenge is to find and put together a good combo kernel
version with -rt supporting that board.

Wolfgang.

Re: [Socketcan-users] Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Wolfgang Grandegger]

On 05/03/2012 09:13 AM, Wolfgang Grandegger wrote:
> On 05/03/2012 07:21 AM, Marcus Liebhardt wrote:
>> Hi there!
>>
>> First of all, thank you for your valuable feedback! I'll combine my
>> questions and answers in one email.
>>
>>> Setup time is not a strong argument for choosing -rt vs. Xenomai.
>>> [...]
>>> What are your requirements concerning latency and data rate?
>>
>> Our real-time requirements are 10 ms cycles, latencies around 1000 us
>> and we plan to use the 1 Mbit/s data rate. Based on what I read so
>> far, this should be feasible with SocketCAN and a _well-tuned_
>> RT-Linux.
> 
> Yes, that's feasible, I believe.
> 
>> And yes, set-up time is not the most important part for this decision,
>> but since I am a beginner it is not totally unimportant either.
>>
>>> Don't use mcp2515, you won't have any fun with it. [...]
>>
>> Why exactly is the MCP2515 not suitable for real-time applications? Is
>> the SPI interface a bottleneck? (Isn't SPI fast?)
> 
> For each register access a SPI transfer needs to be setup and handled
> and therefore it's much slower than memory mapped I/O. People report
> data-losses at high data rates, especially 1MBit/s. Maybe the -rt helps
> to avoid them. Also the existing SPI interface is not optimal,
> especially for -rt.
> 
>>> Note that Beaglebone uses TI's AM335x SOC which has D_CAN peripheral vs the Beagleboard
>>> Which uses TI's AM37x SOC and it does not have CAN peripheral integrated. AM3517 SOC has
>>> HECC CAN peripheral which is different than D_CAN found on AM335x. Both HECC and D_CAN drivers
>>> have been submitted to the linux-can list and HECC is already mainline - D_CAN driver has
>>> been submitted to this list and is undergoing review - it will be merged with the C_CAN driver
>>> shortly.
>>
>> Thanks a lot for this clarification! It made me realise that I got
>> quite confused by those many SoC variations. Hence, I checked the
>> documents again and I hope I got it right this time:
>> Neither the Beagleboard (OMAP3530), nor the Beagleboard-xM (DM3730)
>> offer a CAN bus controller. But the Beaglebone (AM3359) offers the
>> DCAN controller and the Craneboard (AM3517) the HECC.
>> Are both controllers suitable for a real-time application with the
>> mentioned requirements? Is there a performance difference among both
>> controllers?
>> And do you think that the whole system consisting of SocketCAN + Linux
>> + PREEMPT_RT patch + proper tuning will fulfil the requirements?
> 
> I'm quite optimistic, despite the sub-optimal SPI interface.

To be clear, I'm optimistic for the SOC CAN controllers but not for the
mcp2515.

Wolfgang.

Re: [Socketcan-users] Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Marcus Liebhardt]

2012/5/3 Wolfgang Grandegger <wg@grandegger.com>:
> On 05/03/2012 09:13 AM, Wolfgang Grandegger wrote:
>> On 05/03/2012 07:21 AM, Marcus Liebhardt wrote:
>>> Hi there!
>>>
>>> First of all, thank you for your valuable feedback! I'll combine my
>>> questions and answers in one email.
>>>
>>>> Setup time is not a strong argument for choosing -rt vs. Xenomai.
>>>> [...]
>>>> What are your requirements concerning latency and data rate?
>>>
>>> Our real-time requirements are 10 ms cycles, latencies around 1000 us
>>> and we plan to use the 1 Mbit/s data rate. Based on what I read so
>>> far, this should be feasible with SocketCAN and a _well-tuned_
>>> RT-Linux.
>>
>> Yes, that's feasible, I believe.
>>
>>> And yes, set-up time is not the most important part for this decision,
>>> but since I am a beginner it is not totally unimportant either.
>>>
>>>> Don't use mcp2515, you won't have any fun with it. [...]
>>>
>>> Why exactly is the MCP2515 not suitable for real-time applications? Is
>>> the SPI interface a bottleneck? (Isn't SPI fast?)
>>
>> For each register access a SPI transfer needs to be setup and handled
>> and therefore it's much slower than memory mapped I/O. People report
>> data-losses at high data rates, especially 1MBit/s. Maybe the -rt helps
>> to avoid them. Also the existing SPI interface is not optimal,
>> especially for -rt.
>>
>>>> Note that Beaglebone uses TI's AM335x SOC which has D_CAN peripheral vs the Beagleboard
>>>> Which uses TI's AM37x SOC and it does not have CAN peripheral integrated. AM3517 SOC has
>>>> HECC CAN peripheral which is different than D_CAN found on AM335x. Both HECC and D_CAN drivers
>>>> have been submitted to the linux-can list and HECC is already mainline - D_CAN driver has
>>>> been submitted to this list and is undergoing review - it will be merged with the C_CAN driver
>>>> shortly.
>>>
>>> Thanks a lot for this clarification! It made me realise that I got
>>> quite confused by those many SoC variations. Hence, I checked the
>>> documents again and I hope I got it right this time:
>>> Neither the Beagleboard (OMAP3530), nor the Beagleboard-xM (DM3730)
>>> offer a CAN bus controller. But the Beaglebone (AM3359) offers the
>>> DCAN controller and the Craneboard (AM3517) the HECC.
>>> Are both controllers suitable for a real-time application with the
>>> mentioned requirements? Is there a performance difference among both
>>> controllers?
>>> And do you think that the whole system consisting of SocketCAN + Linux
>>> + PREEMPT_RT patch + proper tuning will fulfil the requirements?
>>
>> I'm quite optimistic, despite the sub-optimal SPI interface.
>
> To be clear, I'm optimistic for the SOC CAN controllers but not for the
> mcp2515.

I was already suspecting that. :-)

However, I'm confused by "[...] despite the sub-optimal SPI
interface.". Do you mean, that the SOC CAN controllers (e.g. DCAN,
HECC) are also using the SPI interface? If so, are they not suffering
the same problems as external CAN controllers (e.g. the MCP2515) using
this bus?


Marcus

>
> Wolfgang.
>
>



-- 
Dipl.-Ing. (M.Sc.) Marcus Liebhardt
Control Engineer
Yujin Robot
주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023.
Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu,
Seoul, 153-023, Republic of Korea
Website: http://www.yujinrobot.com
Email: marcus.liebhardt@yujinrobot.com
Phone: +82-2-2104-0435

Re: [Socketcan-users] Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN

[Wolfgang Grandegger]

On 05/04/2012 04:27 AM, Marcus Liebhardt wrote:
> 2012/5/3 Wolfgang Grandegger <wg@grandegger.com>:
>> On 05/03/2012 09:13 AM, Wolfgang Grandegger wrote:
>>> On 05/03/2012 07:21 AM, Marcus Liebhardt wrote:
>>>> Hi there!
>>>>
>>>> First of all, thank you for your valuable feedback! I'll combine my
>>>> questions and answers in one email.
>>>>
>>>>> Setup time is not a strong argument for choosing -rt vs. Xenomai.
>>>>> [...]
>>>>> What are your requirements concerning latency and data rate?
>>>>
>>>> Our real-time requirements are 10 ms cycles, latencies around 1000 us
>>>> and we plan to use the 1 Mbit/s data rate. Based on what I read so
>>>> far, this should be feasible with SocketCAN and a _well-tuned_
>>>> RT-Linux.
>>>
>>> Yes, that's feasible, I believe.
>>>
>>>> And yes, set-up time is not the most important part for this decision,
>>>> but since I am a beginner it is not totally unimportant either.
>>>>
>>>>> Don't use mcp2515, you won't have any fun with it. [...]
>>>>
>>>> Why exactly is the MCP2515 not suitable for real-time applications? Is
>>>> the SPI interface a bottleneck? (Isn't SPI fast?)
>>>
>>> For each register access a SPI transfer needs to be setup and handled
>>> and therefore it's much slower than memory mapped I/O. People report
>>> data-losses at high data rates, especially 1MBit/s. Maybe the -rt helps
>>> to avoid them. Also the existing SPI interface is not optimal,
>>> especially for -rt.
>>>
>>>>> Note that Beaglebone uses TI's AM335x SOC which has D_CAN peripheral vs the Beagleboard
>>>>> Which uses TI's AM37x SOC and it does not have CAN peripheral integrated. AM3517 SOC has
>>>>> HECC CAN peripheral which is different than D_CAN found on AM335x. Both HECC and D_CAN drivers
>>>>> have been submitted to the linux-can list and HECC is already mainline - D_CAN driver has
>>>>> been submitted to this list and is undergoing review - it will be merged with the C_CAN driver
>>>>> shortly.
>>>>
>>>> Thanks a lot for this clarification! It made me realise that I got
>>>> quite confused by those many SoC variations. Hence, I checked the
>>>> documents again and I hope I got it right this time:
>>>> Neither the Beagleboard (OMAP3530), nor the Beagleboard-xM (DM3730)
>>>> offer a CAN bus controller. But the Beaglebone (AM3359) offers the
>>>> DCAN controller and the Craneboard (AM3517) the HECC.
>>>> Are both controllers suitable for a real-time application with the
>>>> mentioned requirements? Is there a performance difference among both
>>>> controllers?
>>>> And do you think that the whole system consisting of SocketCAN + Linux
>>>> + PREEMPT_RT patch + proper tuning will fulfil the requirements?
>>>
>>> I'm quite optimistic, despite the sub-optimal SPI interface.
>>
>> To be clear, I'm optimistic for the SOC CAN controllers but not for the
>> mcp2515.
> 
> I was already suspecting that. :-)
> 
> However, I'm confused by "[...] despite the sub-optimal SPI
> interface.". Do you mean, that the SOC CAN controllers (e.g. DCAN,
> HECC) are also using the SPI interface? If so, are they not suffering
> the same problems as external CAN controllers (e.g. the MCP2515) using
> this bus?

The SOC CAN controllers do *not* use the SPI interface? They are usually
memory mapped (SOC register address space). My answer was
misleading/wrong and that's why I tried to clarify.

Wolfgang.