From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46C0368A.2080207@domain.hid> Date: Mon, 13 Aug 2007 12:46:34 +0200 From: Wolfgang Grandegger MIME-Version: 1.0 References: <46C01909.5020308@domain.hid> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] RTDM 82527 Xenomai driver List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: juanba romance Cc: Jan Kiszka , xenomai@xenomai.org juanba romance wrote: > On 8/13/07, *Jan Kiszka* > > 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.