On 1/24/2013 2:48 AM, Bas Laarhoven wrote: > On 23-1-2013 23:25, Charles Steinkuehler wrote: >> On 1/23/2013 1:33 PM, Bas Laarhoven wrote: >>> On 23-1-2013 19:52, Michael Haberler wrote: >>>> Am 23.01.2013 um 16:17 schrieb Bas Laarhoven: >>>> >>>>> Since you have experience with patching xenomai on top of a kernel, >>>>> is there any chance applying the patches on the 3.2.34 kernel? >>>>> You can download that kernel from >>>>> https://github.com/modmaker/linux/tree/linux-ti33x-psp-3.2.34-r18a+gitr720e07b4c1f687b61b147b31c698cb6816d72f01. >>>>> >>>>> The link might not work directly, but it contains all the relevant >>>>> information to find the branch in my kernel tree. >>>>> >>>>> The advantage of this kernel is that it contains the relevant >>>>> drivers for GPIO, PWM, ADC, PRUSS, etc. It also contains the EEPROM >>>>> based configuration decoder that I wrote. It's used by my BeBoPr >>>>> board to automatically configure the I/O, so one doesn't need to >>>>> load drivers, set the multiplexers and so on (Charles: This might >>>>> save you a lot of work!). >>>> I am now looking into it, and I am not so sure about the last >>>> paragraph. >>> ??? Huh, I'm not sure if I understand what you're saying here. Do you >>> think the TI branches are better., is that what you're saying? Then I >>> suggest that you read back the IRC logs on #beagle over the last year. >> From my perspective, the fancy BeagleBone specific kernel bits that Bas >> is wanting are not particularly necessary for LinuxCNC. > Charles, > The capes have an EEPROM containing configuration information that is > used to configure the BeagleBone's I/O when the kernel boots. If you > want (or need) to do that yourself, that's of course a choice you are > free to make. It's indeed fancy, and user friendly : )
I know about the EEPROMs on the cape boards. I agree it's a useful feature, but it's far from a mandatory kernel feature required to do anything handy with the 'Bone. >> Running under Xenomai, we can't call into the Linux kernel to update >> anything without a severe latency hit, so we'll have to talk to the raw >> hardware anyway. It's easy enough to talk to the PRU directly since >> it's unused by Linux, but some of the other hardware (like the ADC and >> PWM) is a bit trickier. I'm actually hoping I don't have to *disable* >> the Linux drivers for the AM335x hardware to keep the kernel from >> stepping on registers while we're talking directly to the hardware via >> Xenomai/userspace. >> > Ah, it wasn't clear to me that you were going to do all the low level > stuff yourself. > Is this necessary? Can't you use the standard drivers for the not time > critical parts? > If not, I hope you're an expert and have lot's of time to spend ; ) I may be able to use some of the Linux drivers. The problem is if any of the real-time code executes anything that results in a kernel syscall (for instance to do a write to a sysfs file), the real-time performance guarantees provided by Xenomai are lost and the code is at the mercy of the Linux kernel for latency. That's one reason I like the PREEMT_RT patches (but they don't perform as well as Xenomai and are less available for the ARM). -- Charles Steinkuehler char...@steinkuehler.net ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
