[Xenomai-core] RTDM 82527 Xenomai driver

[Xenomai-core] RTDM 82527 Xenomai driver

[juanba romance]

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

Hello, all,
I am currently developing a RTDM/xenomai driver for the CANbus chipset 82527
that i think it could have some interest
it has the next features:

   1. Specific management for the remote frames CANbus feasibility, it
   couple the real-time data bus flow with a user software feedback to
   handshake remote frames and update mailbox callback for the auto-replied
   messages
   2. Transparent use to push/suck data from the driver using a common
   data format
   3. Capability to push a bunch of CANbus messages in a single system
   call. The bunch is copied to a kernel domain ring buffer to guarantee low
   latencies at the user side. A specific kernel thread  sucks the ring pushing
   the user request into the chipset
   4. Driver readout using a native RT message queue where the control
   and data flow is published
   5. Multichipset capabilities, right now a commercial PC104 board with
   two devices is used. The on board CPU is a SBC VIA C3 1GHz processor
   softwared with the stack xenomai-2.3,1/vanilla-2.6.20-15/Adeos-
   ipipe-1.7-03
   6. board monitoring through the /proc file system entry
   7. Local Data Transfers controlled with RT-alarms
   8. Virtual support to check applications/driver usage/design, right
   now only the chipset is virtualised, but plans to have network transactions
   are on going
   9. ISR hardware optimizations focused on the network readout to
   gurantee low latencies
   10. Easy porting to other i82527 based on boards
   11. Full transmission operation handling the 16 message object set

We have in plan also

   1. Capabilities to filtering/masking the incoming flow at the driver
   stage allowing that the same context, using the "xenomai nomenclature" feed
   specific threads using some kind of binding/configuration process. This is
   an open issue cause i don't have a clear approach to follow..
   2. can-festival coupling

I think this is the full picture, i look forward..

Best regards..

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

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[Wolfgang Grandegger]

Hello,

juanba romance wrote:
> Hello, all,
> I am currently developing a RTDM/xenomai driver for the CANbus chipset 
> 82527 that i think it could have some interest
> it has the next features:
> 
>    1. Specific management for the remote frames CANbus feasibility, it
>       couple the real-time data bus flow with a user software feedback
>       to handshake remote frames and update mailbox callback for the
>       auto-replied messages
>    2. Transparent use to push/suck data from the driver using a common
>       data format
>    3. Capability to push a bunch of CANbus messages in a single system
>       call. The bunch is copied to a kernel domain ring buffer to
>       guarantee low latencies at the user side. A specific kernel
>       thread  sucks the ring pushing the user request into the chipset
>    4. Driver readout using a native RT message queue where the control
>       and data flow is published
>    5. Multichipset capabilities, right now a commercial PC104 board with
>       two devices is used. The on board CPU is a SBC VIA C3 1GHz
>       processor softwared with the stack
>       xenomai-2.3,1/vanilla-2.6.20-15/Adeos-ipipe-1.7-03
>    6. board monitoring through the /proc file system entry
>    7. Local Data Transfers controlled with RT-alarms
>    8. Virtual support to check applications/driver usage/design, right
>       now only the chipset is virtualised, but plans to have network
>       transactions are on going
>    9. ISR hardware optimizations focused on the network readout to
>       gurantee low latencies
>   10. Easy porting to other i82527 based on boards
>   11. Full transmission operation handling the 16 message object set 
> 
> We have in plan also
> 
>    1. Capabilities to filtering/masking the incoming flow at the driver
>       stage allowing that the same context, using the "xenomai
>       nomenclature" feed specific threads using some kind of
>       binding/configuration process. This is an open issue cause i don't
>       have a clear approach to follow..
>    2. can-festival coupling
> 
> I think this is the full picture, i look forward..

Are you aware that there is already a RT-Socket-CAN driver coming with 
Xenomai, which has most of the feature you listed above?

http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/README
http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html

There is not yet a driver for the i82527, but I already started to 
implement it.

Wolfgang.

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[Jan Kiszka]

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

juanba romance wrote:
> Hello, all,
> I am currently developing a RTDM/xenomai driver for the CANbus chipset 82527
> that i think it could have some interest
> it has the next features:

Thanks for moving our private thread here! See, now we know that
Wolfgang is already working on 82527 support for RT-Socket-CAN -
something I wasn't aware of as well.

> 
>    1. Specific management for the remote frames CANbus feasibility, it
>    couple the real-time data bus flow with a user software feedback to
>    handshake remote frames and update mailbox callback for the auto-replied
>    messages

Mind to elaborate what you precisely gain here compared to "open-coded"
designs (loop closed over the application)? Can you quantify the
improvements?

>    2. Transparent use to push/suck data from the driver using a common
>    data format
>    3. Capability to push a bunch of CANbus messages in a single system
>    call. The bunch is copied to a kernel domain ring buffer to guarantee low
>    latencies at the user side. A specific kernel thread  sucks the ring pushing
>    the user request into the chipset

That was discussed before in the context of Socket-CAN. My feeling is
that it /could/ be useful in case you have to issue longer streams of
CAN frames at high rates, and specifically if your CAN hardware can
handle these streams autonomously. Is the 82527 able to do so?

In any case, this would complicate the existing stack and driver and
would first require careful evaluation of the achievable improvement
(lower latency, lower system load?).

>    4. Driver readout using a native RT message queue where the control
>    and data flow is published

And this way you make your driver unportable, e.g. to move it over the
RTDM layer Wolfgang wrote for the -rt kernel. RTDM drivers are ought to
use RTDM services (or Linux ones), not other skins. If a generally
useful service is lacking, we need to think about adding it - to RTDM.

>    5. Multichipset capabilities, right now a commercial PC104 board with
>    two devices is used. The on board CPU is a SBC VIA C3 1GHz processor
>    softwared with the stack xenomai-2.3,1/vanilla-2.6.20-15/Adeos-
>    ipipe-1.7-03
>    6. board monitoring through the /proc file system entry
>    7. Local Data Transfers controlled with RT-alarms

Another violation - but this one is easily avoidable with RTDM timers
that come with API revision 6 (upcoming Xenomai 2.4).

>    8. Virtual support to check applications/driver usage/design, right
>    now only the chipset is virtualised, but plans to have network transactions
>    are on going
>    9. ISR hardware optimizations focused on the network readout to
>    gurantee low latencies

Any numbers?

>    10. Easy porting to other i82527 based on boards
>    11. Full transmission operation handling the 16 message object set
> 
> We have in plan also
> 
>    1. Capabilities to filtering/masking the incoming flow at the driver
>    stage allowing that the same context, using the "xenomai nomenclature" feed
>    specific threads using some kind of binding/configuration process. This is
>    an open issue cause i don't have a clear approach to follow..
>    2. can-festival coupling

Look, with Socket-CAN, you would now already have CAN-Festival binding. :)

But maybe this library scenario can be used to explain why you need to
do things in a special way and what you can gain that way. Looking forward!

> 
> I think this is the full picture, i look forward..
> 
> Best regards..
> 

Jan


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

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[juanba romance]

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

On 8/13/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> juanba romance wrote:
> > Hello, all,
> > I am currently developing a RTDM/xenomai driver for the CANbus chipset
> 82527
> > that i think it could have some interest
> > it has the next features:
>
> Thanks for moving our private thread here! See, now we know that
> Wolfgang is already working on 82527 support for RT-Socket-CAN -
> something I wasn't aware of as well.
>
> >
> >    1. Specific management for the remote frames CANbus feasibility, it
> >    couple the real-time data bus flow with a user software feedback to
> >    handshake remote frames and update mailbox callback for the
> auto-replied
> >    messages
>
> Mind to elaborate what you precisely gain here compared to "open-coded"
> designs (loop closed over the application)? Can you quantify the
> improvements?


After review your current user interface i can not understand how a RF cycle
flows through the user application
holding as much as possible the latency at the receiver side. Maybe it's my
own misunderstanding.
The point is one node requests an information to another one issuing a RF,
the CAN specification says that the RF receptor will handshake the cycle
issuing the corresponding DF, and right here is when/where i am fuzzy. We
use this capability using real time as much as possible only relying on the
CANbus network load, i mean we perform the RF handshake using the RF
receptor mailbox auto-reply capability, feedbacking the user software only
when the DF handshake is decoded at the network, this event will trigger the
user actions i.e. the message data update with the new local variables
state. This feature is requested through  the configuration stage, this kind
of information is labeled as "quick.ack" responses , cause are not related
with software at all. The RF requester has the guarantee  that the
information is sampled with any jitter software coupled. The typical
approach found in other stacks is labelled as "slow.ack", it avoids to
response the RF-request up to reach any software area (kernel/user spaces)
that explicitly issue the data-frame as usual, this is how can-festival
currently works.

Both operations are included in the proposal.

>    2. Transparent use to push/suck data from the driver using a common
> >    data format
> >    3. Capability to push a bunch of CANbus messages in a single system
> >    call. The bunch is copied to a kernel domain ring buffer to guarantee
> low
> >    latencies at the user side. A specific kernel thread  sucks the ring
> pushing
> >    the user request into the chipset
>
> That was discussed before in the context of Socket-CAN. My feeling is
> that it /could/ be useful in case you have to issue longer streams of
> CAN frames at high rates, and specifically if your CAN hardware can
> handle these streams autonomously. Is the 82527 able to do so?
>
> In any case, this would complicate the existing stack and driver and
> would first require careful evaluation of the achievable improvement
> (lower latency, lower system load?).

The i82527 has 15 mailboxes with fixed priority, the lowest one is hardwared
to the RX operation. So theoretically  you can pipeline up to 14 TX
messages. When the stuff is full, we are labeled it as a  "pileup"  because
the hardware handler has to wait up to get some free one, this operation is
performed in our case through the either the mailbox-alarm mechanism or the
ISR transmission side . I have mention the "low latency" term, cause i have
decoupled the loopback-tx feedback from the ISR to a kernel RT thread/task
so the ISR only cleans/stops the mailbox software/hardware resources. The
user call is only blocked the time required to push the message bunch into
the transmission ring. The physical user transmission is performed in
open-loop if no error/alarm is sampled..


> >    4. Driver readout using a native RT message queue where the control
> >    and data flow is published
>
> And this way you make your driver unportable, e.g. to move it over the
> RTDM layer Wolfgang wrote for the -rt kernel. RTDM drivers are ought to
> use RTDM services (or Linux ones), not other skins. If a generally
> useful service is lacking, we need to think about adding it - to RTDM.
>
Fully deliberated. this is one the reason cause i labelled the stuff as
"xenomai-RTDM" instead of "RTDM". I assume that the native layer is
available to be used at all. My first intention is not to build something
fully compliance with the RTDM layer, this is a second step from my point of
view. I need ASAP the driver ready to be used in a Xenomai framework  where
our applications are running..

>    5. Multichipset capabilities, right now a commercial PC104 board with
> >    two devices is used. The on board CPU is a SBC VIA C3 1GHz processor
> >    softwared with the stack xenomai-2.3,1/vanilla-2.6.20-15/Adeos-
> >    ipipe-1.7-03
> >    6. board monitoring through the /proc file system entry
> >    7. Local Data Transfers controlled with RT-alarms
>
> Another violation - but this one is easily avoidable with RTDM timers
> that come with API revision 6 (upcoming Xenomai 2.4).

Same as above


>    8. Virtual support to check applications/driver usage/design, right
> >    now only the chipset is virtualised, but plans to have network
> transactions
> >    are on going
> >    9. ISR hardware optimizations focused on the network readout to
> >    gurantee low latencies
>
> Any numbers?

Right now i am on holidays and i can't not run any scope test, but i
remember that the worst case was around to 100usec to fully read the mailbox
plenty of 8 bytes. It is fully coupled to the hardware ISA mapping, every
chipset register read cycle requires three io operations to write the
addressed register, perform a dummy read  and the valid read one. This
killer takes 500nsec to each chipset select activation, but the most burner
is 1000nsec between each in,out IO address space instruction so around
4usec/sucked byte,
We have implementing the chipset clearing and data sucking with ~ 20 io
cycles , so the numbers fit quite with the xenomai-i386 latencies.

>    10. Easy porting to other i82527 based on boards
> >    11. Full transmission operation handling the 16 message object set
> >
> > We have in plan also
> >
> >    1. Capabilities to filtering/masking the incoming flow at the driver
> >    stage allowing that the same context, using the "xenomai
> nomenclature" feed
> >    specific threads using some kind of binding/configuration process.
> This is
> >    an open issue cause i don't have a clear approach to follow..
> >    2. can-festival coupling
>
> Look, with Socket-CAN, you would now already have CAN-Festival binding. :)

Yes, i know it's clear motivation to use it ;-)


> But maybe this library scenario can be used to explain why you need to
> do things in a special way and what you can gain that way. Looking
> forward!

>From my point of view the RTDM layout is ideal to perform linux porting
The fact related on with the missed chipset support and the gained
experience developing standard linux drivers using this chipset biased my
approach a lot. For sure, that if the chipset support were provided in time
we will re-consider the stuff to re-usage/patch the official stack if the
latencies are similar..

>
> > I think this is the full picture, i look forward..
> >
> > Best regards..
> >
> Jan
>

IHTH..
Best regards..

Juanba

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

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[Jan Kiszka]

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

juanba romance wrote:
> On 8/13/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> juanba romance wrote:
>>> Hello, all,
>>> I am currently developing a RTDM/xenomai driver for the CANbus chipset
>> 82527
>>> that i think it could have some interest
>>> it has the next features:
>> Thanks for moving our private thread here! See, now we know that
>> Wolfgang is already working on 82527 support for RT-Socket-CAN -
>> something I wasn't aware of as well.
>>
>>>    1. Specific management for the remote frames CANbus feasibility, it
>>>    couple the real-time data bus flow with a user software feedback to
>>>    handshake remote frames and update mailbox callback for the
>> auto-replied
>>>    messages
>> Mind to elaborate what you precisely gain here compared to "open-coded"
>> designs (loop closed over the application)? Can you quantify the
>> improvements?
> 
> 
> After review your current user interface i can not understand how a RF cycle
> flows through the user application
> holding as much as possible the latency at the receiver side. Maybe it's my
> own misunderstanding.
> The point is one node requests an information to another one issuing a RF,
> the CAN specification says that the RF receptor will handshake the cycle
> issuing the corresponding DF, and right here is when/where i am fuzzy. We
> use this capability using real time as much as possible only relying on the
> CANbus network load, i mean we perform the RF handshake using the RF
> receptor mailbox auto-reply capability, feedbacking the user software only
> when the DF handshake is decoded at the network, this event will trigger the
> user actions i.e. the message data update with the new local variables
> state. This feature is requested through  the configuration stage, this kind
> of information is labeled as "quick.ack" responses , cause are not related
> with software at all. The RF requester has the guarantee  that the
> information is sampled with any jitter software coupled. The typical
> approach found in other stacks is labelled as "slow.ack", it avoids to
> response the RF-request up to reach any software area (kernel/user spaces)
> that explicitly issue the data-frame as usual, this is how can-festival
> currently works.

The point is that quite a few CAN controllers do not support this
hardware-based RF reply. And as Socket-CAN aims at a _generic_ API, not
the n-th Intel or MSCAN or whatever CAN stack, we had to define the
basic interface without such special support first.

But that doesn't mean we would be unable to extend the profile with
optional or, when required, software-emulated accelerations like for RTR
handling. That's what we're interested in: How may such an extension
look like to exploit the hardware to its limits where available,
_without_ giving up CAN application portability?

> 
> Both operations are included in the proposal.
> 
>>    2. Transparent use to push/suck data from the driver using a common
>>>    data format
>>>    3. Capability to push a bunch of CANbus messages in a single system
>>>    call. The bunch is copied to a kernel domain ring buffer to guarantee
>> low
>>>    latencies at the user side. A specific kernel thread  sucks the ring
>> pushing
>>>    the user request into the chipset
>> That was discussed before in the context of Socket-CAN. My feeling is
>> that it /could/ be useful in case you have to issue longer streams of
>> CAN frames at high rates, and specifically if your CAN hardware can
>> handle these streams autonomously. Is the 82527 able to do so?
>>
>> In any case, this would complicate the existing stack and driver and
>> would first require careful evaluation of the achievable improvement
>> (lower latency, lower system load?).
> 
> The i82527 has 15 mailboxes with fixed priority, the lowest one is hardwared
> to the RX operation. So theoretically  you can pipeline up to 14 TX
> messages. When the stuff is full, we are labeled it as a  "pileup"  because
> the hardware handler has to wait up to get some free one, this operation is
> performed in our case through the either the mailbox-alarm mechanism or the
> ISR transmission side . I have mention the "low latency" term, cause i have
> decoupled the loopback-tx feedback from the ISR to a kernel RT thread/task
> so the ISR only cleans/stops the mailbox software/hardware resources. The

So you already have task context here (+ the challenge to manage
priorities). Did you measure the difference in latencies between kernel
and user space on your platform? If your hardware is slow (ISA...)
and/or the platform is fast, that doesn't make much difference anymore,
thus you are already half way to use the standard API, maybe with some
CAN library for the boring routine work.

> user call is only blocked the time required to push the message bunch into
> the transmission ring. The physical user transmission is performed in
> open-loop if no error/alarm is sampled..
> 
> 
>>>    4. Driver readout using a native RT message queue where the control
>>>    and data flow is published
>> And this way you make your driver unportable, e.g. to move it over the
>> RTDM layer Wolfgang wrote for the -rt kernel. RTDM drivers are ought to
>> use RTDM services (or Linux ones), not other skins. If a generally
>> useful service is lacking, we need to think about adding it - to RTDM.
>>
> Fully deliberated. this is one the reason cause i labelled the stuff as
> "xenomai-RTDM" instead of "RTDM". I assume that the native layer is
> available to be used at all. My first intention is not to build something
> fully compliance with the RTDM layer, this is a second step from my point of
> view. I need ASAP the driver ready to be used in a Xenomai framework  where
> our applications are running..

Yeah, the old problem: "But we need it immediately!" However, keep in
mind: CAN controllers come and go (just as SoC come an go), the
programming model should be there to stay. And using a standard API,
maybe tuning it in the direction you need, raises the chances that
future hardware vendors get "inspired" by that interface as well.

> 
>>    5. Multichipset capabilities, right now a commercial PC104 board with
>>>    two devices is used. The on board CPU is a SBC VIA C3 1GHz processor
>>>    softwared with the stack xenomai-2.3,1/vanilla-2.6.20-15/Adeos-
>>>    ipipe-1.7-03
>>>    6. board monitoring through the /proc file system entry
>>>    7. Local Data Transfers controlled with RT-alarms
>> Another violation - but this one is easily avoidable with RTDM timers
>> that come with API revision 6 (upcoming Xenomai 2.4).
> 
> Same as above
> 
> 
>>    8. Virtual support to check applications/driver usage/design, right
>>>    now only the chipset is virtualised, but plans to have network
>> transactions
>>>    are on going
>>>    9. ISR hardware optimizations focused on the network readout to
>>>    gurantee low latencies
>> Any numbers?
> 
> Right now i am on holidays and i can't not run any scope test, but i
> remember that the worst case was around to 100usec to fully read the mailbox
> plenty of 8 bytes. It is fully coupled to the hardware ISA mapping, every
> chipset register read cycle requires three io operations to write the
> addressed register, perform a dummy read  and the valid read one. This
> killer takes 500nsec to each chipset select activation, but the most burner
> is 1000nsec between each in,out IO address space instruction so around
> 4usec/sucked byte,
> We have implementing the chipset clearing and data sucking with ~ 20 io
> cycles , so the numbers fit quite with the xenomai-i386 latencies.

So the programming model of the driver is actually not the core issue
(taking aside true hardware acceleration where available).

> 
>>    10. Easy porting to other i82527 based on boards
>>>    11. Full transmission operation handling the 16 message object set
>>>
>>> We have in plan also
>>>
>>>    1. Capabilities to filtering/masking the incoming flow at the driver
>>>    stage allowing that the same context, using the "xenomai
>> nomenclature" feed
>>>    specific threads using some kind of binding/configuration process.
>> This is
>>>    an open issue cause i don't have a clear approach to follow..
>>>    2. can-festival coupling
>> Look, with Socket-CAN, you would now already have CAN-Festival binding. :)
> 
> Yes, i know it's clear motivation to use it ;-)
> 
> 
>> But maybe this library scenario can be used to explain why you need to
>> do things in a special way and what you can gain that way. Looking
>> forward!
> 
> From my point of view the RTDM layout is ideal to perform linux porting
> The fact related on with the missed chipset support and the gained
> experience developing standard linux drivers using this chipset biased my
> approach a lot. For sure, that if the chipset support were provided in time
> we will re-consider the stuff to re-usage/patch the official stack if the
> latencies are similar..

You will definitely be welcome to contribute!

Jan


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

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[juanba romance]

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

On 8/13/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> juanba romance wrote:
> > On 8/13/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >> juanba romance wrote:
> >>> Hello, all,
> >>> I am currently developing a RTDM/xenomai driver for the CANbus chipset
>
> >> 82527
> >>> that i think it could have some interest
> >>> it has the next features:
> >> Thanks for moving our private thread here! See, now we know that
> >> Wolfgang is already working on 82527 support for RT-Socket-CAN -
> >> something I wasn't aware of as well.
> >>
> >>>    1. Specific management for the remote frames CANbus feasibility, it
> >>>    couple the real-time data bus flow with a user software feedback to
>
> >>>    handshake remote frames and update mailbox callback for the
> >> auto-replied
> >>>    messages
> >> Mind to elaborate what you precisely gain here compared to "open-coded"
>
> >> designs (loop closed over the application)? Can you quantify the
> >> improvements?
> >
> >
> > After review your current user interface i can not understand how a RF
> cycle
> > flows through the user application
> > holding as much as possible the latency at the receiver side. Maybe it's
> my
> > own misunderstanding.
> > The point is one node requests an information to another one issuing a
> RF,
> > the CAN specification says that the RF receptor will handshake the cycle
>
> > issuing the corresponding DF, and right here is when/where i am fuzzy.
> We
> > use this capability using real time as much as possible only relying on
> the
> > CANbus network load, i mean we perform the RF handshake using the RF
> > receptor mailbox auto-reply capability, feedbacking the user software
> only
> > when the DF handshake is decoded at the network, this event will trigger
> the
> > user actions i.e. the message data update with the new local variables
> > state. This feature is requested through  the configuration stage, this
> kind
> > of information is labeled as "quick.ack" responses , cause are not
> related
> > with software at all. The RF requester has the guarantee  that the
> > information is sampled with any jitter software coupled. The typical
> > approach found in other stacks is labelled as "slow.ack", it avoids to
> > response the RF-request up to reach any software area (kernel/user
> spaces)
> > that explicitly issue the data-frame as usual, this is how can-festival
> > currently works.
>
> The point is that quite a few CAN controllers do not support this
> hardware-based RF reply. And as Socket-CAN aims at a _generic_ API, not
> the n-th Intel or MSCAN or whatever CAN stack, we had to define the
> basic interface without such special support first.

But that doesn't mean we would be unable to extend the profile with
> optional or, when required, software-emulated accelerations like for RTR
> handling.
>
Fully agree. One of the reason to write the driver was to use it as our
current applications require it
IMHO this feature is powerful a lot, an could be really nice to allow some
kind of service attached to this feature
i.e.  we have measure less than 250usec to suck the full package from a
remote CANbus node .
(all the numbers are referenced to 1Mbit bus rate, and assuming full
packages it means ~100bits )

That's what we're interested in: How may such an extension
> look like to exploit the hardware to its limits where available,
> _without_ giving up CAN application portability?

In the cases where not be available at chipset level, i think that the
quick.ack could be implemented at kernel space using a private mailbox where
the driver itself could perform the data exchange.
Our proposal use the configuration stage to assign this reserved objects and
the standard input interface is used to update the  message data.
The transmission overhead on such kind of objects is really fast, it's a
good argument to be driver embedded. I think that the documentation and the
examples that i am producing/building right now should illustrate the
stuff.
I don't see too much different between two approaches from the user API
point of view. IHMO it should be a fully driver issue

>
> > Both operations are included in the proposal.
> >
> >>    2. Transparent use to push/suck data from the driver using a common
> >>>    data format
> >>>    3. Capability to push a bunch of CANbus messages in a single system
>
> >>>    call. The bunch is copied to a kernel domain ring buffer to
> guarantee
> >> low
> >>>    latencies at the user side. A specific kernel thread  sucks the
> ring
> >> pushing
> >>>    the user request into the chipset
> >> That was discussed before in the context of Socket-CAN. My feeling is
> >> that it /could/ be useful in case you have to issue longer streams of
> >> CAN frames at high rates, and specifically if your CAN hardware can
> >> handle these streams autonomously. Is the 82527 able to do so?
> >>
> >> In any case, this would complicate the existing stack and driver and
> >> would first require careful evaluation of the achievable improvement
> >> (lower latency, lower system load?).
> >
> > The i82527 has 15 mailboxes with fixed priority, the lowest one is
> hardwared
> > to the RX operation. So theoretically  you can pipeline up to 14 TX
> > messages. When the stuff is full, we are labeled it as
> a  "pileup"  because
> > the hardware handler has to wait up to get some free one, this operation
> is
> > performed in our case through the either the mailbox-alarm mechanism or
> the
> > ISR transmission side . I have mention the "low latency" term, cause i
> have
> > decoupled the loopback-tx feedback from the ISR to a kernel RT
> thread/task
> > so the ISR only cleans/stops the mailbox software/hardware resources.
> The
>
> So you already have task context here (+ the challenge to manage
> priorities). Did you measure the difference in latencies between kernel
> and user space on your platform?

The snapshots were taken from the first ISR instruction up to reach the last
one. I estimate 10~20usec from the 8259 hit up to reach the service, so the
100 usec are required to perform the ISR task including the RT message queue
management. Uhmm i need to measure/estimate the context switch up to get the
xeomai thread


> If your hardware is slow (ISA...)
> and/or the platform is fast, that doesn't make much difference anymore,
> thus you are already half way to use the standard API, maybe with some
> CAN library for the boring routine work.

Likely


> > user call is only blocked the time required to push the message bunch
> into
> > the transmission ring. The physical user transmission is performed in
> > open-loop if no error/alarm is sampled..
> >
> >
> >>>    4. Driver readout using a native RT message queue where the control
> >>>    and data flow is published
> >> And this way you make your driver unportable, e.g. to move it over the
> >> RTDM layer Wolfgang wrote for the -rt kernel. RTDM drivers are ought to
>
> >> use RTDM services (or Linux ones), not other skins. If a generally
> >> useful service is lacking, we need to think about adding it - to RTDM.
> >>
> > Fully deliberated. this is one the reason cause i labelled the stuff as
> > "xenomai-RTDM" instead of "RTDM". I assume that the native layer is
> > available to be used at all. My first intention is not to build
> something
> > fully compliance with the RTDM layer, this is a second step from my
> point of
> > view. I need ASAP the driver ready to be used in a Xenomai
> framework  where
> > our applications are running..
>
> Yeah, the old problem: "But we need it immediately!" However, keep in
> mind: CAN controllers come and go (just as SoC come an go), the
> programming model should be there to stay. And using a standard API,
> maybe tuning it in the direction you need, raises the chances that
> future hardware vendors get "inspired" by that interface as well.

Yes fully agree, but to be honest, at our company we have already checked
different strategies to control the stuff and the experiment always outputs
the Murphy's law
I hope someday your sentence be a real fact, it will save lot of headaches

>
> >>    5. Multichipset capabilities, right now a commercial PC104 board
> with
> >>>    two devices is used. The on board CPU is a SBC VIA C3 1GHz
> processor
> >>>    softwared with the stack xenomai-2.3,1/vanilla-2.6.20-15/Adeos-
> >>>    ipipe-1.7-03
> >>>    6. board monitoring through the /proc file system entry
> >>>    7. Local Data Transfers controlled with RT-alarms
> >> Another violation - but this one is easily avoidable with RTDM timers
> >> that come with API revision 6 (upcoming Xenomai 2.4).
> >
> > Same as above
> >
> >
> >>    8. Virtual support to check applications/driver usage/design, right
> >>>    now only the chipset is virtualised, but plans to have network
> >> transactions
> >>>    are on going
> >>>    9. ISR hardware optimizations focused on the network readout to
> >>>    gurantee low latencies
> >> Any numbers?
> >
> > Right now i am on holidays and i can't not run any scope test, but i
> > remember that the worst case was around to 100usec to fully read the
> mailbox
> > plenty of 8 bytes. It is fully coupled to the hardware ISA mapping,
> every
> > chipset register read cycle requires three io operations to write the
> > addressed register, perform a dummy read  and the valid read one. This
> > killer takes 500nsec to each chipset select activation, but the most
> burner
> > is 1000nsec between each in,out IO address space instruction so around
> > 4usec/sucked byte,
> > We have implementing the chipset clearing and data sucking with ~ 20 io
> > cycles , so the numbers fit quite with the xenomai-i386 latencies.
>


So the programming model of the driver is actually not the core issue
> (taking aside true hardware acceleration where available).

Yes that's it. You got it


> >
> >>    10. Easy porting to other i82527 based on boards
> >>>    11. Full transmission operation handling the 16 message object set
> >>>
> >>> We have in plan also
> >>>
> >>>    1. Capabilities to filtering/masking the incoming flow at the
> driver
> >>>    stage allowing that the same context, using the "xenomai
> >> nomenclature" feed
> >>>    specific threads using some kind of binding/configuration process.
> >> This is
> >>>    an open issue cause i don't have a clear approach to follow..
> >>>    2. can-festival coupling
> >> Look, with Socket-CAN, you would now already have CAN-Festival binding.
> :)
> >
> > Yes, i know it's clear motivation to use it ;-)
> >
> >
> >> But maybe this library scenario can be used to explain why you need to
> >> do things in a special way and what you can gain that way. Looking
> >> forward!
> >
> > From my point of view the RTDM layout is ideal to perform linux porting
> > The fact related on with the missed chipset support and the gained
> > experience developing standard linux drivers using this chipset biased
> my
> > approach a lot. For sure, that if the chipset support were provided in
> time
> > we will re-consider the stuff to re-usage/patch the official stack if
> the
> > latencies are similar..
>
> You will definitely be welcome to contribute!

Uhmm i would like provide some specific numbers about latencies soon..


> Jan
>

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

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[Wolfgang Grandegger]

juanba romance wrote:
> On 8/13/07, *Jan Kiszka* <jan.kiszka@domain.hid <mailto:jan.kiszka@domain.hid>> 
> wrote:
> 
>     juanba romance wrote:
[...]
      That was discussed before in the context of Socket-CAN. My feeling is
>     that it /could/ be useful in case you have to issue longer streams of
>     CAN frames at high rates, and specifically if your CAN hardware can
>     handle these streams autonomously. Is the 82527 able to do so?
> 
>     In any case, this would complicate the existing stack and driver and
>     would first require careful evaluation of the achievable improvement
>     (lower latency, lower system load?). 
> 
> The i82527 has 15 mailboxes with fixed priority, the lowest one is 
> hardwared to the RX operation. So theoretically  you can pipeline up to 
> 14 TX messages. When the stuff is full, we are labeled it as a  
> "pileup"  because the hardware handler has to wait up to get some free 
> one, this operation is performed in our case through the either the 
> mailbox-alarm mechanism or the ISR transmission side . I have mention 

To be more precise, you have to wait that the object with the lowest 
priority, #14 has sent it's message, otherwise messages will be sent 
out-of-order.

> the "low latency" term, cause i have decoupled the loopback-tx feedback 
> from the ISR to a kernel RT thread/task so the ISR only cleans/stops the 
> mailbox software/hardware resources. The user call is only blocked the 
> time required to push the message bunch into the transmission ring. The 
> physical user transmission is performed in open-loop if no error/alarm 
> is sampled..   

Note that in RT-Socket-CAN messages are not queued in software nor in 
hardware for the sake of real-time. Just one message object will be used 
for sending. I also doubt, that there is a notable performance benefit 
from sophisticated TX queuing.

Wolfgang.

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[juanba romance]

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

On 8/13/07, Wolfgang Grandegger <wg@domain.hid> wrote:
>
> juanba romance wrote:
> > On 8/13/07, *Jan Kiszka* <jan.kiszka@domain.hid <mailto:jan.kiszka@domain.hid>>
> > wrote:
> >
> >     juanba romance wrote:
> [...]
>       That was discussed before in the context of Socket-CAN. My feeling
> is
> >     that it /could/ be useful in case you have to issue longer streams
> of
> >     CAN frames at high rates, and specifically if your CAN hardware can
> >     handle these streams autonomously. Is the 82527 able to do so?
> >
> >     In any case, this would complicate the existing stack and driver and
> >     would first require careful evaluation of the achievable improvement
> >     (lower latency, lower system load?).
> >
> > The i82527 has 15 mailboxes with fixed priority, the lowest one is
> > hardwared to the RX operation. So theoretically  you can pipeline up to
> > 14 TX messages. When the stuff is full, we are labeled it as a
> > "pileup"  because the hardware handler has to wait up to get some free
> > one, this operation is performed in our case through the either the
> > mailbox-alarm mechanism or the ISR transmission side . I have mention
>
> To be more precise, you have to wait that the object with the lowest
> priority, #14 has sent it's message, otherwise messages will be sent
> out-of-order.

Obviously if the pipe is full and the last activated one was the #14; We
have not take in care in a first approach the message identifier priority,
so the bunch sucked from the user ring is downloaded sequentially on the
free mailboxes starting from the #0 up to get the #14. A better approach to
be implemented in the TX thread would be to sample the current
free/available mailboxes, suck the ring and perform over there some ordering
before be attached to the chipset.  In fact, the mailboxes pool is shared
with the static message user map which is always allocated in the top area,
so the it's ACK is guaranteed at least for the auto-replier ones.

Another issue is the fact that to block a CANbus network transaction(so the
full pipe) any node should provide the ACK bit which is OR-wired. This
situation means that all the network devices have the RX line broken. This
unusual cause means likely a fully broken system, anyway if it is sampled I
think that the case must be traced without the hardware feedback; the i82527
has a 96 try mechanism to provide a status interrupt to monitor the fault.
This counter may be too later, using 1 Mbit bus rate, take the worst case in
terms of message size which is ~100bits, 100usec/message *96 tries, then up
to ~9.6ms be the pipe blocked, this is traced in our case through the alarm
mechanism but we have decreased the timeout up to 2msec, without have to
wait any IRQ flow. The ISR is also coded to have in care about this
situation but theoretically the alarm should be triggered before.. Of course
decreasing the bus speed the stuff get worse..


> > the "low latency" term, cause i have decoupled the loopback-tx feedback
> > from the ISR to a kernel RT thread/task so the ISR only cleans/stops the
> > mailbox software/hardware resources. The user call is only blocked the
> > time required to push the message bunch into the transmission ring. The
> > physical user transmission is performed in open-loop if no error/alarm
> > is sampled..
>
> Note that in RT-Socket-CAN messages are not queued in software nor in
> hardware for the sake of real-time. Just one message object will be used
> for sending. I also doubt, that there is a notable performance benefit
> from sophisticated TX queuing.
>
> Wolfgang.
>
I will provide some measures related on

Juanba

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

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[Wolfgang Grandegger]

juanba romance wrote:
[...]
> After review your current user interface i can not understand how a RF 
> cycle flows through the user application
> holding as much as possible the latency at the receiver side. Maybe it's 
> my own misunderstanding.

Your just send a "remote transmission request" message and receive the 
response as a normal message.

> The point is one node requests an information to another one issuing a 
> RF, the CAN specification says that the RF receptor will handshake the 
> cycle issuing the corresponding DF, and right here is when/where i am 
> fuzzy. We use this capability using real time as much as possible only 
> relying on the CANbus network load, i mean we perform the RF handshake 
> using the RF receptor mailbox auto-reply capability, feedbacking the 
> user software only when the DF handshake is decoded at the network, this 
> event will trigger the user actions i.e. the message data update with 
> the new local variables state. This feature is requested through  the 
> configuration stage, this kind of information is labeled as "quick.ack" 
> responses , cause are not related with software at all. The RF requester 
> has the guarantee  that the information is sampled with any jitter 
> software coupled. The typical approach found in other stacks is labelled 
> as " slow.ack", it avoids to response the RF-request up to reach any 
> software area (kernel/user spaces) that explicitly issue the data-frame 
> as usual, this is how can-festival currently works.

Can you point me to the code in CAN-Festival supporting directly that 
feature of the i82527?

RTR message handling of the i82527 is very special and I do not know any 
other (non-compatible) CAN controller doing it in a similar way. The 
feature you like so much makes it actually a nightmare to support the 
i82527 in a generic framework (like RT-Socket-CAN or Socket-CAN), 
especially receiving RTR messages by justs using send and receive. 
Anyhow, supporting the RTR auto-reply capability in (RT-)Socket-CAN is 
feasible and would be a "nice to have". It could be supported by a 
generic RTR update object. Would be nice, if you bring-up the idea on 
the Socket-CAN mailing list to share it between other CAN experts with 
the goal to define an CAN-API extension.

Wolfgang.

Re: [Xenomai-core] RTDM 82527 Xenomai driver

[juanba romance]

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

On 8/13/07, Wolfgang Grandegger <wg@domain.hid> wrote:
>
> juanba romance wrote:
> [...]
> > After review your current user interface i can not understand how a RF
> > cycle flows through the user application
> > holding as much as possible the latency at the receiver side. Maybe it's
> > my own misunderstanding.
>
> Your just send a "remote transmission request" message and receive the
> response as a normal message.

I was pointing to the receiver node software. The requester node flow seems
quite standard/clear.


> > The point is one node requests an information to another one issuing a
> > RF, the CAN specification says that the RF receptor will handshake the
> > cycle issuing the corresponding DF, and right here is when/where i am
> > fuzzy. We use this capability using real time as much as possible only
> > relying on the CANbus network load, i mean we perform the RF handshake
> > using the RF receptor mailbox auto-reply capability, feedbacking the
> > user software only when the DF handshake is decoded at the network, this
> > event will trigger the user actions i.e. the message data update with
> > the new local variables state. This feature is requested through  the
> > configuration stage, this kind of information is labeled as "quick.ack"
> > responses , cause are not related with software at all. The RF requester
> > has the guarantee  that the information is sampled with any jitter
> > software coupled. The typical approach found in other stacks is labelled
> > as " slow.ack", it avoids to response the RF-request up to reach any
> > software area (kernel/user spaces) that explicitly issue the data-frame
> > as usual, this is how can-festival currently works.
>
> Can you point me to the code in CAN-Festival supporting directly that
> feature of the i82527?

It doesn't.  All the incoming RTR flow must be handshaked by the user space,
i.e. take a look on lifegrd.c at the src directory entry and review the
first filter based on the .rtr message struct field located on the symbol
proceedNODE_GUARD(CO_Data* d, Message* m ), the symbol context drive me to
think in a "soft" ack..
But the point is:
should one remove this powerful issue from the design/implementation cause
one specific user library doesn't provide the feature ?
>From my point of view this restriction is too much.
The consider the can-festival stuff is a facility to attach the CANopen
specification nothing else, we already have applications that smoothly run
using the raw CAN bus 2.0 specification. May be other CANopen stack be
available sometime, maybe we write our own, maybe we remove the CANopen
layer, i mean, nobody knows..
In fact in a first approach, we plan that the can-festival related driver
layer not use the high speed ACK. We will measure the latencies using the
layer as it is and then will take a final decision..

RTR message handling of the i82527 is very special and I do not know any
> other (non-compatible) CAN controller doing it in a similar way. The
> feature you like so much makes it actually a nightmare to support the
> i82527 in a generic framework (like RT-Socket-CAN or Socket-CAN),
> especially receiving RTR messages by justs using send and receive.

Fully agree. We have thought a lot about this feature at our company before
start this stuff long, long, long time ago. But the stuff was solved and
fixed and it has been part of our functional specifications along this time,
we still would like to hold it..


> Anyhow, supporting the RTR auto-reply capability in (RT-)Socket-CAN is
> feasible and would be a "nice to have". It could be supported by a
> generic RTR update object. Would be nice, if you bring-up the idea on
> the Socket-CAN mailing list to share it between other CAN experts with
> the goal to define an CAN-API extension.
>
Fully agree. I think that the driver documentation will help a lot, uhmm let
me do some pictures and write some formal document about and you will have
a  a better point of view..


> Wolfgang.
>

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