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

[Wolfgang Grandegger <wg@domain.hid>]

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
> 
>