Hi,
Absolutely clear. From the metaphorical chinaman's point of view that is. :)
Thanks all.
Roland.
Jan Kiszka wrote:
Roland Tollenaar wrote:
Hi
Add 1 to 1: The CAN profile describes what IOCTLs are available for CAN
sockets. rt_dev_ioctl() (or ioctl() with the POSIX skin) is the way to
pass these IOCTLs down to the CAN stack.
Actually this sheds quite a bit of light on matters. If you would be
so kind as to give a brief explanation of what a "stack" is exactly. I
have been confronted with the term quite a lot now but its not
becoming clearer. I used to think it was a buffer of some kind. Kind
of like the ones that one "pushes" and "pops" on but I can't see a
connection between that concept and what you say above.
http://en.wikipedia.org/wiki/Protocol_stack? :->
Thanks.
Would that mean that the protocol stack we are looking at is something
like this?:
Yep.
CANOpen (in my application)
RTCAN (incorporated in Xenomai)
CAN Driver (e.g. the PEAK dongle dirver)
Parallel port driver
That driver doesn't exist here technically.
:
Parallel Port Hardware
Dongle
Whereby the last two would officially not make out part of the protocol
stack.
and rt_dev_ioctl passes the IOCTLS to the layer RTCAN in my example above?
Yes.
And in this text
Add 1 to 1: The CAN profile describes what IOCTLs are available for
CAN sockets. rt_dev_ioctl() (or ioctl() with the POSIX skin) is the
way to pass these IOCTLs down to the CAN stack.
the final word should technically speaking not be "stack" but rather
"layer". ?
Yes and no. The first layer to see the request is the CAN protocol
layer, but it may decide to pass it down to the driver, which may decide
to hand it to the hardware. That's why I was speaking of the whole thing
"stack" here.
If all the above is a roughly correct understanding of the situation I
should be able to make a bit more sense out of the CAN code.
Thanks,
Roland
Jan
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
