On Tue, Feb 2, 2010 at 11:00 AM, Wolfgang Grandegger <[email protected]> wrote: > Hi Christian, >
Hi, > > The MERR should not come when the device is in bus-off. Nevertheless, it yes, sorry it's in error-passive state! > space via error messages. For exactly that reason we do not disable bus > errors on other CAN controllers, like the SJA1000 or the AT91, even if > they may produce high load. But we may discuss some generic interface to > disable bus-errors somehow, maybe configurable via ctrlmode. What do you > think? The transition of CAN error states is handled by the ERR interrupt, the MERR means "message error" and is fired when a transmission or receptions leads to an error. The problems with this interrupt are: 1) it's impossible to know if it was a TX or RX error. 2) if the error is accounted (for example) to TX the user will see ton's of TX errors even if he sent just one packet (this happens in error-passive mode for example) which could be confusing. 3) I guess that microchip has a specific use of this interrupt in mind which explains it's drawbacks. From the data sheet: "7.4 Message Error Interrupt When an error occurs during transmission or reception of a message the message error flag (CAN- INTF.MERRF) will be set and, if the CANINTE.MERRE bit is set, an interrupt will be generated on the INT pin. This is intended to be used to facilitate baud rate deter- mination when used in conjunction with listen-only mode." I think that a much more useful information to somehow export to the user are the TEC and REC counters. I checked other CAN drivers but no one seems to do this. Anyway let me know what do you think so I could prepere the final patch now that OSM problems where sorted out. -- 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
