Kurt Van Dijck wrote: > On Mon, Feb 08, 2010 at 10:12:12AM +0100, Wolfgang Grandegger wrote: >> Kurt Van Dijck wrote: >>> On Sun, Feb 07, 2010 at 06:25:39PM +0100, Wolfgang Grandegger wrote: >>>> christian pellegrin wrote: >>>>> On Sun, Feb 7, 2010 at 6:05 PM, Wolfgang Grandegger <[email protected]> >>>>> wrote: >>>>>> christian pellegrin wrote: >>>>>> increase). Can you confirm that? Normal state changes are interrupt >>>>>> driver. So, if the hardware does not trigger an interrupt, we have a >>>>>> problem. >>>>> On the mcp251x we get an interrupt when we get back from error-warning >>>>> to error-active but I don't know if we have to send some kind of error >>>>> frame in this case. Now nothing is sent, I was worried if this is >>>>> right. >>>> Good question. I think we should send an error message for any state >>>> change also for passive->warning->active, which we currently do not >>>> handle by software. We speak about controller *problems* and there is >>>> currently no CAN_ERR_CRTL_ACTIVE. Well, that's another weak point :-(. >>>> This needs some more thoughts/discussion. >>> We had some discussion lately, but having an interrupt (and some message >>> to userspace) seems like a non-optional requirement to me. >> I don't understand. What is "non-optional"? Currently we just report >> controller *problems*, meaning state changes >> active->warning->passive->bus-off. > sorry for the confusion. > I meant: having an 'bus state change' interrupt seems a requirement to > me (therefore : non-optional, but it depends on CAN chip capabilities). > This (bus-state-change interrupt) is, IMO, more important than the bus > error interrupts.
Of course. I'm not speaking about the bus-error interrupts here. The discussion drifted away and the subject is not appropriate anymore :-(. The question I rised is if we should report state changes passive->warning->active to the app as well. > Therefore, I think that it may not be very good not sending anything > on the 'error-warning to error-active interrupt', as was mentioned > above. OK. > Implementing bus-error interrupts, but poor bus state change interrupts > requires the user to enable bus-error interrupts, and tracking the bus > state itself. I do not like that (But I did no mcp251x work either). The bus-error messages should *not* be used for that purpose. They are mainly useful to get more information on the cause of the problem (error type, etc.). As the mcp251x does not provide enhanced information, I do not regard the bus-error messages for that processor as really useful. > I think we agree, but I didn't express my opinion very clear :-) Should be cleared now. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
