[Xenomai-core] Fwd: i82527 CANbus RTDM driver
Hello Wolfgang this is the previous mail thread maintained with Jan and i hope it answer your question -- Forwarded message -- From: Jan Kiszka [EMAIL PROTECTED] Date: Aug 13, 2007 1:13 AM Subject: Re: i82527 CANbus RTDM driver To: juanba romance [EMAIL PROTECTED] juanba romance wrote: On 8/12/07, Jan Kiszka [EMAIL PROTECTED] wrote: Hi Juanba, I won't go much into technical and design details in this reply, because I'm hoping we can continue this discussion on some public list. Xenomai-core e.g.? I think that right now the sources are not too useful in a first public post, may be better to announce in the list that i am developing the stuff and wait if somebody else shows any interest would be better Would you like to re-post? With or without code (there is likely some size limit, so pushing code to a webserver is better)? Of course, yes.. Some questions I'm going to ask then: - Is your API compatible to any pre-existing one? I don't think so, the stuff use specific objects/interfaces of the Xenomai-framework to exchange the control and data flow between the user and kernel address spaces. I was referring to the API the user of the CAN driver sees, not its internal design. On first sight, I don't see Xenomai specifics in the interface. In fact the objects/system calls were selected having in mind the driver capabilities which also income from our previous designs/products around the 82527 chipset Did you consider the *official* RTDM CAN profile? Yes. I study your framework, but to be sincere i think that the capabilities/specifications are too far between. In particular all the stuff related with the remote frame data exchange. The expected latencies and the porting to other frameworks/platforms are also important to the re-usage-design. I have reviewed the official one as a reference to programming with the new symbols set and to check different approaches to solve our stuff. Don't fully get your requirements yet - food for discussion on the public list I guess. If yes and something was missing/insufficient in that profile: Why was it impossible to extend it (so that at least basic CAN operations remain portable, tools can be reused)? I think that two matters were around my mind, time and optimal design. You must consider also the opposite situation. we already have a design implemented with the necessary tools to check/verify/validate; the point is that we like/need to add it real time capabilities. This implementation/ideas ha/s/ve been ported from things like uclinux-mcf5282, linux-i386 including also MC51 micro controllers. See, Socket-CAN is close to mainline Linux, and RT-Socket-CAN (ie. RTDM's CAN profile) is compatible with it, just making it deterministic under the hood. Older CAN frameworks for Linux, including commercial ones, will more and more become obsolete. If there are technical deficits, specifically compared to pre-existing approaches, _that_ would be very interesting to discuss with the aim to improve the design wherever feasible. Maybe it turns out that certain scenarios simply require different approaches. But as long as deficits aren't really discussed and, at best, quantified, we make no progress. Other important issue is my time and the required one to write the sources following the profile specification, which must be also fully understood. i.e. the sources don't consider at any stage the 11 and 29 bits stuff, our application is 29 bits focused on, so the stuff is removed I mean, we need to have the driver ready to the application purposes ASAP and this could be contradictory also with other generalist issues. Of course, I assume that i.e. that fix will be easy but i like to clarify that this kind of things are minors from our point of view. The documentation that i need to build any case, will present these design issues in terms of functional operation and provided tools. Looking forward. What are your plans with the driver? How/where are you planning to maintain it? Right now i am worry about it's reliability on stress. This is one of the things that we have checked once and again at our company, a design is proposed, implemented, verified and validated but not under the worst case when all the software is fully weird, then the people cry. To be honest i haven't thought about the external issues in terms of maintenance, this is new for me. If the Xenomai crew like the stuff of course your control version repositories would be the best place. At our For Xenomai integration, we either need a patch against the existing stack, enhancing it in favour of creating a second one. Or we need evidence that only a different approach is adequate for certain CAN controllers and/or CAN applications. company we hold the driver stuff as much as possible, all the changes are biased to the application level, we don't add too much functionalities in the kernel space from the validation stage
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
[Xenomai-core] RTDM 82527 Xenomai driver
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: 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 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 4. Driver readout using a native RT message queue where the control and data flow is published 5. Multichipset capabilities, right now a commercial PC104 board with two devices is used. The on board CPU is a SBC VIA C3 1GHz processor softwared with the stack xenomai-2.3,1/vanilla-2.6.20-15/Adeos- ipipe-1.7-03 6. board monitoring through the /proc file system entry 7. Local Data Transfers controlled with RT-alarms 8. Virtual support to check applications/driver usage/design, right now only the chipset is virtualised, but plans to have network transactions are on going 9. ISR hardware optimizations focused on the network readout to gurantee low latencies 10. Easy porting to other i82527 based on boards 11. Full transmission operation handling the 16 message object set We have in plan also 1. Capabilities to filtering/masking the incoming flow at the driver stage allowing that the same context, using the xenomai nomenclature feed specific threads using some kind of binding/configuration process. This is an open issue cause i don't have a clear approach to follow.. 2. can-festival coupling I think this is the full picture, i look forward.. Best regards.. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
