Robert Schwebel wrote:
On Fri, May 14, 2010 at 11:34:47AM +0200, Armin Steinhoff wrote:
The Linux CAN interface is SocketCAN. Do you see a usecase where
this doesn't fit?
IMHO, the SocketCAN interface is simply an overkill for the handling
of small CAN messages. I estimate that the amount of executed code
for handling of a single CAN frame is much bigger as the frame itself
:) Every read and write action creates context switches ...
This is not the case with the user space based driver. Same story
with our PROFIBUS-DP drivers ...
Do you see a use case which shows that a reasonably modern CPU has
performance problems with SocketCAN, while it works fine with your
userspace driver? My impression from previous projects is that, for all
real life scenarios, the advantage of having a standard hardware
abstraction in the kernel
How many "hardware abstractions" do you want in the kernel ?
Realtime != fast.
But a small response time is a technological requirement in order to
meet deadlines. The standard kernel is a _good base_ in order to
implement predictive behavior ... this would not the case if the
response time would be in the range of 100us. OK ... you can have
real-time behavior with a response time of 100us .. but this would be
useless for most real-time applications.
Above you state that you send "1000 frames per second", but that has
nothing to do with response times.
The response time of the whole real-time application
(hardware/driver/application) is the point.
If Linux wouldn't able to handle every 100us a CAN frame ... the whole
real-time application would be useless.
Sending lots of frames works also if
you have for example a CAN chip with a long FIFO, push the frames in and
wait forever.
But every so called "long FIFO" is limited and can reach the overun state.
"Repsonse time" does involve some kind of round trip,
which one do you mean?
Responses of an real-time application to external events ...
Can you elaborate where you see the need for us
response times?
As the minimum reaction time is limited by hardware constraints on
modern cpus anyway, I think that for most applications which require sub
100 us response times, a hardware solution (microcontroller, fpga) is a
better way to achive things.
Why should we use FPGAs when a CPU has multiple cores ?
Every fast fieldbus ( e.g. EtherCAT) needs a reaction time with less
than 100us.
--Armin
---
Armin Steinhoff <as@xxxxxxxxxxxxxxxxxxxxxxxx>
STEINHOFF Automation & Fieldbus-Systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TEL +49-6431 -529366 or -570 99 70
FAX +49-6431 - 57454 or -570 99 80
http://www.steinhoff-automation.com
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
