juanba romance wrote: > On 8/13/07, *Jan Kiszka* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > 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. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
