From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Subject: Re: [Socketcan-users] Support of MCP2515 and AM35x High-End CAN controller in (RT-)SocketCAN Date: Thu, 03 May 2012 09:13:00 +0200 Message-ID: <4FA22FFC.8050905@grandegger.com> References: <3F602CD5BF1C69469B2F060E90850642C7E6DC@DQHE01.ent.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from ngcobalt02.manitu.net ([217.11.48.102]:57301 "EHLO ngcobalt02.manitu.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752459Ab2ECHNG (ORCPT ); Thu, 3 May 2012 03:13:06 -0400 In-Reply-To: Sender: linux-can-owner@vger.kernel.org List-ID: To: Marcus Liebhardt Cc: Linux-CAN 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.