-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/27/2012 12:42 PM, Michael Haberler wrote: > can you say anything about the *LinuxCNC* source level changes > which happened, in particular to rtapi and hal?
Well, I'm no expert on LinuxCNC or the PREEMPT_RT kernel, but I was one of those working on getting a PREEMPT_RT version of LinuxCNC working a while back. Somewhat crude directions can be found on the wiki: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC As mentioned, the patch set is fairly small. In crawling through the change-set looking for what turned out to be a crashing the stack pointer bug my impression of the major changes from the virgin LinuxCNC code (all from memory): * A new real-time back-end was added (rtapi wrappers for PREEMPT_RT) * The basic configuration of LinuxCNC for PREEMPT_RT looks almost exactly like a simulator build, since everything is now running in userspace. * Various HAL modules were modified to reflect that they are now running as userspace code instead of kernel modules, requiring minor tweaks to get them to compile. ...and that's really the bulk of what changed. It's not a lot. Anyway, since the PREEMPT_RT stuff started running a while back, I haven't spent much time on it. That is hopefully about to change, as I now have completed upgrading my test system and now have a working mechanical test platform (my 3D printer). I now have three different options for control I can switch between: 1) USB connected Arduino (typical RepRap setup), that doesn't involve LinuxCNC at all. 2) Traditional RTAI LinuxCNC build from the Ubuntu install CD. I have this driving the motors (software step-gen), but have not yet gotten the temperature feedback and control implemented. 3) Debian Wheeze PREEMPT_RT kernel with LinuxCNC PREEMPT_RT. I need to fire this up and see how motor control compares to the RTAI version, or if it can even talk to the parallel port! - From my looking at Arm chips, they don't seem like a worthy candidate for LinuxCNC. The latency is horrid unless you can hack something onto the fast IRQ which likely isn't going to support something as complex as HAL. Another option would be using one of the Arm chips on an FPGA (or a soft-core) and implementing the motion control in hardware, but with the horrid Arm IRQ latencies even that might not work well. - -- Charles Steinkuehler [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9F6cACgkQLywbqEHdNFw9bgCdEcDrID9dveAdO44W7bXXJZr8 i+cAoJLbEajN4ffWaXnZcNFhV2Xxkk4E =tK19 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
