lkml.org 
[lkml]   [2005]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: LinCAN 0.3-rc1 for ARM
Date
On Thursday 02 June 2005 14:04, you wrote:
> Hi Pavel,
>
> How about to add your LinCAN into kernel tree (mainstream could be very
> difficult) f.e. in
> driver/char/can directory?
>
> It'd be necessary only to patch Kconfig and Makefile and standalone
> version, I think , what do you?
> It can allow to compile LinCAN inside kernel not as module.

Hello Jose and all others,

I am sending this reply even to LKML, because Linux CAN
specific lists are fragmented and sometimes dead same way as many
Linux CAN related projects. If somebody is convinced, that he knows
the right Linux CAN bus related central place, redirect me to it, please.

The LinCAN integration would be interresting and great, but it would
require big-big-big amount of work and common consensus

- there is too many Linux CAN related drivers and works.
Many of them are dead branches of two or three initial projects
which has disappeared over time. There is more fully functional
single chip or single vendor specific CAN drivers now.

- I have tried to lay fast infrastructure for CAN messages
handling through generalized FIFOs concept, but there
could be objections to my concept

- the boards support has been based on Arnaud's Westenberg CAN project
so knowledge accumulated about different cards in this project
and even original Claus Schroeter LDDK projects (both dead and sites
not updated for many years) has been preserved in the LinCAN driver

- LinCAN is one of very little Linux CAN drivers, which are prepared
to support many different hardware kinds even in one build,
it means some code and time overhead. It supports SJA1000
i82527 chips and some intelligent cards. It is used on even
on ARM and PowerPC base industrial boards with more different
cards.

- it has been adapted by some companies for their cards as well.
But not all of them provided feedback and are best Linux
community citizens. This is shame for them, because they would
have problems to keep their changes usebale with evolving
LinCAN core sources and it hurts us, because we lose
bigger picture of our code usage and adaptations helping different
hardware and applications. I hate idea of diverging and hidden branches.

- on the other hand LinCAN has advantage, that it is not bound
by any commercial subject a has been accepted by more companies

- LinCAN is used at some universities and it is adapted for their
projects special needs

- LinCAN supports 2.2.x, 2.4.x and 2.6.x kernels. At least 2.4.x
and 2.6.x is required for now. This is fundamental problem for inclusion
into 2.6.x kernel, because we can not switch to 2.6.x driver model
if 2.4.x has to be supported. I fully understand that it would be required
by 2.6.x kernel maintainers, but we (at CTU) have not enough financial
and personal resources to maintain two branches diverging in the time

- LinCAN supports RT-Linux, but RTAI is missing, again, it is not too
difficult problem, we have some experience with RTAI, but our power
is limited. Even nobody from RTAI core community offered significant
interrest or help in this case.

- there is very long list of ideas and features which should be implemented
or at least evaluated.
Traffic statistics, possibility to use more communication objects
as hardware FIFO in some chips. Fast distinct ID per chip filterring etc.

This all means, that there is probably zero chance for inclusion in
the mid range future. Our original goal of CTU part in the OCERA project
has been to work on CANopen and ETERNET RTPS protocols. The work
on the driver has been result of our frustration how many incompatible
and insufficient half life Linux CAN drivers exists. We have tried to start
from widely accepted base to not start new totally incompatible branch.
Others has to evaluate value of our work.

The conclusion is:
we would like to hear and collect others opinion. We would be happy for
provided help and new boards/hardware support contributions.
If there is consensus that LinCAN is useful for more users and accepted
by more developers, we would try to find funding for university project
to boost development. I think, that right time for re-evaluation
of LinCAN inclusion into Linux kernel would be when 2.4.x Linux kernel
is superseded by 2.6.x in near absolute majority of Linux embedded project.
I do not expect that such time comes before and of this year.
I have fear that even at that time CAN users base would be considered
as minority and inclusion of the CAN driver into mainline would be
considered as kernel bloating by most of others.

About CAN bus and LinCAN

The CAN bus is used in many industrial and automotive applications.
It can be found in each modern vehicle, many robots, servo-drivers etc.
Many embedded microcontrollers have on the chip integrated CAN controller.
http://www.can-cia.org/

FreshMeat LinCAN entry
http://freshmeat.net/projects/lincan

OCERA (http://www.ocera.org/) - Communication components
http://www.ocera.org/download/components/WP7/index.html

Some short quick start info on my page
http://cmp.felk.cvut.cz/~pisa/#can

Latest PDF doc with internals, history, other CAN drivers evaluation
http://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.2.pdf

One of our department projects utilizing LinCAN and Presentation
http://dce.felk.cvut.cz/retobot/
http://www.linuxexpo.cz/prezentace2005/OCERA_LinuxExpo_2005.pdf

Best wishes

Pavel Pisa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-06-02 18:02    [W:0.036 / U:1.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site