Re: [Xenomai-core] RTDM 82527 Xenomai driver

[Wolfgang Grandegger <wg@domain.hid>]

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.