From: Wolfgang Grandegger <wg@grandegger•com>
To: David Jander <david.jander@protonic•nl>
Cc: linuxppc-embedded@ozlabs•org
Subject: Re: Which CAN driver to port to for PPC
Date: Thu, 29 Dec 2005 12:53:32 +0100 [thread overview]
Message-ID: <43B3CE3C.3050601@grandegger.com> (raw)
In-Reply-To: <200512281302.46210.david.jander@protonic.nl>
David Jander wrote:
> Hi again,
>
> On Wednesday 28 December 2005 11:44, Wolfgang Grandegger wrote:
>
>>AFAIK, there is no _generic_ embedded CAN driver available which even
>>supports real-time extensions.
>
>
> Yes, lincan does. Well, it supports RTlinux and OCERA's RTlinux (GPL)
> modifications, which somehow reinvent ADEOS (or is it the other way around?),
> but since RTlinux is an option only for i386, and anyway almost dead right
> now, you could say it doesn't support real-time extensions.
Well, ADEOS uses a different method of handling interrupts and
exceptions to avoid the infamous RTLinux patent. Better let's say: it
doesn't support really "free" real-time extensions.
> The problem of saying "Peak-CAN for SJA1000" and "OCAN for intel" is that you
> can basically forget about writing portable code because they are both very
> different.
I agree.
> Maybe you should have a look at Pavel Pisa's lincan. After trying it out you
> might end up as confused as I am, because it doesn't look that bad at all,
> it's almost platform independent, supports all kernels (2.2 to latest 2.6),
> and supports a great amount of cards with intel and/or philips chips (yes,
> both of them on one card is also an option). The driver is designed with
> performance and throughput in mind, but I am not so sure about the API which
> is still a little too simple (maybe that's actually good) and doesn't support
> properly checking chip- or bus-status yet. Also honorable is their effort of
> staying compatible with at least one other player: can4linux.
In the meantime I had a closer look and it looks like the most advanced
in terms of portability, indeed. My experience is, that the chip- or
bus-status, apart from the bus-off state, is very hardware specific and
it's difficult to provide a generic API. Still need to dig more in
lincan to make a reasonable judgment, though.
> Greetings, and thanks for the comments,
>
> Btw, how's ELDK-4 coming along?
Please ask Wolfgang Denk directly.
Wolfgang.
prev parent reply other threads:[~2005-12-29 11:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-27 16:30 Which CAN driver to port to for PPC David Jander
2005-12-27 21:49 ` Alessandro Rubini
2005-12-28 9:00 ` David Jander
2005-12-28 13:19 ` Alessandro Rubini
2005-12-28 15:05 ` David Jander
2005-12-28 15:02 ` Andrey Volkov
2005-12-28 15:07 ` Alessandro Rubini
2005-12-29 12:17 ` Wolfgang Grandegger
2005-12-29 16:28 ` David Jander
2005-12-29 13:43 ` Robert Schwebel
2005-12-29 15:12 ` [Socket-can] " Jan Kiszka
2005-12-28 10:44 ` Wolfgang Grandegger
2005-12-28 12:02 ` David Jander
2005-12-29 11:53 ` Wolfgang Grandegger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43B3CE3C.3050601@grandegger.com \
--to=wg@grandegger$(echo .)com \
--cc=david.jander@protonic$(echo .)nl \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox