juanba romance wrote:
> On 8/13/07, *Jan Kiszka* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> 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
> 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.
Xenomai-core mailing list