>
> What I gather is that allowing the CAN-RX interrupt handler to be
> interruptible could lead to undesirably long delays while reading out
> the registers which would either result in buffer overflow or/and,
> changed register content before the previously read values are
> written?
The discussion was a little bit theoretical. This would only apply if we
shift some code from the handler to a bottom-half thread, which would then
be interruptible by a higher prio task. But I'm not planning to do this.
;-)
Ah. :(
>
> If it is also not possible to optimize the code further then IMHO we
> are looking at a fundamental hardware constraint.
Paul already posted some calculations which make the situation rather
clear.
I thought so too.
>
> If the latter is true then to be of any use in a RT environment, it
> must be possible to retain more control over the message receiving in
> at least one respect. It must be possible to either block the CAN-RX
> interrupt or the reaction to it of the ISR. Obviously at the cost of
> loosing messages but in some cases (like mine) loosing messages is not
> that much of a problem. Having excessive latencies on the other hand
> is.
With every reception you get those "excessive" latencies on your hardware.
Which one will you choose to be suppressed? A rather difficult task, I
could imagine.
Is it? Perhaps I am being rather over optimistic but I am not
interested in position readings coming in at the end of the 1ms
period. If I could block the RX interrupt for the last 0.2ms of my
task the chances are that I would have perfectly acceptable readings.
>
> What would probably work in my case is to allow the Rx ISR to be
> interrupted by the rt tasks in such a manner that when the ISR is
> interrupted the ISR is exited with no values written to the the
> sockets.
This requires a conversion of the driver which is not done in five
minutes. And whether this is the way to go remains yet questionable.
I feel that if we are facing a fundamental hardware constraint and
making the ISR interruptible is "impossible" there are not many
alternatives. I don't deny that the suggestion is a serious compromise
but there are applications where it can be used. Mine possibly being
one of them.
Regards,
Roland
--
Sebastian
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
