On Thu, Feb 04, 2010 at 07:13:46PM +0100, Wolfgang Grandegger wrote: > Marc Kleine-Budde wrote: > > Kurt Van Dijck wrote: > >>> I think a "pure" ratelimit isn't a good choice. From my point of view > >>> (with no CAN background) we should limit only if the errors are > >>> consecutive, a successfully transmitted or received CAN frame should > >>> reset our limiter. > > > >> Or a bus-off indication. > > > > ACK > > ACK. > > >> Resetting the rate-limit at successfull tx or rx requires disabling > >> _only_ the bus-error interrupt and not the TX & RX interrupt, > >> and is therefore chip specific? > > > > Yes, of course. We just want to limit the error interrupts but not the > > active/passive/warning/busoff and of course the rx/tx interrupts. > > > > On the at91_can you can individually mask the errors. IIRC the sja1000 > > can do likewise. > > Normally bus-error interrupts have a dedicated bit in the interrupt > enable register. This approach is, as I expected, complex and rather > tricky and delicate. I still prefer the simple solution of disabling the > bus error interrupts globally. I believe, that most people/apps do not > check bus-errors at all. Other opinions? It would be nice to hear real > CAN users and experts. I use CAN for ~11 years (rather much, we do automotive). I never enabled the bus-error interrupts anywhere embedded. To research odd behaviour, the error counters were helpfull, and oscilloscope devices on the bus. Even a normal oscilloscope nowadays can catch error frames, given the baud rate.
That is because on a production system (automobile or such), the bus should not have bus-errors at all, and if it does (we live in the real world), then that's a problem we can't influence with software (except for disabling CAN). Of course, during develpment I see more problems, but I make much more mistakes. That's when debugging was invented. When a single (or few) bus-error is encountered, then you can/should ignore it. When a bunch of bus-errors is encountered, the chip will go into error-passive(I tend to confuse the names :-) ) and in bus-off. This triggers a bus-state change, which is interesting to alert an application that things are getting bad. so, on embedded device, I would never activate the bus-error interrupts. My software is capable of dealing with CAN bus status as a binary value: "it's gone" or "it's not gone" Anything in between is a test facility, and not production level. I see some uses on a laptop. Then, you could investigate CAN bus quality on a real machine/CAN bus. So, enable/disable globally is good enough. I my system gets loaded in that situation, yep, so be it. I don't do that every week :-). I only need it when I didn't bring the oscilloscope. That's my opinion. > > Wolfgang. Kurt _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
