GSoC 2013 - CAN deivers/framework

Rempel, Cynthia cynt6007 at vandals.uidaho.edu
Sat Apr 20 04:48:20 UTC 2013


Hi Jinyang Sia,

Although simulating hardware is not my forte, I was able to find something that looks like it might be potentially helpful...

A manual for qdev (some sort of framework for devices...)
http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg00842.html

Then for plenty of examples,
1. navigate to http://lists.gnu.org/archive/html/qemu-devel/
2. search for: adding emulated device
3. look at how other people added an emulated device...

There's some high-level discussion in:
http://comments.gmane.org/gmane.comp.emulators.qemu/157587

Hopefully, there's a virtual device close to what you want already in the qemu source, and you might be able to reuse it to develop a CAN device... there's also qemu-devel at nongnu.org

Hope this helps...
Cynthia Rempel
________________________________________
From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of jinyang.sia [jinyang.sia at gmail.com]
Sent: Friday, April 19, 2013 6:06 PM
To: Pavel Pisa
Cc: rtems-devel
Subject: Re: Re: GSoC 2013 - CAN deivers/framework

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<mailto:ppisa4lists at pikron.com>
Date: 2013-04-19 22:45
To: rtems-devel<mailto:rtems-devel at rtems.org>; jinyang.sia<mailto:jinyang.sia at gmail.com>
CC: Rempel, Cynthia<mailto:cynt6007 at vandals.uidaho.edu>
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





More information about the devel mailing list