GSoC 2013 - CAN drivers/framework -> AT91SAM9263 BSP?
cynt6007 at vandals.uidaho.edu
Sun Apr 21 16:01:31 UTC 2013
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!
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
Subject: Re: Re: GSoC 2013 - CAN deivers/framework
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
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
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
The mailing list is at
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
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
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
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.
More information about the devel