[Xenomai-help] State of implementation of CAN, CANOpen in Xenomai

[Xenomai-help] State of implementation of CAN, CANOpen in Xenomai

[Berruer Sébastien]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

Hello,

I'm reviewing the feasibility of a project that would require the driving of
devices with real time constrains.

I'm asking for the current state of the CAN implementation. Is it a partial or a
complete implementation of the CAN standard? What are the guarantee about real
time latency?

I explored briefly the sources of Xenomai, and I read the file
"ksrc/drivers/can/README". Is it up-to-date? Is there really only support for
the controllers listed in it?

I've read in "RTDM and applications" that there would be an effort for
implementing a CANOpen profile. But, the implementation of CANOpen protocol is
let to users? I can't find any newer reference for that in sources or in the
documentation of Xenomai. What is the state of this project?

I've seen that there is currently only one implementation of a RT driver for the
16550A serial controller. Has anybody implemented it for other chip?

If I finally decide to choose a RT-Patch, instead of Xenomai, I will have the
CAN implementation that will use the Linux networking stack. But I will not have
any guarantee about its real time implementation, isn't it?

I hope that somebody can answer my questions. May I ask those directly to
Wolfgang Grandegger or Sebastian Smolorz? Or on the "SocketCan" mailing list?

Best regards,

=================================
| BERRUER Sébastien             |
| Trainee at Altran Ouest       |
| Centre d'Affaires Alphasis    |
| 35760 Saint-Grégoire - FRANCE |
| Tel: 06-76-35-29-55           |
=================================



[-- Attachment #2: Type: text/html, Size: 2309 bytes --]

Re: [Xenomai-help] State of implementation of CAN, CANOpen in Xenomai

[Wolfgang Grandegger]

Berruer Sébastien wrote:
> Hello,
> 
> I'm reviewing the feasibility of a project that would require the driving of
> devices with real time constrains.

OK, then RT-Socket-CAN is a good choice.

> I'm asking for the current state of the CAN implementation. Is it a
> partial or a
> complete implementation of the CAN standard? What are the guarantee
> about real
> time latency?

What exactly do you mean with CAN standard? RT-Socket-CAN allows
low-level access the CAN controller to send and receive messages, handle
errors and set the bit-timing. Standard, extended and RTR frames are
supported.

> I explored briefly the sources of Xenomai, and I read the file
> "ksrc/drivers/can/README". Is it up-to-date? Is there really only
> support for
> the controllers listed in it?

Mainly yes, what CAN controller would you like to use? Writing a
RT-Socket-CAN driver is usually not a big deal.

> I've read in "RTDM and applications" that there would be an effort for
> implementing a CANOpen profile. But, the implementation of CANOpen
> protocol is
> let to users? I can't find any newer reference for that in sources or in the
> documentation of Xenomai. What is the state of this project?

If you are looking for a free CANopen implementation, CANfestival might
be an option, which also supports RT-Socket-CAN, IIRC. Check
http://canfestival.org/ for further information.

> I've seen that there is currently only one implementation of a RT driver
> for the
> 16550A serial controller. Has anybody implemented it for other chip?

What chip/hardware do you have in mind?

> If I finally decide to choose a RT-Patch, instead of Xenomai, I will
> have the
> CAN implementation that will use the Linux networking stack. But I will
> not have
> any guarantee about its real time implementation, isn't it?

The Linux network stack is not hard real-time capable and the real-time
preemption patch will only help partially.

Wolfgang.

[Xenomai-help] RE : State of implementation of CAN, CANOpen in Xenomai

[Berruer Sébastien]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

I'm on the first step of the project and I have to choose a complete system for my customer. I looking at the constraints both for hardware and software and the possibly dependency between them.



> I'm asking for the current state of the CAN implementation. Is it a
> partial or a
> complete implementation of the CAN standard? What are the guarantee
> about real
> time latency?

What exactly do you mean with CAN standard? RT-Socket-CAN allows
low-level access the CAN controller to send and receive messages, handle
errors and set the bit-timing. Standard, extended and RTR frames are
supported.

Sorry, I've made a misunderstood about the CAN organization. In fact, the RT-Socket-CAN is a kind of user API for ease the use of CAN bus, isn't it? It seems that, generally, the handling of protocol, like the access to media or arbitration, is done in the chip.



> I explored briefly the sources of Xenomai, and I read the file
> "ksrc/drivers/can/README". Is it up-to-date? Is there really only
> support for
> the controllers listed in it?

Mainly yes, what CAN controller would you like to use? Writing a
RT-Socket-CAN driver is usually not a big deal.

I asked this to point at the dependency between the software and the hardware. For time, the most part of boards that I've seen had the SJA100 controller, so that won't be a problem.



> I've read in "RTDM and applications" that there would be an effort for
> implementing a CANOpen profile. But, the implementation of CANOpen
> protocol is
> let to users? I can't find any newer reference for that in sources or in the
> documentation of Xenomai. What is the state of this project?

If you are looking for a free CANopen implementation, CANfestival might
be an option, which also supports RT-Socket-CAN, IIRC. Check
http://canfestival.org/ for further information.

My client asks for a complete implementation of the CANOpen protocol. I will take all a look at this site and if it's clear for that use. 



> I've seen that there is currently only one implementation of a RT driver
> for the
> 16550A serial controller. Has anybody implemented it for other chip?

What chip/hardware do you have in mind?

Similarly to CAN hardware, almost the hardware that I've seen yet use this controller or a 8250 chip.



Best regards, and really thanks for help,

=================================
| BERRUER Sébastien             |
| Trainee at Altran Ouest       |
| Centre d'Affaires Alphasis    |
| 35760 Saint-Grégoire - FRANCE |
| Tel: 06-76-35-29-55           |
=================================






[-- Attachment #2: Type: text/html, Size: 3582 bytes --]

Re: [Xenomai-help] RE : State of implementation of CAN, CANOpen in Xenomai

[Wolfgang Grandegger]

Berruer Sébastien wrote:
> I'm on the first step of the project and I have to choose a complete
> system for my customer. I looking at the constraints both for hardware
> and software and the possibly dependency between them.

OK.

>> I'm asking for the current state of the CAN implementation. Is it a
>> partial or a
>> complete implementation of the CAN standard? What are the guarantee
>> about real
>> time latency?
> 
> What exactly do you mean with CAN standard? RT-Socket-CAN allows
> low-level access the CAN controller to send and receive messages, handle
> errors and set the bit-timing. Standard, extended and RTR frames are
> supported.
> 
> Sorry, I've made a misunderstood about the CAN organization. In fact,
> the RT-Socket-CAN is a kind of user API for ease the use of CAN bus,
> isn't it? It seems that, generally, the handling of protocol, like the
> access to media or arbitration, is done in the chip.

Yep.

>> I've read in "RTDM and applications" that there would be an effort for
>> implementing a CANOpen profile. But, the implementation of CANOpen
>> protocol is
>> let to users? I can't find any newer reference for that in sources or
> in the
>> documentation of Xenomai. What is the state of this project?
> 
> If you are looking for a free CANopen implementation, CANfestival might
> be an option, which also supports RT-Socket-CAN, IIRC. Check
> http://canfestival.org/ for further information.
> 
> My client asks for a complete implementation of the CANOpen protocol. I
> will take all a look at this site and if it's clear for that use.

Usually, only a sub-set of the CANopen protocol is implemented.

Wolfgang