christian pellegrin wrote: > On Mon, Feb 1, 2010 at 8:19 AM, christian pellegrin <[email protected]> > wrote: >> even with the MERR handling (but can you confirm this?). The first >> thing that comes to my mind is using the standard netdev tx watchdog >> to restart it, but I don't know it's an elegant solution. > > After a second thought and after reading the chapter about one shot > mode on a CAN book I've understood that this is mode is all about real > time behavior. So I think it's better to give a precise control to the > user of write syscall on when the packets can be send. So in > CAN_ONE_SHOT_MODE frame transmit returns error until the TX buffer is > free. There is no netif queue flow control, so a write in a busy loop > can happily overload the system. Unfortunately I don't see any other > way to get a feedback in one shot mode after a lost arbitration (the > basic problem is that the mcp2515 doesn't have a "tx buffer free" > interrupt but a "frame txed" one) after studying the data sheet of the > mcp can controller (message error could be trapped by MERR interrupt > but lost of arbitration cannot). Let me know what you think about the > patch below. Another problem is that right now I don't have a mcp2515, > so Paul may you kindly test it? TIA!
In real-time, transfer errors are not allowed to happen, otherwise deterministic behavior can not be guaranteed. I actually hesitate to add too much extra code for this feature. Note also, that the network stack is not hard real-time anyway and the "-rt" patch does only help partially. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
