From: David Jander <david.jander@protonic.nl>
To: Alessandro Rubini <rubini@gnudd.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Which CAN driver to port to for PPC
Date: Wed, 28 Dec 2005 10:00:11 +0100 [thread overview]
Message-ID: <200512281000.12073.david.jander@protonic.nl> (raw)
In-Reply-To: <20051227214949.GA8236@mail.gnudd.com>
Hi all,
On Tuesday 27 December 2005 22:49, Alessandro Rubini wrote:
> I need to port ocan to support SJA1000 on an ARM device, as a client
> asked for it. Also, another client asked for a 2.6 port, so all of
> this will happen pretty soon (2-3 weeks). I don't know if that makes
> any difference.
That could of course make a difference.... eventually.
The problem I see with Ocan is that it has a very different API than all the
others. I know of at least two others, which try to be compatible (or at
least easily portable between) with each other: lincan and can4linux. I am
not sure but I think they started from the same base, and somehow agreed to
stay API-compatible.
Ocan's API on the other hand, seems to be tailored around the intel
controller, and doing little more than offering a user-space interface to the
chip, much in the same way as one is used to programming small
microcontrollers with integrated CAN periferals. I wonder how the port to
SJA1000 will turn out, since I believe it would have to emulate some
82527-specific stuff, in order to offer a compatible API.
The advantage OCan might have, is probably better control of timing, since
AFAIK, one can avoid using queues, which give additional delays if the queue
is not empty; somehting often not wanted in real-time applications.
Also one difficulty in designing a good CAN driver model, is the fact that CAN
offers up to the link-layer in hardware, and the rest is application
specific, so it is hard to do much in the driver without hampering some
possible application. I am convinced though, that there should be a
chip/card-independent API to the application-programmer, and that effort
should be done to converge into the same direction. Programmers now really
have a tough time choosing, and that is as bad as having no choice at all
IMHO.
So, wouldn't it be better to try to unite forces and at least offer similar
API's, or even better, develop a standard linux CAN framework? I guess there
is little chance something like this will ever become part of the kernel, but
right now the situation is really awful. CAN is quite popular for embedded
systems, but even embedded systems developers like to write portable code.
Regards,
P.S.: Alessandro: I have copy of "LDD1" on my desk, and I like it a lot.
Thanks!
--
David Jander
Protonic Holland.
next prev parent reply other threads:[~2005-12-28 9:00 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 [this message]
2005-12-28 15:02 ` Andrey Volkov
2005-12-29 13:43 ` Robert Schwebel
2005-12-29 15:12 ` [Socket-can] " Jan Kiszka
2005-12-28 15:07 ` Alessandro Rubini
2005-12-29 12:17 ` Wolfgang Grandegger
2005-12-29 16:28 ` David Jander
2005-12-28 13:19 ` Alessandro Rubini
2005-12-28 15:05 ` David Jander
2005-12-28 10:44 ` Wolfgang Grandegger
2005-12-28 12:02 ` David Jander
2005-12-29 11:53 ` Wolfgang Grandegger
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=200512281000.12073.david.jander@protonic.nl \
--to=david.jander@protonic.nl \
--cc=linuxppc-embedded@ozlabs.org \
--cc=rubini@gnudd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).