From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46C03F62.30009@domain.hid> Date: Mon, 13 Aug 2007 13:24:18 +0200 From: Wolfgang Grandegger MIME-Version: 1.0 References: <46C01909.5020308@domain.hid> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] RTDM 82527 Xenomai driver List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: juanba romance Cc: Jan Kiszka , xenomai@xenomai.org juanba romance wrote: [...] > After review your current user interface i can not understand how a RF > cycle flows through the user application > holding as much as possible the latency at the receiver side. Maybe it's > my own misunderstanding. Your just send a "remote transmission request" message and receive the response as a normal message. > The point is one node requests an information to another one issuing a > RF, the CAN specification says that the RF receptor will handshake the > cycle issuing the corresponding DF, and right here is when/where i am > fuzzy. We use this capability using real time as much as possible only > relying on the CANbus network load, i mean we perform the RF handshake > using the RF receptor mailbox auto-reply capability, feedbacking the > user software only when the DF handshake is decoded at the network, this > event will trigger the user actions i.e. the message data update with > the new local variables state. This feature is requested through the > configuration stage, this kind of information is labeled as "quick.ack" > responses , cause are not related with software at all. The RF requester > has the guarantee that the information is sampled with any jitter > software coupled. The typical approach found in other stacks is labelled > as " slow.ack", it avoids to response the RF-request up to reach any > software area (kernel/user spaces) that explicitly issue the data-frame > as usual, this is how can-festival currently works. Can you point me to the code in CAN-Festival supporting directly that feature of the i82527? RTR message handling of the i82527 is very special and I do not know any other (non-compatible) CAN controller doing it in a similar way. The feature you like so much makes it actually a nightmare to support the i82527 in a generic framework (like RT-Socket-CAN or Socket-CAN), especially receiving RTR messages by justs using send and receive. Anyhow, supporting the RTR auto-reply capability in (RT-)Socket-CAN is feasible and would be a "nice to have". It could be supported by a generic RTR update object. Would be nice, if you bring-up the idea on the Socket-CAN mailing list to share it between other CAN experts with the goal to define an CAN-API extension. Wolfgang.