On 8/13/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > > 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.
I was pointing to the receiver node software. The requester node flow seems quite standard/clear. > > 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? It doesn't. All the incoming RTR flow must be handshaked by the user space, i.e. take a look on lifegrd.c at the src directory entry and review the first filter based on the .rtr message struct field located on the symbol proceedNODE_GUARD(CO_Data* d, Message* m ), the symbol context drive me to think in a "soft" ack.. But the point is: should one remove this powerful issue from the design/implementation cause one specific user library doesn't provide the feature ? >From my point of view this restriction is too much. The consider the can-festival stuff is a facility to attach the CANopen specification nothing else, we already have applications that smoothly run using the raw CAN bus 2.0 specification. May be other CANopen stack be available sometime, maybe we write our own, maybe we remove the CANopen layer, i mean, nobody knows.. In fact in a first approach, we plan that the can-festival related driver layer not use the high speed ACK. We will measure the latencies using the layer as it is and then will take a final decision.. 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. Fully agree. We have thought a lot about this feature at our company before start this stuff long, long, long time ago. But the stuff was solved and fixed and it has been part of our functional specifications along this time, we still would like to hold it.. > 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. > Fully agree. I think that the driver documentation will help a lot, uhmm let me do some pictures and write some formal document about and you will have a a better point of view.. > Wolfgang. >
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core