<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<STYLE>
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
BODY {
LINE-HEIGHT: 1.5; FONT-FAMILY: 宋体; COLOR: #000080; FONT-SIZE: 10.5pt
}
</STYLE>
<META name=GENERATOR content="MSHTML 8.00.6001.19412"></HEAD>
<BODY style="MARGIN: 10px">
<DIV>Thanks,</DIV>
<DIV>It's really give me a lot of help.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>However, I have little konwledge how to add hardware simulation to QEMU.
Hope to get more guidance from you on this point.</DIV>
<DIV> </DIV>
<DIV>Thanks, best wishes</DIV>
<HR style="WIDTH: 210px; HEIGHT: 1px" align=left color=#b5c4df SIZE=1>
<DIV><SPAN>jinyang.sia</SPAN></DIV>
<DIV> </DIV>
<DIV
style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0cm; PADDING-LEFT: 0cm; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<DIV
style="PADDING-BOTTOM: 8px; PADDING-LEFT: 8px; PADDING-RIGHT: 8px; BACKGROUND: #efefef; COLOR: #000000; FONT-SIZE: 12px; PADDING-TOP: 8px">
<DIV><B>From:</B> <A href="mailto:ppisa4lists@pikron.com">Pavel
Pisa</A></DIV>
<DIV><B>Date:</B> 2013-04-19 22:45</DIV>
<DIV><B>To:</B> <A href="mailto:rtems-devel@rtems.org">rtems-devel</A>; <A
href="mailto:jinyang.sia@gmail.com">jinyang.sia</A></DIV>
<DIV><B>CC:</B> <A href="mailto:cynt6007@vandals.uidaho.edu">Rempel,
Cynthia</A></DIV>
<DIV><B>Subject:</B> Re: GSoC 2013 - CAN
deivers/framework</DIV></DIV></DIV>
<DIV>
<DIV>Hello all,</DIV>
<DIV> </DIV>
<DIV>if we speak about CAN for Linux than there is already</DIV>
<DIV>establishes standard and that is SocketCAN.</DIV>
<DIV>It support the most of the board.</DIV>
<DIV> </DIV>
<DIV>The code for the CAN packet family, device support and drivers</DIV>
<DIV>is mainlined. Some for IP tool to setup basic parameters.</DIV>
<DIV>The SocketCAN development repositories are at</DIV>
<DIV> </DIV>
<DIV> http://gitorious.org/linux-can</DIV>
<DIV> </DIV>
<DIV>The mailing list is at</DIV>
<DIV> </DIV>
<DIV> http://vger.kernel.org/vger-lists.html#linux-can</DIV>
<DIV> </DIV>
<DIV>On Friday 19 April 2013 10:55:45 jinyang.sia wrote:</DIV>
<DIV>> Can4linux is widely used on Linux, but is there a copyright problem? for</DIV>
<DIV>> can4linux and RTEMS?</DIV>
<DIV> </DIV>
<DIV>Can4linux is probably not of much interrest today.</DIV>
<DIV>As for licensing, I see that as very problematic to use</DIV>
<DIV>any Linux code.</DIV>
<DIV> </DIV>
<DIV>I am not 100% sure about Can4linux but all SocketCAN</DIV>
<DIV>code is licensed under GPLv2 which disqualifies it for inclusion</DIV>
<DIV>in the RTEMS mainline (GPL + linking exception). May it be</DIV>
<DIV>we could try to ask for license extension main contributors</DIV>
<DIV>but I expect that it would be very problematic.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>> And i also have some question on qemu-system-arm, does it support CAN? I</DIV>
<DIV>> googled Wire-shark, i think it's a tool for TCP/IP stack, does it support</DIV>
<DIV>> CAN too?</DIV>
<DIV> </DIV>
<DIV>I am not aware of CAN support in QEMU. It worth to write one</DIV>
<DIV>and it would not be so big problem. We have some experience</DIV>
<DIV>with QEMU virtual HW implementations already. It could be routed</DIV>
<DIV>to Linux SocketCAN virtual/VCAN interface on the host side.</DIV>
<DIV> </DIV>
<DIV>As for other CAN sources, we (still) maintain LinCAN driver</DIV>
<DIV>for Linux and some embedded platforms. It has roots in</DIV>
<DIV>LDDK some 15 years ago but it has been completely rewritten</DIV>
<DIV>form then. This source is under GPL but with linking exception</DIV>
<DIV>(intended to be usable for RTEMS). It has been written more with</DIV>
<DIV>realtime responses on the mind but it supports much smaller</DIV>
<DIV>range of devices. Sources are available at SF.net</DIV>
<DIV> </DIV>
<DIV> http://ortcan.sourceforge.net/</DIV>
<DIV> </DIV>
<DIV>There is even quite large code base for CANopen and monitoring</DIV>
<DIV>tools. Code is used by us for some educational projects and</DIV>
<DIV>testing of other CAN systems. So it could worth to look at</DIV>
<DIV>it and use some part of it/or some knowledge for RTEMS</DIV>
<DIV>development. The LinCAN aggregated knowledge about more CAN</DIV>
<DIV>cards has been used by SocketCAN authors during more cards</DIV>
<DIV>support development.</DIV>
<DIV> </DIV>
<DIV>It worth to consider implementing SocketCAN compatible</DIV>
<DIV>CAN interface for RTEMS. It is very users friendly</DIV>
<DIV>but socket layer has some overhead. When I have looked</DIV>
<DIV>at RTEMS CAN code last time I have feeling that its</DIV>
<DIV>messages queuing could be better. One possibility</DIV>
<DIV>is to use LinCAN code other is reuse some queues offered</DIV>
<DIV>by RTEMS.</DIV>
<DIV> </DIV>
<DIV>I would like to see more development in RTEMS CAN support.</DIV>
<DIV>I can help with some suggestions. I would be happy to help</DIV>
<DIV>even by writting of some code but time is against me.</DIV>
<DIV> </DIV>
<DIV>Best wishes,</DIV>
<DIV> </DIV>
<DIV> Pavel Pisa</DIV></DIV></BODY></HTML>