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