[Xenomai-help] RT socket CAN architecture

[Xenomai-help] RT socket CAN architecture

[Frits de Klark]

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

Hello everyone,

I'm in the need of a realtime CAN driver which is as fast as possible and at
the same time user-friendly. The RT socket CAN driver looks rather appealing
to me, but I'm wondering if there's any negative impact on speed (in the
context of minimal response times) in using a socket approach.
Also, is there any of you with some testresults?

Thanks very much in advance!

Best regards,

Frits

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

Re: [Xenomai-help] RT socket CAN architecture

[Jan Kiszka]

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

Frits de Klark wrote:
> Hello everyone,
> 
> I'm in the need of a realtime CAN driver which is as fast as possible
> and at
> the same time user-friendly. The RT socket CAN driver looks rather
> appealing
> to me, but I'm wondering if there's any negative impact on speed (in the
> context of minimal response times) in using a socket approach.
> Also, is there any of you with some testresults?

Wolfgang once had some test results (and application code) on
hardware-based loopback latencies, maybe he can post them when time permits.

For sure, twiddling directly with the CAN hardware is always faster than
having generic layer(s) in between, but the impact of the CAN stack is
fairly small, specifically as we have a direct wake-up path from the IRQ
to the application on reception or TX buffer availability.

Do you have any scenario and/or numbers you would like to compare them
against?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] RT socket CAN architecture

[Wolfgang Grandegger]

Jan Kiszka wrote:
> Frits de Klark wrote:
>> Hello everyone,
>>
>> I'm in the need of a realtime CAN driver which is as fast as possible
>> and at
>> the same time user-friendly. The RT socket CAN driver looks rather
>> appealing
>> to me, but I'm wondering if there's any negative impact on speed (in the
>> context of minimal response times) in using a socket approach.
>> Also, is there any of you with some testresults?
> 
> Wolfgang once had some test results (and application code) on
> hardware-based loopback latencies, maybe he can post them when time permits.

A while ago I ported the round-trip-test from RTnet. "rtcan_rtt" is a 
simplified version available in rtsocketcan-0.90.0.tar.bz2 at 
ftp://ftp.denx.de/pub/xenomai/rtsocketcan.

> For sure, twiddling directly with the CAN hardware is always faster than
> having generic layer(s) in between, but the impact of the CAN stack is
> fairly small, specifically as we have a direct wake-up path from the IRQ
> to the application on reception or TX buffer availability.
> 
> Do you have any scenario and/or numbers you would like to compare them
> against?

And what platform do you intend to use?

Wolfgang.