Re: [Xenomai-core] RTDM 82527 Xenomai driver
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
Re: [Xenomai-core] RTDM 82527 Xenomai driver
On 8/13/07, Jan Kiszka [EMAIL PROTECTED] wrote: juanba romance wrote: On 8/13/07, Jan Kiszka [EMAIL PROTECTED] wrote: juanba romance wrote: Hello, all, I am currently developing a RTDM/xenomai driver for the CANbus chipset 82527 that i think it could have some interest it has the next features: Thanks for moving our private thread here! See, now we know that Wolfgang is already working on 82527 support for RT-Socket-CAN - something I wasn't aware of as well. 1. Specific management for the remote frames CANbus feasibility, it couple the real-time data bus flow with a user software feedback to handshake remote frames and update mailbox callback for the auto-replied messages Mind to elaborate what you precisely gain here compared to open-coded designs (loop closed over the application)? Can you quantify the improvements? 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. 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. The point is that quite a few CAN controllers do not support this hardware-based RF reply. And as Socket-CAN aims at a _generic_ API, not the n-th Intel or MSCAN or whatever CAN stack, we had to define the basic interface without such special support first. But that doesn't mean we would be unable to extend the profile with optional or, when required, software-emulated accelerations like for RTR handling. Fully agree. One of the reason to write the driver was to use it as our current applications require it IMHO this feature is powerful a lot, an could be really nice to allow some kind of service attached to this feature i.e. we have measure less than 250usec to suck the full package from a remote CANbus node . (all the numbers are referenced to 1Mbit bus rate, and assuming full packages it means ~100bits ) That's what we're interested in: How may such an extension look like to exploit the hardware to its limits where available, _without_ giving up CAN application portability? In the cases where not be available at chipset level, i think that the quick.ack could be implemented at kernel space using a private mailbox where the driver itself could perform the data exchange. Our proposal use the configuration stage to assign this reserved objects and the standard input interface is used to update the message data. The transmission overhead on such kind of objects is really fast, it's a good argument to be driver embedded. I think that the documentation and the examples that i am producing/building right now should illustrate the stuff. I don't see too much different between two approaches from the user API point of view. IHMO it should be a fully driver issue Both operations are included in the proposal. 2. Transparent use to push/suck data from the driver using a common data format 3. Capability to push a bunch of CANbus messages in a single system call. The bunch is copied to a kernel domain ring buffer to guarantee low latencies at the user side. A specific kernel thread sucks the ring pushing the user request into the chipset That was discussed before in the context of Socket-CAN. My feeling is that it /could/ be useful in case you have to issue longer streams of CAN frames at high rates, and specifically if your CAN hardware can handle these streams autonomously. Is the 82527 able to do so? In any case, this would complicate the existing stack and driver and would first require careful evaluation of the achievable improvement (lower latency, lower system load?). The i82527 has 15 mailboxes with fixed priority, the lowest one is hardwared to the RX operation. So theoretically you can pipeline up to 14 TX
Re: [Xenomai-core] RTDM 82527 Xenomai driver
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 Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM 82527 Xenomai driver
On 8/13/07, Wolfgang Grandegger [EMAIL PROTECTED] wrote: juanba romance wrote: On 8/13/07, *Jan Kiszka* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: juanba romance wrote: [...] That was discussed before in the context of Socket-CAN. My feeling is that it /could/ be useful in case you have to issue longer streams of CAN frames at high rates, and specifically if your CAN hardware can handle these streams autonomously. Is the 82527 able to do so? In any case, this would complicate the existing stack and driver and would first require careful evaluation of the achievable improvement (lower latency, lower system load?). The i82527 has 15 mailboxes with fixed priority, the lowest one is hardwared to the RX operation. So theoretically you can pipeline up to 14 TX messages. When the stuff is full, we are labeled it as a pileup because the hardware handler has to wait up to get some free one, this operation is performed in our case through the either the mailbox-alarm mechanism or the ISR transmission side . I have mention To be more precise, you have to wait that the object with the lowest priority, #14 has sent it's message, otherwise messages will be sent out-of-order. Obviously if the pipe is full and the last activated one was the #14; We have not take in care in a first approach the message identifier priority, so the bunch sucked from the user ring is downloaded sequentially on the free mailboxes starting from the #0 up to get the #14. A better approach to be implemented in the TX thread would be to sample the current free/available mailboxes, suck the ring and perform over there some ordering before be attached to the chipset. In fact, the mailboxes pool is shared with the static message user map which is always allocated in the top area, so the it's ACK is guaranteed at least for the auto-replier ones. Another issue is the fact that to block a CANbus network transaction(so the full pipe) any node should provide the ACK bit which is OR-wired. This situation means that all the network devices have the RX line broken. This unusual cause means likely a fully broken system, anyway if it is sampled I think that the case must be traced without the hardware feedback; the i82527 has a 96 try mechanism to provide a status interrupt to monitor the fault. This counter may be too later, using 1 Mbit bus rate, take the worst case in terms of message size which is ~100bits, 100usec/message *96 tries, then up to ~9.6ms be the pipe blocked, this is traced in our case through the alarm mechanism but we have decreased the timeout up to 2msec, without have to wait any IRQ flow. The ISR is also coded to have in care about this situation but theoretically the alarm should be triggered before.. Of course decreasing the bus speed the stuff get worse.. the low latency term, cause i have decoupled the loopback-tx feedback from the ISR to a kernel RT thread/task so the ISR only cleans/stops the mailbox software/hardware resources. The user call is only blocked the time required to push the message bunch into the transmission ring. The physical user transmission is performed in open-loop if no error/alarm is sampled.. Note that in RT-Socket-CAN messages are not queued in software nor in hardware for the sake of real-time. Just one message object will be used for sending. I also doubt, that there is a notable performance benefit from sophisticated TX queuing. Wolfgang. I will provide some measures related on Juanba ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
