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. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
