CANOpen implementation over RTEMS
Wolfram.Wadepohl at ek-automation.com
Mon Jun 25 08:14:31 UTC 2007
Pavel Pisa schrieb:
> On Tuesday 19 June 2007 17:57, Thomas Doerfler wrote:
>>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
>>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
> 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
> Other option is to try port another Linux CAN driver
> maturing infrastructure
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()
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
We have planned some programming resources for CAN/open redesign in the 3rd
quarter this year.
Schöne Grüße aus Reutlingen
Forschung & Entwicklung
Indumat GmbH & Co. KG
Tel. +49 7121 514-289
Fax +49 7121 514-299
eMail Wolfram.Wadepohl at ek-automation.com
W.Wadepohl at ieee.org
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3210 bytes
Desc: S/MIME Cryptographic Signature
More information about the users