CANOpen implementation over RTEMS

[Wolfram Wadepohl]

Pavel Pisa schrieb:

> On Tuesday 19 June 2007 17:57, Thomas Doerfler wrote:
> 
>>Hi,
>>
>>Wolfram Wadepohl schrieb:
>>
>>>Joel Sherrill schrieb:
>>>
>>>>I noticed that you mention RTEMS does not have a standard device
>>>>driver model for CAN.  Do you or Thomas have a proposal for a standard
>>>>CAN device interface for RTEMS?
>>>
>>>spoken only for me and not for Thomas, there is no time left to do this
>>>before august.
>>
>>We have currently implemented a CAN driver interface that is directly
>>related to the MSCAN capabilities implemented in the MPC5200. We did not
>>intend to set it as a standard for RTEMS CAN drivers. OTOH, when a
>>CANOpen implementation is desired, I am sure a proper interface should
>>be defined that allows the integration of most CAN controllers available.
> 
> 
> Hello all,
> 
> I have interrest into CANopen support for RTEMS.
> I want to provide some pointers for yours information.
> 
> We (CTU) are maintainers of LinCAN CAN driver for Linux
> and I have it on long long term plan to port it to the
> RTEMS system. We have SJA1000 CAN controller connected
> to our PiMX1 system and it is supported by LinCAN under Linux.
> The PiMX1 board is (on the other hand) used with RTEMS
> in our final application, so porting LinCAN would be logical step.
> Unfortunately I do not expect to have chance to find time
> for this work during next two or three months
> and I would not be even reachable by Internet
> during July.
> 
> Some LinCAN pointers to LinCAN info
> 
> http://www.ocera.org/download/components/WP7/index.html
> http://www.ocera.org/archive/ctu/public/components/lincan/lincan-0.3.3/doc/lincandoc-0.3.pdf
> http://cmp.felk.cvut.cz/~pisa/can/lincan-0.3.4-pre2.tar.gz
> http://cmp.felk.cvut.cz/~pisa/#can
> 
> LinCAN driver is maintained and it is used by more
> companies. Porting it to RTEMS would allow users to test
> applications against same driver API on Linux and RTEMS.
> The LinCAN driver is directly supported by CANfestival
> (CANopen implementation).
> 
> There is also our own CANopen implementation on OCERA
> site, but for device oriented projects CANfestival
> is more mature and simpler. The main idea behind our code
> was to allow build whole dictionary at startup from EDS
> file and link it with real I/O objects at runtime.
> This works and through canblaster and ETHERNET connected
> Java CANmonitor it is possible to browse device dictionaries.
> But our code would require some work to reach industrial grade
> still.
> 
> Other option is to try port another Linux CAN driver
> maturing infrastructure
> 
> SocketCAN
> 
> http://developer.berlios.de/projects/socketcan/
> 

Hello,

thank you Pavel. I could not easily find the licensing terms for LinCAN. Is 
it compatible with the RTEMS license?

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().

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.

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.

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

-- 
Schöne Grüße aus Reutlingen

Wolfram Wadepohl
Forschung & Entwicklung

E&K AUTOMATION
Indumat GmbH & Co. KG
Siemensstraße 3
72766 Reutlingen
Deutschland

Tel.  +49 7121 514-289
Fax   +49 7121 514-299
eMail Wolfram.Wadepohl at ek-automation.com
       W.Wadepohl at ieee.org
WWW   http://www.ek-automation.com
       http://www.indumat.de

Diese Nachricht ist keine geschäftliche Mitteilung i. S. des EHUG.

Bitte senden Sie mir keine Word- oder PowerPoint- (tm Microsoft) Anhänge.
Senden Sie mir einfachen Text, HTML oder PDF.
Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3210 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.rtems.org/pipermail/users/attachments/20070625/a9133872/attachment-0001.bin>