Wolfgang Grandegger wrote: >>> The problem is to define what degree of error-related IRQ load is >>> generally acceptable. We surely can't do this, so we have to document >>> the effect /at least/ and help the users to check it on their own - or >>> we have to avoid it / make it insignificant compared to normal CAN >>> operation (I'm still in favour of this path). >> >> We speak about a pathological situation and therefore I do not share >> your concerns. When there are electrical problems or even the cable is >> not connected, we do have an abnormal mode of operation and CAN >> related real-time is broken anyhow. The bus error messages are then >> useful for analyzing the problem. The effect of the bus error
I do understand, and that's why I was looking for some solution that rate-controls such IRQs deterministically, but doesn't switch them off altogether. >> interrupts on non-CAN related latencies is another issue but I think >> it's not that critical either (handling a bus error just requires the >> reading of 2 SJA1000 registers). But I agree, a more detailed analysis >> of "bus error flooding" would help to understand the impact on the >> real-time behavior. > > And also be aware, that heavy CAN traffic can cause similar latencies as > well and when there is more than one CAN controller, they can accumulate > (as I have observed with my PCAN dongle tests). Here a IRQ service task Well, this argumentation doesn't help if some concrete CAN bus was specified to _not_ deliver such high traffic. > or threaded IRQs would help. Maybe this is the right way to go. Again: threaded IRQs are no magic bullet. First of all, they add latencies, specifically on low-end. And they can only help if IRQ priorities can actually be lowered appropriately (or if you apply round-robin or a similar CPU bandwidth policy). Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
