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.
Xenomai-core mailing list