GSoC 2013 - CAN deivers/framework

[jinyang.sia]

Thanks,
It's really give me a lot of help.

According to your advice, I do some research on can4linux, SocketCAN and LinCAN. I think LinCAN may be a better choice, just same with your advice. So I think, simulation environment should be built first, maybe on QEMU, and then port LinCAN to RTEMS.

However, I have little konwledge how to add hardware simulation to QEMU. Hope to get more guidance from you on this point.

Thanks, best wishes



jinyang.sia

From: Pavel Pisa
Date: 2013-04-19 22:45
To: rtems-devel; jinyang.sia
CC: Rempel, Cynthia
Subject: Re: GSoC 2013 - CAN deivers/framework
Hello all,

if we speak about CAN for Linux than there is already
establishes standard and that is SocketCAN.
It support the most of the board.

The code for the CAN packet family, device support and drivers
is mainlined. Some for IP tool to setup basic parameters.
The SocketCAN development repositories are at

  http://gitorious.org/linux-can

The mailing list is at

  http://vger.kernel.org/vger-lists.html#linux-can

On Friday 19 April 2013 10:55:45 jinyang.sia wrote:
> Can4linux is widely used on Linux, but is there a copyright problem? for
> can4linux and RTEMS?

Can4linux is probably not of much interrest today.
As for licensing, I see that as very problematic to use
any Linux code.

I am not 100% sure about Can4linux but all SocketCAN
code is licensed under GPLv2 which disqualifies it for inclusion
in the RTEMS mainline (GPL + linking exception). May it be
we could try to ask for license extension main contributors
but I expect that it would be very problematic.


> And i also have some question on qemu-system-arm, does it support CAN? I
> googled Wire-shark, i think it's a tool for TCP/IP stack, does it support
> CAN too?

I am not aware of CAN support in QEMU. It worth to write one
and it would not be so big problem. We have some experience
with QEMU virtual HW implementations already. It could be routed
to Linux SocketCAN virtual/VCAN interface on the host side.

As for other CAN sources, we (still) maintain LinCAN driver
for Linux and some embedded platforms. It has roots in
LDDK some 15 years ago but it has been completely rewritten
form then. This source is under GPL but with linking exception
(intended to be usable for RTEMS). It has been written more with
realtime responses on the mind but it supports much smaller
range of devices. Sources are available at SF.net

  http://ortcan.sourceforge.net/

There is even quite large code base for CANopen and monitoring
tools. Code is used by us for some educational projects and
testing of other CAN systems. So it could worth to look at
it and use some part of it/or some knowledge for RTEMS
development. The LinCAN aggregated knowledge about more CAN
cards has been used by SocketCAN authors during more cards
support development.

It worth to consider implementing SocketCAN compatible
CAN interface for RTEMS. It is very users friendly
but socket layer has some overhead. When I have looked
at RTEMS CAN code last time I have feeling that its
messages queuing could be better. One possibility
is to use LinCAN code other is reuse some queues offered
by RTEMS.

I would like to see more development in RTEMS CAN support.
I can help with some suggestions. I would be happy to help
even by writting of some code but time is against me.

Best wishes,

              Pavel Pisa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130420/f5cc520e/attachment-0001.html>