Oliver Hartkopp wrote: > christian pellegrin wrote: >> On Fri, Feb 5, 2010 at 10:05 AM, Kurt Van Dijck <[email protected]> >> wrote: >> >>> I never enabled the bus-error interrupts anywhere embedded. >>> To research odd behaviour, the error counters were helpfull, >> I like this idea much. I speak from a point of view of meanness ;-) : >> we have paid the chip manufacturer for the REC and TEC counters that >> are cleverly incremented and decremented (AFAIK it's more likely they >> are incremented that decremented, so there is always a window in which >> the user space application can catch an increase in them even if not >> polling at an excessive rate) by the controller itself so they could >> be easily exported to user space. Perhaps all we need is a function >> for this in can_priv such do_get_err_counters. Even better if these >> counters are exported via sysfs so the function above is guaranteed to >> be called in non-atomic context. >> > > Trying to summarize these points, what about this: > > 1. We disable bus-error interrupts by default
Fine for me, even if that changes the current behavior. > 2. They can be enabled via netlink Yep. > 3. Once they are enabled we send the (unified) rx/tx error counters inside the > currently reserved bytes of the CAN error frame to the userspace. The problem is that some CAN controllers do not allow to read these counters while it's active. But in general we could add the rx/txerr to any error message, if possible. The information in the error message is hardware dependent anyway. > Would this meet the requirements in production-use and development-use ?? I leave it up to the real users. It's obvious that bus-error inspection is most useful for analyzing hardware problems during the development and testing phase. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
