CANOpen implementation over RTEMS

[Pavel Pisa]

Hello Wolfram,

On Monday 25 June 2007 10:14, Wolfram Wadepohl wrote:
> Hello,
>
> thank you Pavel. I could not easily find the licensing terms for LinCAN. Is
> it compatible with the RTEMS license?

I think, that it should not be a problem.
I maintain this code from 2003. The original author is Arnaud Westenberg.
I have discussed his opinion about possibility to use code
under LGPL at the beginning and he has not been against that.
I have not been able to contact him last years, but I have
rewritten almost twice the code during OCERA project
and I think, that there is no problem to add RTEMS exception
to the code for us at CTU (Czech Technical University).
Some core parts of the actual driver code are even written
from scratch (queues, OS support etc).

> First of all we have to diffentiate between CAN and CANopen.
>
> For the basics we need a "standard" access method to the CAN driver. LinCAN
> uses the classic driver interface based on open(), close(), read(), write()
> and ioctl().

This is how LinCAN is designed.

> I have taken a very quick look at the socketCAN interface, which has its
> origin at Volkswagen AG. This software package is licensed under "GPL
> version 2 or any later version".
>
> The socket concept is borrowed from the BSD networking sockets and provides
> a clear interface for layered services. CAN and CANopen are layered
> services as the networking stack and IMHO this type of basic interface
> suits very fine.
>
> Also the socket code needs an interface to the drivers code, the definition
> from LinCAN may be appropriate.

The SocketCAN drivers are directly connected to the network devices
queues in Linux environment. Some common functionality is added through
protocol/address family support and some common code. But there is no
character driver interface there.

> One major question is, if the driver uses callbacks on receiving CAN
> messages. We use only master functions at this time and callbacks are not
> necessary for our application. I can imagine that for some slave
> applications callbacks may be better than some process waiting for the next
> message.

The hooks are possible for RTEMS, but we have not seen such possibility
for Linux system with direct separation of kernel/driver and user space.

> We have planned some programming resources for CAN/open redesign in the 3rd
> quarter this year.

It would be nice, if work could be somehow coordinated.

Best wishes

              Pavel