GSoC 2013 - CAN drivers/framework -> AT91SAM9263 BSP?

Sun Apr 21 16:16:44 UTC 2013

Hi,
There is also http://wiki.rtems.org/wiki/index.php/CanFestival that
comes from a 2007 email. I don't know if the participating parties
still are interested or made other progress, but it might be worth
checking with them. The wiki page mentions LGPL is compatible with
RTEMS, but actually this is not certain.
-Gedare

On Sun, Apr 21, 2013 at 12:01 PM, Rempel, Cynthia
<cynt6007 at vandals.uidaho.edu> wrote:
> Hi Jinyang Sia and Pavel Pisa,
>
> After much looking, I found another can driver that might meet the licensing needs: the licensing terms are extremely generous...
>
> 1. Navigate to http://www.atmel.com/tools/AT91SAMSOFTWAREPACKAGE.aspx
> 2. Download AT91SAM9263-EK Software Package for IAR 5.2, Keil and GNU
> 3. Navigate to /at91sam9263-ek/packages/
> 4. Open basic-can-project-at91sam9263-ek-gnu.zip
> 5. Navigate to /basic-can-project-at91sam9263-ek/at91lib/peripherals/can/
>
> However, as you indicated the board you are developing with does not have a BSP, would it be desirable to change your project to developing a board support package for the AT91SAM9263 arm processor?  There are quite a few drivers in the software package...
>
> It does look like ATMEL also provided .gdb files, but I don't know if those are for assisting with simulations or not...
>
> 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
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel