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
[email protected]
https://mail.gna.org/listinfo/xenomai-help
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
