[Xenomai-help] rtcan driver. rtcan_sja_interrupt made interruptible

[Xenomai-help] rtcan driver. rtcan_sja_interrupt made interruptible

[Roland Tollenaar]

Hi,

The following probably relates to the functioning of the sja1000 chip. I
cannot see how it can NOT be possible for the chip to function properly
without also having the ability to be read by a fully interruptible ISR.

Could below just be clarified for me please?

When the 14 registers of the sja1000 chip are being read, I presume this
is a single CAN frame that is being recovered which will subsequently be
written to the message buffer of the sockets currently connected to the
device. I also presume that while the registers are being read new
incoming messages from the Bus will not be written into these registers
because this would possibly corrupt the frame that is currently being
extracted from the registers. i.e. if the ISR has read 7 of the 14
messages and a new message is now written into the registers the
resulting frame will be a mixture of two distinct received messages. To
prevent that happening I presume it must be possible to lock the
registers while the Rx-ISR is busy doing its reading of the 14
registers? Messages that arrive on the bus while the Rx-ISR is locking
the 14 registers will then either be discarded or sent again by the node
as a result of the sending node not receiving an acknowledge message?

The point of the above questions being that if it is possible to lock
the 14 registers there is no reason in my humble opinion (IMHO) that the
the Rx-ISR cannot be interrupted. Correct? Of course one wants to
minimize the delay to optimize bus traffic but such behaviour would
certainly improve Real-Time capabilities.

If the non-real-time driver functions as described above (locks the 14
registers and allows itself to be interrupted) it will be better for me
to use the non-real-time driver in a stand-alone non-real-time
application which reads the CAN bus and presents the data it receives to
the real-time application (or any other application for that matter) via
a mechanism of choice. E.g. in a file on RAM-Disk, a pipe etc. In short
this would be a CAN-server which, since it is a fully interruptible
normal process will allow my real-time applications to tick away
undisturbed.

Is the reasoning incorrect?


Having written the above I have just downloaded the datasheet of the
SJA1000 and it seems to confirm my above conjecture. Firstly there are
64 bytes of FIFO receive buffer 13 of which are presented as a window
and are probably the ones referred to by Sebastian as the ones the ISR
reads out. This means that while reading out the window messages will
not get lost immediately.

Then on page 10 with a more detailed explanation on page 14 they talk
about a command register with a bit switch called the Release receive
Buffer (RRB) which seems to have the function of the lock I was talking
about.

Can you more knowledgeable people comment on this. It the above is
correct it could enormously improve the applicability of the driver for
  Real-Time control. Which I presume the driver is all about?


Regards,

Roland.

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[Wolfgang Grandegger]

Hi Roland,

hope most of your problems and questions with RT-Socket-CAN have already 
been solved or answered. I will not have the time to read carefully all 
your mails accumulated over the last week, sorry, it's too much traffic. 
Could you please briefly summarize the pending issues.

Thanks,

Wolfgang.

Roland Tollenaar wrote:
> Hi,
> 
> The following probably relates to the functioning of the sja1000 chip. I
> cannot see how it can NOT be possible for the chip to function properly
> without also having the ability to be read by a fully interruptible ISR.
> 
> Could below just be clarified for me please?
> 
> When the 14 registers of the sja1000 chip are being read, I presume this
> is a single CAN frame that is being recovered which will subsequently be
> written to the message buffer of the sockets currently connected to the
> device. I also presume that while the registers are being read new
> incoming messages from the Bus will not be written into these registers
> because this would possibly corrupt the frame that is currently being
> extracted from the registers. i.e. if the ISR has read 7 of the 14
> messages and a new message is now written into the registers the
> resulting frame will be a mixture of two distinct received messages. To
> prevent that happening I presume it must be possible to lock the
> registers while the Rx-ISR is busy doing its reading of the 14
> registers? Messages that arrive on the bus while the Rx-ISR is locking
> the 14 registers will then either be discarded or sent again by the node
> as a result of the sending node not receiving an acknowledge message?
> 
> The point of the above questions being that if it is possible to lock
> the 14 registers there is no reason in my humble opinion (IMHO) that the
> the Rx-ISR cannot be interrupted. Correct? Of course one wants to
> minimize the delay to optimize bus traffic but such behaviour would
> certainly improve Real-Time capabilities.
> 
> If the non-real-time driver functions as described above (locks the 14
> registers and allows itself to be interrupted) it will be better for me
> to use the non-real-time driver in a stand-alone non-real-time
> application which reads the CAN bus and presents the data it receives to
> the real-time application (or any other application for that matter) via
> a mechanism of choice. E.g. in a file on RAM-Disk, a pipe etc. In short
> this would be a CAN-server which, since it is a fully interruptible
> normal process will allow my real-time applications to tick away
> undisturbed.
> 
> Is the reasoning incorrect?
> 
> 
> Having written the above I have just downloaded the datasheet of the
> SJA1000 and it seems to confirm my above conjecture. Firstly there are
> 64 bytes of FIFO receive buffer 13 of which are presented as a window
> and are probably the ones referred to by Sebastian as the ones the ISR
> reads out. This means that while reading out the window messages will
> not get lost immediately.
> 
> Then on page 10 with a more detailed explanation on page 14 they talk
> about a command register with a bit switch called the Release receive
> Buffer (RRB) which seems to have the function of the lock I was talking
> about.
> 
> Can you more knowledgeable people comment on this. It the above is
> correct it could enormously improve the applicability of the driver for
>  Real-Time control. Which I presume the driver is all about?
> 
> 
> Regards,
> 
> Roland.
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 
> 

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[Wolfgang Grandegger]

Hi Roland,

in the meantime I browsed the interesting threads and I think I 
understood the problem with the PCAN dongle.

roland Tollenaar wrote:
> Hi Wolfgang,
> 
> 
> Just to bring you up to speed. You can skip most of the discussion.
> The problem is that the rtcan driver is breaking up the RT performance
> as soon as there are incoming messages on the bus. My rt task period
> times start to shift from the steady 1 repspectively 2 ms with
> latencies ranging between 20 and 40 micorseconds to latencies of about
> 200 microseconds when messages come in on the bus.
> 
> The problem we are all convinced is fairly certainly in the duration
> that it takes the interrupt handler rtcan_sja_interrupt to process the
> reading out of the messages and sending it to the socket.
> 
> The general consensus is that the hardware is slow i.e. parallel port.
> Some rule-of-thumb calculations confirm the 200 microseconds.
> Apparently PCI would be faster but even if it is 50% faster its still
> not really worth using. I cannot use the driver like this.

Access to the parallel port is slow, indeed. Looking to 
rtcan_peak_dng_epp_readreg tells me, that 6 inb/outb are required to 
read one register and if every inb/outb takes up 1-2 us ... puh ... the 
problem gets obvious. Nevertheless, this problem is special for the PCAN 
dongle and it seems to be a bad choice for RT-Socket-CAN. All other 
devices can read/write registers much faster. I'm going to do some more 
tests next week, also with other CAN hardware. Sebastian, have you 
realized similar latency problems with SJA1000 on the ISA bus (which is 
slow as well)?

> Don't stress I will circumvent the problem even if it means discarding
> CAN and using some other bus. So I am not really worried.

The question is how we can help you quickly.

> Taking the slow hardware as a given the only elegant solution IMHO is
> letting the Rx-ISR be interruptible by the rt-tasks so that those can
> at least complete their work and cycle with reasonable latency (50
> microseconds max, 25microsecond average)
> 
> Sebastian's opinion is that making it interruptible would be "the
> start of chaos". I am sure he knows more about this than I ever will
> but only out of academic interest before I sort this problem out
> outside the realm of rtcan, I would like to know why.

As I see it, the right solution would be to handle the CAN interrupts by 
a service task and disabled the corresponding IRQ till it's handled. I 
do not see a real problem with this method, but it requires substantial 
implementation effort. I think threaded IRQs are on Jan's to-do list for 
RTDM as well, but they will also not be available soon. And if the 
problem is just relevant for the parallel port, it might not be worth 
the effort.

> That is all there is to it at the moment.

OK, what other CAN hardware would be an option for you. Do you have PCI 
on your board?

> Hopefully below email will make more sense to you now.

It does, thanks for pointing us to the problem. So far I was not aware 
of it and I'm curious, how much the latency will be affected on my 
Laptop and PC.

Wolfgang.

> Regards,
> 
> Roland.
> 
> 
> 
> 
> 
> 
> 
> 
> On 3/10/07, Wolfgang Grandegger <wg@domain.hid> wrote:
>> Hi Roland,
>>
>> hope most of your problems and questions with RT-Socket-CAN have already
>> been solved or answered. I will not have the time to read carefully all
>> your mails accumulated over the last week, sorry, it's too much traffic.
>> Could you please briefly summarize the pending issues.
>>
>> Thanks,
>>
>> Wolfgang.
>>
>> Roland Tollenaar wrote:
>> > Hi,
>> >
>> > The following probably relates to the functioning of the sja1000 
>> chip. I
>> > cannot see how it can NOT be possible for the chip to function properly
>> > without also having the ability to be read by a fully interruptible 
>> ISR.
>> >
>> > Could below just be clarified for me please?
>> >
>> > When the 14 registers of the sja1000 chip are being read, I presume 
>> this
>> > is a single CAN frame that is being recovered which will 
>> subsequently be
>> > written to the message buffer of the sockets currently connected to the
>> > device. I also presume that while the registers are being read new
>> > incoming messages from the Bus will not be written into these registers
>> > because this would possibly corrupt the frame that is currently being
>> > extracted from the registers. i.e. if the ISR has read 7 of the 14
>> > messages and a new message is now written into the registers the
>> > resulting frame will be a mixture of two distinct received messages. To
>> > prevent that happening I presume it must be possible to lock the
>> > registers while the Rx-ISR is busy doing its reading of the 14
>> > registers? Messages that arrive on the bus while the Rx-ISR is locking
>> > the 14 registers will then either be discarded or sent again by the 
>> node
>> > as a result of the sending node not receiving an acknowledge message?
>> >
>> > The point of the above questions being that if it is possible to lock
>> > the 14 registers there is no reason in my humble opinion (IMHO) that 
>> the
>> > the Rx-ISR cannot be interrupted. Correct? Of course one wants to
>> > minimize the delay to optimize bus traffic but such behaviour would
>> > certainly improve Real-Time capabilities.
>> >
>> > If the non-real-time driver functions as described above (locks the 14
>> > registers and allows itself to be interrupted) it will be better for me
>> > to use the non-real-time driver in a stand-alone non-real-time
>> > application which reads the CAN bus and presents the data it 
>> receives to
>> > the real-time application (or any other application for that matter) 
>> via
>> > a mechanism of choice. E.g. in a file on RAM-Disk, a pipe etc. In short
>> > this would be a CAN-server which, since it is a fully interruptible
>> > normal process will allow my real-time applications to tick away
>> > undisturbed.
>> >
>> > Is the reasoning incorrect?
>> >
>> >
>> > Having written the above I have just downloaded the datasheet of the
>> > SJA1000 and it seems to confirm my above conjecture. Firstly there are
>> > 64 bytes of FIFO receive buffer 13 of which are presented as a window
>> > and are probably the ones referred to by Sebastian as the ones the ISR
>> > reads out. This means that while reading out the window messages will
>> > not get lost immediately.
>> >
>> > Then on page 10 with a more detailed explanation on page 14 they talk
>> > about a command register with a bit switch called the Release receive
>> > Buffer (RRB) which seems to have the function of the lock I was talking
>> > about.
>> >
>> > Can you more knowledgeable people comment on this. It the above is
>> > correct it could enormously improve the applicability of the driver for
>> >  Real-Time control. Which I presume the driver is all about?
>> >
>> >
>> > Regards,
>> >
>> > Roland.
>> >
>> >
>> > _______________________________________________
>> > Xenomai-help mailing list
>> > Xenomai-help@domain.hid
>> > https://mail.gna.org/listinfo/xenomai-help
>> >
>> >
>>
>>
> 
> 

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[roland Tollenaar]

>
> Access to the parallel port is slow, indeed. Looking to
> rtcan_peak_dng_epp_readreg tells me, that 6 inb/outb are required to
> read one register and if every inb/outb takes up 1-2 us ... puh ... the
> problem gets obvious. Nevertheless, this problem is special for the PCAN
> dongle and it seems to be a bad choice for RT-Socket-CAN.
That may be. I was not aware of this beforehand and on my laptop its
all I have besides USB and PCMCIA which are not supported RT. Besides,
if we look at this fundamentally the PCAN dongle is not TOO slow. 200
micoseconds leaves me 800 ms in a 1ms task to do work. That should be
ample. So the problem (in my case) lies more in the behavior of the
ISR, the fact that it reacts to all Rx interrupts and rigorously
blocks all other processes. If you consider how the structure i
suggested earlier with a non-real-time CAN-service utilizing a driver
with interruptible Rx-ISR could be used to sort out my problem the
fact that the slowness of the hardware is not -as such- the constraint
becomes evident. Of course I agree that if hardware is used that would
provide 20 us reading time the problem would be less visible. But for
someone who is interested in a 200us task-time that may be a problem
again so such a person or project would then also benefit from an
interruptible Rx-ISR. Which again emphasizes my feeling that faster
hardware diminishes the symptoms of the problem, not really the
problem.

All other
> devices can read/write registers much faster. I'm going to do some more
> tests next week, also with other CAN hardware. Sebastian, have you
> realized similar latency problems with SJA1000 on the ISA bus (which is
> slow as well)?
>
> > Don't stress I will circumvent the problem even if it means discarding
> > CAN and using some other bus. So I am not really worried.
>
> The question is how we can help you quickly.

Thanks.

>
> > Taking the slow hardware as a given the only elegant solution IMHO is
> > letting the Rx-ISR be interruptible by the rt-tasks so that those can
> > at least complete their work and cycle with reasonable latency (50
> > microseconds max, 25microsecond average)
> >
> > Sebastian's opinion is that making it interruptible would be "the
> > start of chaos". I am sure he knows more about this than I ever will
> > but only out of academic interest before I sort this problem out
> > outside the realm of rtcan, I would like to know why.
>
> As I see it, the right solution would be to handle the CAN interrupts by
> a service task and disabled the corresponding IRQ till it's handled.
Agreed.

I
> do not see a real problem with this method, but it requires substantial
> implementation effort. I think threaded IRQs are on Jan's to-do list for
> RTDM as well, but they will also not be available soon.
I fully understand. Not the part about a "threaded IRQ" though. What
does that entail exactly?

> And if the
> problem is just relevant for the parallel port, it might not be worth
> the effort.
This is for you people to say. I on the other hand get the impression
that this touches a defining issue of real-time drivers. Earlier I
posted the question of what distinguishes a "real-time" driver from a
normal device driver. The answer if i understood correctly was related
to the inability of the RT driver to be interrupted by any old non-rt
process which would render any rt-task to be non-rt. If on the other
hand the rt-driver is a rigid block that can not even be interrupted
by the rt-task itself AND the rt-driver responds to external IRQ
signals at its own discretion, well IMHO the rt-task is broken. Using
my case as an example, what we have is a situation where the CAN-bus
dictates what the CPU must pay attention to instead of the rt-task
being dominant in that respect.

Don't get me wrong, the above is not intended to convince you or
anyone else to sort out this issue in the driver. Its just a point of
view that I have and am interested in the opinions about. I will
settle for solving the problem with faster hardware with no second
thoughts. I do have two concerns on this I will mention later.


> OK, what other CAN hardware would be an option for you. Do you have PCI
> on your board?
If you discover that Peak PCI boards have acceptable impact on the
latency then I will continue to develop with the dongle on my laptop
but use PCI when I finally reach implementation for production stage.

>
> > Hopefully below email will make more sense to you now.
>
> It does, thanks for pointing us to the problem. So far I was not aware
> of it and I'm curious, how much the latency will be affected on my
> Laptop and PC.
If you don't experience the problem,  tell me what laptop you are
using. I am always on the lookout for a good excuse to get a new one.
:)

I mentioned earlier that I would revert to two concerns regarding the
faster hardware.

The first concern is that it was mentioned in one of the threads that
the clock rate of the sja1000 is rather low and reading out the sja
registers is not a fast exercise. If that is the case then a faster
interface (PCI) might not help all that much to suppress the symptoms.

The second concern is that even if I have a faster interface even if
it is substantially faster (added latency < 20 us) I still have a
potential problem. Consider the case where I have a few nodes on the
bus. Most of them are relatively quiet, one of them sends a position
every 1ms and everything is running fine. Now suddenly some nodes post
an exception of some sort (emergency something or other and send a
host of messages). With the current driver design, the driver will
respond to all the Rx interrupts and be so busy reading the messages
and posting them to the sockets that the control tasks will have no
time to a) handle the exception quickly and b) get through
position-control calculations on time.
The net effect could be that the machine responds to the exception
badly, closes down too late and the feedback control goes off-kilter
crashing the physical process. To exclude the possibility of a broken
machine i would need to get control over the send behavior of the
nodes in every possible exception to ensure that the bus never gets
too busy etc etc.

So I really feel your suggestion of working with an (interruptible)
service-task and blocking IRQ's is a better approach.

Regards,

Roland.


>
> Wolfgang.
>
> > Regards,
> >
> > Roland.
> >
> >
> >
> >
> >
> >
> >
> >
> > On 3/10/07, Wolfgang Grandegger <wg@domain.hid> wrote:
> >> Hi Roland,
> >>
> >> hope most of your problems and questions with RT-Socket-CAN have already
> >> been solved or answered. I will not have the time to read carefully all
> >> your mails accumulated over the last week, sorry, it's too much traffic.
> >> Could you please briefly summarize the pending issues.
> >>
> >> Thanks,
> >>
> >> Wolfgang.
> >>
> >> Roland Tollenaar wrote:
> >> > Hi,
> >> >
> >> > The following probably relates to the functioning of the sja1000
> >> chip. I
> >> > cannot see how it can NOT be possible for the chip to function properly
> >> > without also having the ability to be read by a fully interruptible
> >> ISR.
> >> >
> >> > Could below just be clarified for me please?
> >> >
> >> > When the 14 registers of the sja1000 chip are being read, I presume
> >> this
> >> > is a single CAN frame that is being recovered which will
> >> subsequently be
> >> > written to the message buffer of the sockets currently connected to the
> >> > device. I also presume that while the registers are being read new
> >> > incoming messages from the Bus will not be written into these registers
> >> > because this would possibly corrupt the frame that is currently being
> >> > extracted from the registers. i.e. if the ISR has read 7 of the 14
> >> > messages and a new message is now written into the registers the
> >> > resulting frame will be a mixture of two distinct received messages. To
> >> > prevent that happening I presume it must be possible to lock the
> >> > registers while the Rx-ISR is busy doing its reading of the 14
> >> > registers? Messages that arrive on the bus while the Rx-ISR is locking
> >> > the 14 registers will then either be discarded or sent again by the
> >> node
> >> > as a result of the sending node not receiving an acknowledge message?
> >> >
> >> > The point of the above questions being that if it is possible to lock
> >> > the 14 registers there is no reason in my humble opinion (IMHO) that
> >> the
> >> > the Rx-ISR cannot be interrupted. Correct? Of course one wants to
> >> > minimize the delay to optimize bus traffic but such behaviour would
> >> > certainly improve Real-Time capabilities.
> >> >
> >> > If the non-real-time driver functions as described above (locks the 14
> >> > registers and allows itself to be interrupted) it will be better for me
> >> > to use the non-real-time driver in a stand-alone non-real-time
> >> > application which reads the CAN bus and presents the data it
> >> receives to
> >> > the real-time application (or any other application for that matter)
> >> via
> >> > a mechanism of choice. E.g. in a file on RAM-Disk, a pipe etc. In short
> >> > this would be a CAN-server which, since it is a fully interruptible
> >> > normal process will allow my real-time applications to tick away
> >> > undisturbed.
> >> >
> >> > Is the reasoning incorrect?
> >> >
> >> >
> >> > Having written the above I have just downloaded the datasheet of the
> >> > SJA1000 and it seems to confirm my above conjecture. Firstly there are
> >> > 64 bytes of FIFO receive buffer 13 of which are presented as a window
> >> > and are probably the ones referred to by Sebastian as the ones the ISR
> >> > reads out. This means that while reading out the window messages will
> >> > not get lost immediately.
> >> >
> >> > Then on page 10 with a more detailed explanation on page 14 they talk
> >> > about a command register with a bit switch called the Release receive
> >> > Buffer (RRB) which seems to have the function of the lock I was talking
> >> > about.
> >> >
> >> > Can you more knowledgeable people comment on this. It the above is
> >> > correct it could enormously improve the applicability of the driver for
> >> >  Real-Time control. Which I presume the driver is all about?
> >> >
> >> >
> >> > Regards,
> >> >
> >> > Roland.
> >> >
> >> >
> >> > _______________________________________________
> >> > Xenomai-help mailing list
> >> > Xenomai-help@domain.hid
> >> > https://mail.gna.org/listinfo/xenomai-help
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[Wolfgang Grandegger]

roland Tollenaar wrote:
>>
>> Access to the parallel port is slow, indeed. Looking to
>> rtcan_peak_dng_epp_readreg tells me, that 6 inb/outb are required to
>> read one register and if every inb/outb takes up 1-2 us ... puh ... the
>> problem gets obvious. Nevertheless, this problem is special for the PCAN
>> dongle and it seems to be a bad choice for RT-Socket-CAN.
> That may be. I was not aware of this beforehand and on my laptop its
> all I have besides USB and PCMCIA which are not supported RT. Besides,
> if we look at this fundamentally the PCAN dongle is not TOO slow. 200
> micoseconds leaves me 800 ms in a 1ms task to do work. That should be
> ample. So the problem (in my case) lies more in the behavior of the
> ISR, the fact that it reacts to all Rx interrupts and rigorously
> blocks all other processes. If you consider how the structure i
> suggested earlier with a non-real-time CAN-service utilizing a driver
> with interruptible Rx-ISR could be used to sort out my problem the
> fact that the slowness of the hardware is not -as such- the constraint
> becomes evident. Of course I agree that if hardware is used that would
> provide 20 us reading time the problem would be less visible. But for
> someone who is interested in a 200us task-time that may be a problem
> again so such a person or project would then also benefit from an
> interruptible Rx-ISR. Which again emphasizes my feeling that faster
> hardware diminishes the symptoms of the problem, not really the
> problem.

Yes, you are right and my hope is that other devices can read the 
registers in less than 20 us...

> All other
>> devices can read/write registers much faster. I'm going to do some more
>> tests next week, also with other CAN hardware. Sebastian, have you
>> realized similar latency problems with SJA1000 on the ISA bus (which is
>> slow as well)?

.. and that's the reason why I asked the question above.

>> > Don't stress I will circumvent the problem even if it means discarding
>> > CAN and using some other bus. So I am not really worried.
>>
>> The question is how we can help you quickly.
> 
> Thanks.
> 
>>
>> > Taking the slow hardware as a given the only elegant solution IMHO is
>> > letting the Rx-ISR be interruptible by the rt-tasks so that those can
>> > at least complete their work and cycle with reasonable latency (50
>> > microseconds max, 25microsecond average)
>> >
>> > Sebastian's opinion is that making it interruptible would be "the
>> > start of chaos". I am sure he knows more about this than I ever will
>> > but only out of academic interest before I sort this problem out
>> > outside the realm of rtcan, I would like to know why.
>>
>> As I see it, the right solution would be to handle the CAN interrupts by
>> a service task and disabled the corresponding IRQ till it's handled.
> Agreed.
> 
> I
>> do not see a real problem with this method, but it requires substantial
>> implementation effort. I think threaded IRQs are on Jan's to-do list for
>> RTDM as well, but they will also not be available soon.
> I fully understand. Not the part about a "threaded IRQ" though. What
> does that entail exactly?

For each IRQ there is a dedicated thread handling it allowing for 
privatization of interrupts.

>> And if the
>> problem is just relevant for the parallel port, it might not be worth
>> the effort.
> This is for you people to say. I on the other hand get the impression
> that this touches a defining issue of real-time drivers. Earlier I
> posted the question of what distinguishes a "real-time" driver from a
> normal device driver. The answer if i understood correctly was related
> to the inability of the RT driver to be interrupted by any old non-rt
> process which would render any rt-task to be non-rt. If on the other
> hand the rt-driver is a rigid block that can not even be interrupted
> by the rt-task itself AND the rt-driver responds to external IRQ
> signals at its own discretion, well IMHO the rt-task is broken. Using
> my case as an example, what we have is a situation where the CAN-bus
> dictates what the CPU must pay attention to instead of the rt-task
> being dominant in that respect.
> 
> Don't get me wrong, the above is not intended to convince you or
> anyone else to sort out this issue in the driver. Its just a point of
> view that I have and am interested in the opinions about. I will
> settle for solving the problem with faster hardware with no second
> thoughts. I do have two concerns on this I will mention later.

I fully share your point of view. The ISR should be as short as possible.

> 
>> OK, what other CAN hardware would be an option for you. Do you have PCI
>> on your board?
> If you discover that Peak PCI boards have acceptable impact on the
> latency then I will continue to develop with the dongle on my laptop
> but use PCI when I finally reach implementation for production stage.

I'm quite sure that access to PCI is much faster even if other devices 
can do rather long bursts.

>>
>> > Hopefully below email will make more sense to you now.
>>
>> It does, thanks for pointing us to the problem. So far I was not aware
>> of it and I'm curious, how much the latency will be affected on my
>> Laptop and PC.
> If you don't experience the problem,  tell me what laptop you are
> using. I am always on the lookout for a good excuse to get a new one.
> :)

I understood that the access speed depends a lot on the motherboard but 
I do not expect wonders.

> I mentioned earlier that I would revert to two concerns regarding the
> faster hardware.
> 
> The first concern is that it was mentioned in one of the threads that
> the clock rate of the sja1000 is rather low and reading out the sja
> registers is not a fast exercise. If that is the case then a faster
> interface (PCI) might not help all that much to suppress the symptoms.

The clock is relevant for the CAN bus, but not for the register access 
by the CPU.

> The second concern is that even if I have a faster interface even if
> it is substantially faster (added latency < 20 us) I still have a
> potential problem. Consider the case where I have a few nodes on the
> bus. Most of them are relatively quiet, one of them sends a position
> every 1ms and everything is running fine. Now suddenly some nodes post
> an exception of some sort (emergency something or other and send a
> host of messages). With the current driver design, the driver will
> respond to all the Rx interrupts and be so busy reading the messages
> and posting them to the sockets that the control tasks will have no
> time to a) handle the exception quickly and b) get through
> position-control calculations on time.
> The net effect could be that the machine responds to the exception
> badly, closes down too late and the feedback control goes off-kilter
> crashing the physical process. To exclude the possibility of a broken
> machine i would need to get control over the send behavior of the
> nodes in every possible exception to ensure that the bus never gets
> too busy etc etc.

The interrupt rate is limited by the CAN bus speed, which could be 
rather high at 1MB/s, indeed. And also error frames, as created 
frequently by the SJA1000 in case of errors, could have some bad impact 
on the latency. But keep in mind that an interrupt service tasks also 
adds some overhead. A more detailed analysis is necessary.

> So I really feel your suggestion of working with an (interruptible)
> service-task and blocking IRQ's is a better approach.

I agree that it would be nice to have that option and it's already on my 
wish list. Patches are welcome, of course.

Wolfgang.

> Regards,
> 
> Roland.
> 
> 
>>
>> Wolfgang.
>>
>> > Regards,
>> >
>> > Roland.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 3/10/07, Wolfgang Grandegger <wg@domain.hid> wrote:
>> >> Hi Roland,
>> >>
>> >> hope most of your problems and questions with RT-Socket-CAN have 
>> already
>> >> been solved or answered. I will not have the time to read carefully 
>> all
>> >> your mails accumulated over the last week, sorry, it's too much 
>> traffic.
>> >> Could you please briefly summarize the pending issues.
>> >>
>> >> Thanks,
>> >>
>> >> Wolfgang.
>> >>
>> >> Roland Tollenaar wrote:
>> >> > Hi,
>> >> >
>> >> > The following probably relates to the functioning of the sja1000
>> >> chip. I
>> >> > cannot see how it can NOT be possible for the chip to function 
>> properly
>> >> > without also having the ability to be read by a fully interruptible
>> >> ISR.
>> >> >
>> >> > Could below just be clarified for me please?
>> >> >
>> >> > When the 14 registers of the sja1000 chip are being read, I presume
>> >> this
>> >> > is a single CAN frame that is being recovered which will
>> >> subsequently be
>> >> > written to the message buffer of the sockets currently connected 
>> to the
>> >> > device. I also presume that while the registers are being read new
>> >> > incoming messages from the Bus will not be written into these 
>> registers
>> >> > because this would possibly corrupt the frame that is currently 
>> being
>> >> > extracted from the registers. i.e. if the ISR has read 7 of the 14
>> >> > messages and a new message is now written into the registers the
>> >> > resulting frame will be a mixture of two distinct received 
>> messages. To
>> >> > prevent that happening I presume it must be possible to lock the
>> >> > registers while the Rx-ISR is busy doing its reading of the 14
>> >> > registers? Messages that arrive on the bus while the Rx-ISR is 
>> locking
>> >> > the 14 registers will then either be discarded or sent again by the
>> >> node
>> >> > as a result of the sending node not receiving an acknowledge 
>> message?
>> >> >
>> >> > The point of the above questions being that if it is possible to 
>> lock
>> >> > the 14 registers there is no reason in my humble opinion (IMHO) that
>> >> the
>> >> > the Rx-ISR cannot be interrupted. Correct? Of course one wants to
>> >> > minimize the delay to optimize bus traffic but such behaviour would
>> >> > certainly improve Real-Time capabilities.
>> >> >
>> >> > If the non-real-time driver functions as described above (locks 
>> the 14
>> >> > registers and allows itself to be interrupted) it will be better 
>> for me
>> >> > to use the non-real-time driver in a stand-alone non-real-time
>> >> > application which reads the CAN bus and presents the data it
>> >> receives to
>> >> > the real-time application (or any other application for that matter)
>> >> via
>> >> > a mechanism of choice. E.g. in a file on RAM-Disk, a pipe etc. In 
>> short
>> >> > this would be a CAN-server which, since it is a fully interruptible
>> >> > normal process will allow my real-time applications to tick away
>> >> > undisturbed.
>> >> >
>> >> > Is the reasoning incorrect?
>> >> >
>> >> >
>> >> > Having written the above I have just downloaded the datasheet of the
>> >> > SJA1000 and it seems to confirm my above conjecture. Firstly 
>> there are
>> >> > 64 bytes of FIFO receive buffer 13 of which are presented as a 
>> window
>> >> > and are probably the ones referred to by Sebastian as the ones 
>> the ISR
>> >> > reads out. This means that while reading out the window messages 
>> will
>> >> > not get lost immediately.
>> >> >
>> >> > Then on page 10 with a more detailed explanation on page 14 they 
>> talk
>> >> > about a command register with a bit switch called the Release 
>> receive
>> >> > Buffer (RRB) which seems to have the function of the lock I was 
>> talking
>> >> > about.
>> >> >
>> >> > Can you more knowledgeable people comment on this. It the above is
>> >> > correct it could enormously improve the applicability of the 
>> driver for
>> >> >  Real-Time control. Which I presume the driver is all about?
>> >> >
>> >> >
>> >> > Regards,
>> >> >
>> >> > Roland.
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Xenomai-help mailing list
>> >> > Xenomai-help@domain.hid
>> >> > https://mail.gna.org/listinfo/xenomai-help
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
> 
> 

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[roland Tollenaar]

Lets see what your tests reveal. But I must remember to keep in mind
that faster hardware access will still always leave a real-time
application exposed to the possibility that unforeseen heavy traffic
destroys the apps RT behavior. So that when I see inexplicable,
undesirable and mysterious intermittent behavior I remember to check
the rate of incoming messages :)

Roland.

On 3/11/07, Wolfgang Grandegger <wg@domain.hid> wrote:
> roland Tollenaar wrote:
> >>
> >> Access to the parallel port is slow, indeed. Looking to
> >> rtcan_peak_dng_epp_readreg tells me, that 6 inb/outb are required to
> >> read one register and if every inb/outb takes up 1-2 us ... puh ... the
> >> problem gets obvious. Nevertheless, this problem is special for the PCAN
> >> dongle and it seems to be a bad choice for RT-Socket-CAN.
> > That may be. I was not aware of this beforehand and on my laptop its
> > all I have besides USB and PCMCIA which are not supported RT. Besides,
> > if we look at this fundamentally the PCAN dongle is not TOO slow. 200
> > micoseconds leaves me 800 ms in a 1ms task to do work. That should be
> > ample. So the problem (in my case) lies more in the behavior of the
> > ISR, the fact that it reacts to all Rx interrupts and rigorously
> > blocks all other processes. If you consider how the structure i
> > suggested earlier with a non-real-time CAN-service utilizing a driver
> > with interruptible Rx-ISR could be used to sort out my problem the
> > fact that the slowness of the hardware is not -as such- the constraint
> > becomes evident. Of course I agree that if hardware is used that would
> > provide 20 us reading time the problem would be less visible. But for
> > someone who is interested in a 200us task-time that may be a problem
> > again so such a person or project would then also benefit from an
> > interruptible Rx-ISR. Which again emphasizes my feeling that faster
> > hardware diminishes the symptoms of the problem, not really the
> > problem.
>
> Yes, you are right and my hope is that other devices can read the
> registers in less than 20 us...
>
> > All other
> >> devices can read/write registers much faster. I'm going to do some more
> >> tests next week, also with other CAN hardware. Sebastian, have you
> >> realized similar latency problems with SJA1000 on the ISA bus (which is
> >> slow as well)?
>
> .. and that's the reason why I asked the question above.
>
> >> > Don't stress I will circumvent the problem even if it means discarding
> >> > CAN and using some other bus. So I am not really worried.
> >>
> >> The question is how we can help you quickly.
> >
> > Thanks.
> >
> >>
> >> > Taking the slow hardware as a given the only elegant solution IMHO is
> >> > letting the Rx-ISR be interruptible by the rt-tasks so that those can
> >> > at least complete their work and cycle with reasonable latency (50
> >> > microseconds max, 25microsecond average)
> >> >
> >> > Sebastian's opinion is that making it interruptible would be "the
> >> > start of chaos". I am sure he knows more about this than I ever will
> >> > but only out of academic interest before I sort this problem out
> >> > outside the realm of rtcan, I would like to know why.
> >>
> >> As I see it, the right solution would be to handle the CAN interrupts by
> >> a service task and disabled the corresponding IRQ till it's handled.
> > Agreed.
> >
> > I
> >> do not see a real problem with this method, but it requires substantial
> >> implementation effort. I think threaded IRQs are on Jan's to-do list for
> >> RTDM as well, but they will also not be available soon.
> > I fully understand. Not the part about a "threaded IRQ" though. What
> > does that entail exactly?
>
> For each IRQ there is a dedicated thread handling it allowing for
> privatization of interrupts.
>
> >> And if the
> >> problem is just relevant for the parallel port, it might not be worth
> >> the effort.
> > This is for you people to say. I on the other hand get the impression
> > that this touches a defining issue of real-time drivers. Earlier I
> > posted the question of what distinguishes a "real-time" driver from a
> > normal device driver. The answer if i understood correctly was related
> > to the inability of the RT driver to be interrupted by any old non-rt
> > process which would render any rt-task to be non-rt. If on the other
> > hand the rt-driver is a rigid block that can not even be interrupted
> > by the rt-task itself AND the rt-driver responds to external IRQ
> > signals at its own discretion, well IMHO the rt-task is broken. Using
> > my case as an example, what we have is a situation where the CAN-bus
> > dictates what the CPU must pay attention to instead of the rt-task
> > being dominant in that respect.
> >
> > Don't get me wrong, the above is not intended to convince you or
> > anyone else to sort out this issue in the driver. Its just a point of
> > view that I have and am interested in the opinions about. I will
> > settle for solving the problem with faster hardware with no second
> > thoughts. I do have two concerns on this I will mention later.
>
> I fully share your point of view. The ISR should be as short as possible.
>
> >
> >> OK, what other CAN hardware would be an option for you. Do you have PCI
> >> on your board?
> > If you discover that Peak PCI boards have acceptable impact on the
> > latency then I will continue to develop with the dongle on my laptop
> > but use PCI when I finally reach implementation for production stage.
>
> I'm quite sure that access to PCI is much faster even if other devices
> can do rather long bursts.
>
> >>
> >> > Hopefully below email will make more sense to you now.
> >>
> >> It does, thanks for pointing us to the problem. So far I was not aware
> >> of it and I'm curious, how much the latency will be affected on my
> >> Laptop and PC.
> > If you don't experience the problem,  tell me what laptop you are
> > using. I am always on the lookout for a good excuse to get a new one.
> > :)
>
> I understood that the access speed depends a lot on the motherboard but
> I do not expect wonders.
>
> > I mentioned earlier that I would revert to two concerns regarding the
> > faster hardware.
> >
> > The first concern is that it was mentioned in one of the threads that
> > the clock rate of the sja1000 is rather low and reading out the sja
> > registers is not a fast exercise. If that is the case then a faster
> > interface (PCI) might not help all that much to suppress the symptoms.
>
> The clock is relevant for the CAN bus, but not for the register access
> by the CPU.
>
> > The second concern is that even if I have a faster interface even if
> > it is substantially faster (added latency < 20 us) I still have a
> > potential problem. Consider the case where I have a few nodes on the
> > bus. Most of them are relatively quiet, one of them sends a position
> > every 1ms and everything is running fine. Now suddenly some nodes post
> > an exception of some sort (emergency something or other and send a
> > host of messages). With the current driver design, the driver will
> > respond to all the Rx interrupts and be so busy reading the messages
> > and posting them to the sockets that the control tasks will have no
> > time to a) handle the exception quickly and b) get through
> > position-control calculations on time.
> > The net effect could be that the machine responds to the exception
> > badly, closes down too late and the feedback control goes off-kilter
> > crashing the physical process. To exclude the possibility of a broken
> > machine i would need to get control over the send behavior of the
> > nodes in every possible exception to ensure that the bus never gets
> > too busy etc etc.
>
> The interrupt rate is limited by the CAN bus speed, which could be
> rather high at 1MB/s, indeed. And also error frames, as created
> frequently by the SJA1000 in case of errors, could have some bad impact
> on the latency. But keep in mind that an interrupt service tasks also
> adds some overhead. A more detailed analysis is necessary.
>
> > So I really feel your suggestion of working with an (interruptible)
> > service-task and blocking IRQ's is a better approach.
>
> I agree that it would be nice to have that option and it's already on my
> wish list. Patches are welcome, of course.
>
> Wolfgang.
>
> > Regards,
> >
> > Roland.
> >
> >
> >>
> >> Wolfgang.
> >>
> >> > Regards,
> >> >
> >> > Roland.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On 3/10/07, Wolfgang Grandegger <wg@domain.hid> wrote:
> >> >> Hi Roland,
> >> >>
> >> >> hope most of your problems and questions with RT-Socket-CAN have
> >> already
> >> >> been solved or answered. I will not have the time to read carefully
> >> all
> >> >> your mails accumulated over the last week, sorry, it's too much
> >> traffic.
> >> >> Could you please briefly summarize the pending issues.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Wolfgang.
> >> >>
> >> >> Roland Tollenaar wrote:
> >> >> > Hi,
> >> >> >
> >> >> > The following probably relates to the functioning of the sja1000
> >> >> chip. I
> >> >> > cannot see how it can NOT be possible for the chip to function
> >> properly
> >> >> > without also having the ability to be read by a fully interruptible
> >> >> ISR.
> >> >> >
> >> >> > Could below just be clarified for me please?
> >> >> >
> >> >> > When the 14 registers of the sja1000 chip are being read, I presume
> >> >> this
> >> >> > is a single CAN frame that is being recovered which will
> >> >> subsequently be
> >> >> > written to the message buffer of the sockets currently connected
> >> to the
> >> >> > device. I also presume that while the registers are being read new
> >> >> > incoming messages from the Bus will not be written into these
> >> registers
> >> >> > because this would possibly corrupt the frame that is currently
> >> being
> >> >> > extracted from the registers. i.e. if the ISR has read 7 of the 14
> >> >> > messages and a new message is now written into the registers the
> >> >> > resulting frame will be a mixture of two distinct received
> >> messages. To
> >> >> > prevent that happening I presume it must be possible to lock the
> >> >> > registers while the Rx-ISR is busy doing its reading of the 14
> >> >> > registers? Messages that arrive on the bus while the Rx-ISR is
> >> locking
> >> >> > the 14 registers will then either be discarded or sent again by the
> >> >> node
> >> >> > as a result of the sending node not receiving an acknowledge
> >> message?
> >> >> >
> >> >> > The point of the above questions being that if it is possible to
> >> lock
> >> >> > the 14 registers there is no reason in my humble opinion (IMHO) that
> >> >> the
> >> >> > the Rx-ISR cannot be interrupted. Correct? Of course one wants to
> >> >> > minimize the delay to optimize bus traffic but such behaviour would
> >> >> > certainly improve Real-Time capabilities.
> >> >> >
> >> >> > If the non-real-time driver functions as described above (locks
> >> the 14
> >> >> > registers and allows itself to be interrupted) it will be better
> >> for me
> >> >> > to use the non-real-time driver in a stand-alone non-real-time
> >> >> > application which reads the CAN bus and presents the data it
> >> >> receives to
> >> >> > the real-time application (or any other application for that matter)
> >> >> via
> >> >> > a mechanism of choice. E.g. in a file on RAM-Disk, a pipe etc. In
> >> short
> >> >> > this would be a CAN-server which, since it is a fully interruptible
> >> >> > normal process will allow my real-time applications to tick away
> >> >> > undisturbed.
> >> >> >
> >> >> > Is the reasoning incorrect?
> >> >> >
> >> >> >
> >> >> > Having written the above I have just downloaded the datasheet of the
> >> >> > SJA1000 and it seems to confirm my above conjecture. Firstly
> >> there are
> >> >> > 64 bytes of FIFO receive buffer 13 of which are presented as a
> >> window
> >> >> > and are probably the ones referred to by Sebastian as the ones
> >> the ISR
> >> >> > reads out. This means that while reading out the window messages
> >> will
> >> >> > not get lost immediately.
> >> >> >
> >> >> > Then on page 10 with a more detailed explanation on page 14 they
> >> talk
> >> >> > about a command register with a bit switch called the Release
> >> receive
> >> >> > Buffer (RRB) which seems to have the function of the lock I was
> >> talking
> >> >> > about.
> >> >> >
> >> >> > Can you more knowledgeable people comment on this. It the above is
> >> >> > correct it could enormously improve the applicability of the
> >> driver for
> >> >> >  Real-Time control. Which I presume the driver is all about?
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Roland.
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > Xenomai-help mailing list
> >> >> > Xenomai-help@domain.hid
> >> >> > https://mail.gna.org/listinfo/xenomai-help
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

Wolfgang Grandegger wrote:
> roland Tollenaar wrote:
>> So I really feel your suggestion of working with an (interruptible)
>> service-task and blocking IRQ's is a better approach.
> 
> I agree that it would be nice to have that option and it's already on my
> wish list. Patches are welcome, of course.

Threaded IRQs are no magic bullet. They can only help to push a problem
down the priority ladder, curing a problem symptom where possible.

Nevertheless, threaded IRQs for RTDM are planned. The yet open design
challenge is how to support driver writers best when they have to switch
between both models, e.g. during compile-time (keep in mind, you also
have to switch the locking: spinlock<->mutex).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[roland Tollenaar]

Hi,

I need some tutoring again if anyone cares to.

> Threaded IRQs are no magic bullet. They can only help to push a problem
> down the priority ladder, curing a problem symptom where possible.

I keep going on about "interruptible" ISR's. Yet I never see the
phrase used by anyone else. This either means that "Threaded IRQ's" or
"service-tasks" are implicitly interruptible, i.e. do not hog the CPU
for themselves exclusively, or I am missing something a lot more
fundamental? Is a "threaded IRQ" a possible solution because threads
(even real-time ones) will automatically share the CPU according to
priority? Is this different to a "service task" as mentioned by
Wolfgang or are the two basically the same?

>
> Nevertheless, threaded IRQs for RTDM are planned. The yet open design
> challenge is how to support driver writers best when they have to switch
> between both models, e.g. during compile-time (keep in mind, you also
> have to switch the locking: spinlock<->mutex).
What is a mutex?

This is slightly off the topic but is it ridiculous to ask whether it
is possible to suppress interrupts from user space?

A possible work-around to the long reading spell occurred to me in the
following. I turn my 1ms task into for example a 0.5ms task. By
releasing interrupt IRQ7 every second time the task is run and
suppressing it on the other, then by using a corresponding toggle I
can alternately read-out the can and calculate and set control outputs
on every second time the task is run.
I might have a bit of trouble preventing the FIFO buffer on the chip
to overflow but it would be interesting to know what it takes to
suppress an interrupt anyway.

?

Regards,

Roland.

>
> Jan
>
>
>

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[Wolfgang Grandegger]

roland Tollenaar wrote:
> Hi,
> 
> I need some tutoring again if anyone cares to.
> 
>> Threaded IRQs are no magic bullet. They can only help to push a problem
>> down the priority ladder, curing a problem symptom where possible.
> 
> I keep going on about "interruptible" ISR's. Yet I never see the
> phrase used by anyone else. This either means that "Threaded IRQ's" or

E.g. Linux-rt has "threaded IRQs" (http://lwn.net/Articles/146861/).

> "service-tasks" are implicitly interruptible, i.e. do not hog the CPU
> for themselves exclusively, or I am missing something a lot more
> fundamental? Is a "threaded IRQ" a possible solution because threads
> (even real-time ones) will automatically share the CPU according to
> priority? Is this different to a "service task" as mentioned by
> Wolfgang or are the two basically the same?

Almost, threaded IRQs is a generic framework to manage interrupts by 
threads. The CAN "service task" manages the CAN interrupts by threads.

>> Nevertheless, threaded IRQs for RTDM are planned. The yet open design
>> challenge is how to support driver writers best when they have to switch
>> between both models, e.g. during compile-time (keep in mind, you also
>> have to switch the locking: spinlock<->mutex).
> What is a mutex?

wikipedia mutex!

> This is slightly off the topic but is it ridiculous to ask whether it
> is possible to suppress interrupts from user space?
> 
> A possible work-around to the long reading spell occurred to me in the
> following. I turn my 1ms task into for example a 0.5ms task. By
> releasing interrupt IRQ7 every second time the task is run and
> suppressing it on the other, then by using a corresponding toggle I
> can alternately read-out the can and calculate and set control outputs
> on every second time the task is run.
> I might have a bit of trouble preventing the FIFO buffer on the chip
> to overflow but it would be interesting to know what it takes to
> suppress an interrupt anyway.

This sounds wired. The IRQ is not manageable by the app and device 
polling mode without interrupts is not for-seen by the driver.

Wolfgang.

[Xenomai-help] RT samples

[karre]

Hi Folks,

I want to measure and evalutate different parameters of system load in Xenomai. Therefore, I am in need of RT samples that simply provide a variety of ressource usage (semaphores, threads, timers, ...).

It is not very important what the tool actually does, as long as it can be run autonomously (latency from the testsuite would be a good example for that).

Who knows good ressources for open source real-time applications?

Btw, the type of skin (Native, POSIX, RTAI, ...) is not important. If it is software that is platform-dependant, than the architecture of choice would be x86. If there was not needed additional hardware, that would be ideal.

Thanks a lot in advance!

Richard

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[Sebastian Smolorz]

Wolfgang Grandegger wrote:
>
> Access to the parallel port is slow, indeed. Looking to
> rtcan_peak_dng_epp_readreg tells me, that 6 inb/outb are required to
> read one register and if every inb/outb takes up 1-2 us ... puh ... the
> problem gets obvious. Nevertheless, this problem is special for the PCAN
> dongle and it seems to be a bad choice for RT-Socket-CAN. All other
> devices can read/write registers much faster. I'm going to do some more
> tests next week, also with other CAN hardware. Sebastian, have you
> realized similar latency problems with SJA1000 on the ISA bus (which is
> slow as well)?

No, I didn't realize any latency problems with the ISA CAN controller. 
However, I didn't made any discrete latency measure tests. But the fact that 
the SJA1000 driver is used on all robots of the RTS with 1 MB/s laser 
scanners and a few more CAN nodes shows me that the latency impact is not 
critical.

> >
> > Sebastian's opinion is that making it interruptible would be "the
> > start of chaos". I am sure he knows more about this than I ever will
> > but only out of academic interest before I sort this problem out
> > outside the realm of rtcan, I would like to know why.
>
> As I see it, the right solution would be to handle the CAN interrupts by
> a service task and disabled the corresponding IRQ till it's handled. I
> do not see a real problem with this method,

I didn't say it's impossible. My point was that making the CAN ISR just 
interruptible with no other changes is not enough.

> but it requires substantial 
> implementation effort.

Right, and for users who don't have such hardware limits like Roland it is 
probably more important that CAN interrupts are processed with no deferral. 
So we would have to deal with both needs. Therefore my statement in a 
previous mail that all the necessary work won't be done in five minutes.

-- 
Sebastian

Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[Wolfgang Grandegger]

Sebastian Smolorz wrote:
> Wolfgang Grandegger wrote:
>> Access to the parallel port is slow, indeed. Looking to
>> rtcan_peak_dng_epp_readreg tells me, that 6 inb/outb are required to
>> read one register and if every inb/outb takes up 1-2 us ... puh ... the
>> problem gets obvious. Nevertheless, this problem is special for the PCAN
>> dongle and it seems to be a bad choice for RT-Socket-CAN. All other
>> devices can read/write registers much faster. I'm going to do some more
>> tests next week, also with other CAN hardware. Sebastian, have you
>> realized similar latency problems with SJA1000 on the ISA bus (which is
>> slow as well)?
> 
> No, I didn't realize any latency problems with the ISA CAN controller. 
> However, I didn't made any discrete latency measure tests. But the fact that 
> the SJA1000 driver is used on all robots of the RTS with 1 MB/s laser 
> scanners and a few more CAN nodes shows me that the latency impact is not 
> critical.

OK, I did'nt expected that reading approx. 15 bytes is really critical. 
But the problem exists and reading these from the ISA bus likely also 
takes 10..20 us.

>>> Sebastian's opinion is that making it interruptible would be "the
>>> start of chaos". I am sure he knows more about this than I ever will
>>> but only out of academic interest before I sort this problem out
>>> outside the realm of rtcan, I would like to know why.
>> As I see it, the right solution would be to handle the CAN interrupts by
>> a service task and disabled the corresponding IRQ till it's handled. I
>> do not see a real problem with this method,
> 
> I didn't say it's impossible. My point was that making the CAN ISR just 
> interruptible with no other changes is not enough.
> 
>> but it requires substantial 
>> implementation effort.
> 
> Right, and for users who don't have such hardware limits like Roland it is 
> probably more important that CAN interrupts are processed with no deferral. 
> So we would have to deal with both needs. Therefore my statement in a 
> previous mail that all the necessary work won't be done in five minutes.

Well, I know but it already got a rather high position on the wish list.

Wolfgang,