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

Rempel, Cynthia cynt6007 at
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
2. Download AT91SAM9263-EK Software Package for IAR 5.2, Keil and GNU
3. Navigate to /at91sam9263-ek/packages/
4. Open
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-devel-bounces at] on behalf of jinyang.sia [jinyang.sia at]
Sent: Friday, April 19, 2013 6:06 PM
To: Pavel Pisa
Cc: rtems-devel
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>
Date: 2013-04-19 22:45
To: rtems-devel<mailto:rtems-devel at>; jinyang.sia<mailto:jinyang.sia at>
CC: Rempel, Cynthia<mailto:cynt6007 at>
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

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

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

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