Which CAN driver to port to for PPC

Which CAN driver to port to for PPC

[David Jander]

Hi,

We have developed CAN hardware based on the Philips SJA1000 controller hooked 
to a MPC8xx based processor board. Now we want to write driver support for 
it. My first try was lincan-0.3.1, which seemed quite well written at first 
glance. Porting was easy too, and the driver works fine on our board with the 
latest kernel (2.6.14).
But.... this driver lacks a proper way of checking the status of the CAN 
controller from userspace :-( Not that nice after all!

Then I see on the DENX website, mention of Rubini's OCAN (mostly useless to 
us), and Peak's PCAN drivers (there is a port for MPC5200 on DENX's site). No 
word about lincan, though.

The reason I suppose is, someone already figured out that lincan is not a good 
choice for whatever reason (status reportability ??), right?

Before beginning to re-invent wheels and re-discover known problems in certain 
CAN driver architectures, could someone please point me to the right place to 
start looking for answers (if that place exists) or just give the answer, 
opinion or experience with one of PeakCAN, lincan, can4linux, etc...?

I am again puzzeled about which way to go.

Thanks for any advice,

-- 
David Jander
Protonic Holland.

Re: Which CAN driver to port to for PPC

[Alessandro Rubini]

Hello.

> [...]
> Then I see on the DENX website, mention of Rubini's OCAN (mostly
> useless to us),

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.

/alessandro

Re: Which CAN driver to port to for PPC

[David Jander]

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.

Re: Which CAN driver to port to for PPC

[Andrey Volkov]

David Jander wrote:
> 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.

Robert Schwebel et al have worked socket based CAN (i.e. implement CAN
as _net_ dev, not as char), as consequence you will not have problem
with major/minor numbers, duplicated code in drivers for different
chips, could share CAN dev between diff processes _without_ misc. third
party shared libraies, stacked CAN protocols (CANopen/NMEA2000 could be
abstract kernel module)... But currently it is not open for everyone
(due to beta status, AFAIK)

Alessandro, please check Pengutronix work first, may be it will be
helpfull to you to,
Also I permit oneself to quotate _you_ ;) from LDDv3 pp6-7:

"The three classes are:

Character devices

A character (char) device is one that can be accessed as a stream of
bytes (like a file); a char driver is in charge of implementing this
behavior. Such a driver usually implements at least the open, close,
read, and write system calls. The text console (/dev/console) and the
serial ports (/dev/ttyS0 and friends) are examples of char devices, as
they are well represented by the stream abstraction. Char devices are
accessed by means of filesystem nodes, such as /dev/tty1 and /dev/lp0.
The only relevant difference between a char device and a regular file is
that you can always move back and forth in the regular file, whereas
most char devices are just data channels, which you can only access
sequentially. There exist, nonetheless, char devices that look like data
areas, and you can move back and forth in them; for instance, this
usually applies to frame grabbers, where the applications can access the
whole acquired image using mmap or lseek.

Block devices

Like char devices, block devices are accessed by filesystem nodes in the
/dev directory. A block device is a device (e.g., a disk) that can host
a filesystem. In most Unix systems, a block device can only handle I/O
operations that transfer one or more whole blocks, which are usually 512
bytes (or a larger power of two) bytes in length. Linux, instead, allows
the application to read and write a block device like a char device—it
permits the transfer of any number of bytes at a time. As a result,
block and char devices differ only in the way data is managed internally
by the kernel, and thus in the kernel/driver software interface. Like a
char device, each block device is accessed through a filesystem node,
and the difference between them is transparent to the user. Block
drivers have a completely different interface to the kernel than char
drivers.

Network interfaces

Any network transaction is made through an interface, that is, a device
that is able to exchange data with other hosts. Usually, an interface is
a hardware device, but it might also be a pure software device, like the
loopback interface. A network interface is in charge of sending and
receiving data packets, driven by the network subsystem of the kernel,
without knowing how individual transactions map to the actual packets
being transmitted. Many network connections (especially those using TCP)
are stream-oriented, but network devices are, usually, designed around
the transmission and receipt of packets. A network driver knows nothing
about individual connections; it only handles packets."

so CAN _is_ Network interface, but not char device
(how it often implemented).

P.S. Robert, when I check last time, it was mature enogh, so may be time
to open mail-list and svn?

--
Regards
Andrey Volkov

Re: Which CAN driver to port to for PPC

[Robert Schwebel]

Hi, 

On Wed, Dec 28, 2005 at 06:02:26PM +0300, Andrey Volkov wrote:
> Robert Schwebel et al have worked socket based CAN (i.e. implement CAN
> as _net_ dev, not as char), as consequence you will not have problem
> with major/minor numbers, duplicated code in drivers for different
> chips, could share CAN dev between diff processes _without_ misc.
> third party shared libraies, stacked CAN protocols (CANopen/NMEA2000
> could be abstract kernel module)... But currently it is not open for
> everyone (due to beta status, AFAIK)
> 
> Alessandro, please check Pengutronix work first, may be it will be
> helpfull to you to
>
> [...]
>
> P.S. Robert, when I check last time, it was mature enogh, so may be time
> to open mail-list and svn?

The socket-can stuff is mature enouth to have been used in some projects
at Pengutronix.

In december, we have made a synchronisation meeting with the VW people
who made the initial port for 2.4; they are more focussed on having
higher level transport protocols ontop of the "raw" socket interface we
currently use. During that process we have reviewed the user interface
with regard to their use cases, so it will have to be changed a little
bit before we have something which is in a state to be posted on lkml.

Unfortunately we have no commercial project behind the infrastructure
work, so it's priority is lower than it should be to really drive things
forward (paying customers have a higher priority than community work). 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: [Socket-can] Re: Which CAN driver to port to for PPC

[Jan Kiszka]

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

Robert Schwebel wrote:
> ...
> In december, we have made a synchronisation meeting with the VW people
> who made the initial port for 2.4; they are more focussed on having
> higher level transport protocols ontop of the "raw" socket interface we
> currently use. During that process we have reviewed the user interface
> with regard to their use cases, so it will have to be changed a little
> bit before we have something which is in a state to be posted on lkml.
> 

Beyond the outstanding comparably minor API adjustments, we furthermore
discussed first ideas how to define the lowest interface, i.e. the CAN
network device layer. That should be done in a way which makes porting
CAN low-level drivers between the standard kernel and a real-time Linux
CAN stack trivial. That's a unique chance (compared to the situation of
RTnet e.g.), so we should take it.

This real-time stack is to be derived from the RT-SJA1000 driver
Wolfgang pointed at. It is already based on an abstraction layer (RTDM)
that makes it portable across many of the various RT-Linux variant. So
far this includes support for Xenomai and RTAI, RTLinux/GPL is planning
to adopt RTDM as well. This means we could end up with portable CAN
applications and drivers, RT and non-RT!

As Robert said, it "just" requires some resources for implementing
this... ;)

Jan

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

Re: Which CAN driver to port to for PPC

[Alessandro Rubini]

> Robert Schwebel et al have worked socket based CAN (i.e. implement CAN
> as _net_ dev, not as char)

That's great. I've always been convinced it is the right way to go.
I remember I've said so to a friend in March 2002.  Unfortunately,
I had no time to do it the right way, due to short deadlines and
tight budget.  I'm happy Robert did it.

/alessandro

Re: Which CAN driver to port to for PPC

[Wolfgang Grandegger]

Alessandro Rubini wrote:
>>Robert Schwebel et al have worked socket based CAN (i.e. implement CAN
>>as _net_ dev, not as char)
> 
> 
> That's great. I've always been convinced it is the right way to go.
> I remember I've said so to a friend in March 2002.  Unfortunately,
> I had no time to do it the right way, due to short deadlines and
> tight budget.  I'm happy Robert did it.

FYI, there is also a RTDM/Xenomai based version of the SJA1000 
socket-based CAN driver at 
http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddon/
As RTDM/Xenomai is avaiable for PowerPC as well, it might be an option.

Wolfgang.

> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

Re: Which CAN driver to port to for PPC

[David Jander]

On Thursday 29 December 2005 13:17, Wolfgang Grandegger wrote:
> > That's great. I've always been convinced it is the right way to go.
> > I remember I've said so to a friend in March 2002.  Unfortunately,
> > I had no time to do it the right way, due to short deadlines and
> > tight budget.  I'm happy Robert did it.
>
> FYI, there is also a RTDM/Xenomai based version of the SJA1000
> socket-based CAN driver at
> http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddon/
> As RTDM/Xenomai is avaiable for PowerPC as well, it might be an option.

This is great!
I have been trying out xenomai with 2.6.14 on our MPC8xx hardware, and it 
looks impressive. Still wonder why xenomai hasn't gotten the publicity it 
deserves.
Somehow I had overlooked the example RTDM CAN driver, though.

I also see Robert Schwebel as a member of OSADL, so I am eagerly waiting for a 
news-update on that site also (www.osadl.org).

This could indeed get very interesting, I can't wait to see how Roberts 
implementation looks like.

Thanks to all for the discussion and work on this matter,

-- 
David Jander
Protonic Holland.

Re: Which CAN driver to port to for PPC

[Alessandro Rubini]

Hello.

> The problem I see with Ocan is that it has a very different API than all the 
> others.

I know. When I started the project there only was one driver, and
it was already very complex. But it lacked the select method(now
poll), and had other serious design problems. So I started mine,
without advertising it.

Now I have a few happy users, and they want to keep my API in their
applications, so I'm stuck with it.

> 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.

True, but the chip isn't _that_ different, actually.

> 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.

Yes, that is how things should be, in an ideal world.

> 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?

It would. Anyone willing to lead this effort? [no offence or humor
intended, I am interested in following it, but can't lead it myself]

Thanks for your comments
/alessandro

Re: Which CAN driver to port to for PPC

[David Jander]

Hi again,

On Wednesday 28 December 2005 14:19, Alessandro Rubini wrote:
> > The problem I see with Ocan is that it has a very different API than all
> > the others.
>
> I know. When I started the project there only was one driver, and
> it was already very complex. But it lacked the select method(now
> poll), and had other serious design problems. So I started mine,
> without advertising it.

Most of the time, that is the reason. There is something, but it's broken, and 
to fix it is much more work that re-doing it. Problem is: some people are 
already using it, and code is beeing grown on top of it. It seems a standard 
open-source dilemma.

> Now I have a few happy users, and they want to keep my API in their
> applications, so I'm stuck with it.

Tough indeed. But according to Newton's laws, if we apply some force to it, 
pointing in the right direction, eventually it'll move there, no matter how 
big the object is. Let's try and find out where that direction is ;-)

> Yes, that is how things should be, in an ideal world.

Sorry for trying to be a bit of an idealist ;-)

> It would. Anyone willing to lead this effort? [no offence or humor
> intended, I am interested in following it, but can't lead it myself]

I have too little time and too little experience to do such a thing, but I'd 
happily contribute and follow.

Regards,

-- 
David Jander
Protonic Holland.

Re: Which CAN driver to port to for PPC

[Wolfgang Grandegger]

David Jander wrote:
> Hi,
> 
> We have developed CAN hardware based on the Philips SJA1000 controller hooked 
> to a MPC8xx based processor board. Now we want to write driver support for 
> it. My first try was lincan-0.3.1, which seemed quite well written at first 
> glance. Porting was easy too, and the driver works fine on our board with the 
> latest kernel (2.6.14).
> But.... this driver lacks a proper way of checking the status of the CAN 
> controller from userspace :-( Not that nice after all!
> 
> Then I see on the DENX website, mention of Rubini's OCAN (mostly useless to 
> us), and Peak's PCAN drivers (there is a port for MPC5200 on DENX's site). No 
> word about lincan, though.

We have looked for "free" CAN software/drivers for Linux already some 
time ago, especially for embedded PowerPC processors. There are various 
implementations out there, but only a few of them are "alive". A natural 
choice for the SJA1000 seems to be the CAN driver from Peak Systems (see
http://www.peak-system.com/linux/index.htm). It already supports 2.6 and 
seems to be well maintained. Porting it to your MPC 8xx bases hardware 
should not be to much effort. The OCAN driver is for the i82527. It's a 
good choice if you use that CAN controller but porting to the SJA1000 
might not be straight-forward as the API uses details of the chips hardware.

> 
> The reason I suppose is, someone already figured out that lincan is not a good 
> choice for whatever reason (status reportability ??), right?

I never tried lincan.

> Before beginning to re-invent wheels and re-discover known problems in certain 
> CAN driver architectures, could someone please point me to the right place to 
> start looking for answers (if that place exists) or just give the answer, 
> opinion or experience with one of PeakCAN, lincan, can4linux, etc...?
> 
> I am again puzzeled about which way to go.

AFAIK, there is no _generic_ embedded CAN driver available which even 
supports real-time extensions.

Wolfgang.

> Thanks for any advice,
> 

Re: Which CAN driver to port to for PPC

[David Jander]

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.

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.

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.

Greetings, and thanks for the comments,

Btw, how's ELDK-4 coming along?

-- 
David Jander
Protonic Holland.

Re: Which CAN driver to port to for PPC

[Wolfgang Grandegger]

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.