On Wed, Feb 3, 2010 at 3:11 AM, Marc Kleine-Budde <[email protected]> wrote: > Hello >
Hi, > wendy liang wrote: >> I am writing a CAN driver using the socketCAN framework. >> When there is an ACK error, the CAN hardware keeps resending the packet and >> keeps raising interrupts, which introduce too much overhead to the >> processor. > > This is a...IMHO..."weak" point of our current driver design. We don't > disable error interrupts even if they are coming at an incredible high > rate. Maybe it's time to discuss the problem again. > Which controller are we speaking of? I have some experience with the mcp251x. On this there are 2 kinds of interrupts: one that informs just about the transition of CAN error (error-active, error-warning, error-passive and bus-off) states and another that informs of every single error in message tx/rx. The first one is absolutely easy to handle, but the second one is an overkill in error-passive state (for example if someone just opens the bus while is a transmission pending which is automatically retried), especially now that the interrupt thread was moved to a threaded interrupt (and so it has a RT priority meaning it gives little chance to run to user-space space SCHED_OTHER processes to act upon the error state). I think we should try to make to most of internal accounting of errors which is required from CAN controller by somehow exporting TEC and REC counters. -- Christian Pellegrin, see http://www.evolware.org/chri/ "Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room." _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
