I visited fosdem.org/2014/ in Brussels last weekend. The following might be relevant for LinuxCNC:
- the LTTNG project (Linux Tracing Toolkit Next Generation, http://lttng.org/quickstart). This was a low-overhead mechanism for kernel tracing only, and recently has been extended to support userland tracing with hires timestamps AND correlated kernel system call traces. In combination this should be a great tool to isolate causes for RT delays; it is certainly usable for RT-PREEMPT and very likely usable for Xenomai userland threads *). Unused, there is practically no overhead, meaning tracing support could be left in production code and activated as needed. Liberal licensing. Since the tracing mechanism has needs very similar to RT/non-RT communications, the code is an interesting read (libringbuffer, userland read-copy-update support). Worth exploring - I'll post the slides as soon as I get them from the speaker. - the picoTCP embedded TCP stack: https://github.com/tass-belgium/picotcp - usable on non-Linux bare metal/FreeRTOS style platforms and has early-stage zeroMQ support. Downstream this could help adding intelligent remote HAL components which plug in like everything else - i.e. without resorting to inventing-your-own-wire-protocol-over-serial and that kind of legacy in the making. I managed to get these fellows to see the light on the upside of the zeroMQ/protobuf/nanopb base which we'll be using, and I guess there might be even examples forthcoming eventually in this tree. GPL2only. They say they have customer demand for zeroMQ support so it's likely to happen in usable form, and remain usable. Whether bare metal ala AVRmega 128k platforms and above still make sense visavis a $35 full-blow-realtime Linux platform like the BBB remains to be debated, but it is good to know to have a downwards option which retains the end-to-end principle **). Personally I'd rather go with a BBB type platform and skip the pains of embedded programming and debugging, unless pointed at with a gun - and the economics dont work out either. But then these guys are addressing an 'Internet of Things' type market, which might be below what is economically justifiable in this context, at least for now. - contacts - I got in touch with some folks driving, using and relying on Xenomai and its networking support, and got a better picture behind that project an who puts which resources into it (or not). In terms of 'extending horse options beyond RTAI' it is safe to say we barely made it in time. There seems to be no discernible industrial followers of RTAI, other than RT-PREEMPT and Xenomai which have substantial life in them ***). However, both the RT-PREEMPT and Xenomai efforts face a tragedy-of-the-commons situation: used by many, but stretched on resources to get the effort mainline and self-sustaining. I have the feeling the proponents of both projects have an issue to address the relevant decision makers: in terms of the overall market size of RT Linux applications, we're talking change, like a low-digit number of million at best. Let me put it this way - it's good to have a horse to ride - any horse in fact. Just dont look at that butt;) What I wasnt fully aware of: the current Xenomai 'cobalt/mercury' effort is about source compatibility for RT applications, with the RT kernel exchangeable underneath, like Xenomai or RT-PREEMPT. So rather similar to what we did. This doesnt say however the ub effort is superseded - cobalt aint there yet, it's just a further option downstream. It might make sense to clue up on whats happening there. - a great punchline: "legacy as a service" ;) I was at this (un)conference for the first time, and found it very inspiring. Lots of creativity and talent in a single spot (7000 attendees). - Michael *) I am unable to tell how that relates or interoperates with the Xenomai ipipe tracer; I rather guess not at all **) http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf - part of the Ten Commandments I follow ***) I hope nobody needs an MRT scan. However, if one does, and it's a Siemens device, that device runs Xenomai. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
