Am 03.09.2013 um 05:43 schrieb Steve Stallings <steve...@newsguy.com>:
> I have always believed that a much better system would > result if the real time interrupts were driven from the > actual hardware that was collecting the feedback and > applying the driving functions. Yes, this means that > the real time system cannot run if the drivers for the > hardware don't correctly supply the interrupts, not necessarily. I would think this is a thread creation option; either you supply a period which is the current case, or you supply an event descriptor the RT task has to wait on before the next cycle. The issue IMO isnt so much providing that option and adding that to threads.c - and again, to motion :-/ - but rather arriving at a sufficiently general event descriptor which can cover many platforms, and map that event descriptor on a wait method across RTOS and hardware platforms. This would become the conditional replacement for this rtapi_wait(): https://github.com/mhaberler/linuxcnc/blob/unified-build-candidate-3/src/hal/hal_lib.c#L3060 . Depending on hardware platform you might have everything from a IRQ number (say 7 for parport) to a descriptor including a say GPIO pin number, an edge selection (provided thats possible), and an IRQ number ontop. Or permutations thereof. An extra wart will be coordinating IRQ vectors with existing driver usage, for instance the parport* modules. I'm not fully รก jour how the hal_parport interacts with the parport* modules re IRQ's, if at all. This is a serious hardware, RTOS and build dependency (kernel code becomes mandatory to do this). I'm pretty sure how this can be done reasonably portably with Xenomai (an RTDM device driver); a parport interrupt example exists as a cheat sheet: http://git.mah.priv.at/gitweb?p=xenomai-irq.git;a=summary , and various examples for GPIO handling float around on the net. If someone else can come up with a kernel module which implements this IRQ wait function for RTAI (for a bare RT task, that is - RTAPI usage not needed) and RT-PREEMPT (probably a simple driver with a wait on read() or ioctl() will do) I'd be willing to give it a stab by papering an RTAPI abstraction layer over the setup and wait code. - Michael > but it > is worth the effort in my opinion. > > Steve Stallings > > >> -----Original Message----- >> From: Jon Elson [mailto:el...@pico-systems.com] >> Sent: Monday, September 02, 2013 11:01 PM >> To: EMC developers >> Subject: [Emc-developers] proposal for capability of external >> interrupts totrigger HAL threads >> >> I'm not sure theis is the right method to bring this up, but... >> I have had some discussions with Michael Haberler about having >> the capability for making HAL threads triggerable via an >> external interrupt. Apparently, there was a partial capability >> in an early version of rtapi, but it was removed, possibly because >> it didn't work. >> >> Anyway, my line of interface boards have always had the capability >> of sending an interrupt pulse through the parallel port on a regular >> interval of 1, 2 5 or 10 KHz. These boards also sample the encoder >> position in hardware at that time, and exchange signals on the >> parallel port bus so all boards sample within 1 us. Since this >> was not supported in HAL/rtapi, we have not been using this >> feature, so the hal_ppmc.c driver does the sampling by a software >> command. This causes some jitter in the sampling time. On an >> X86 machine with decent latency performance, this has been OK, >> but not optimal. Since we are now contemplating moving to >> other platforms, such as the BeagleBone, with somewhat worse >> latency jitter, and having to rework rtapi to adapt to other RT >> packages such as Xenomai, this might be a good time to >> explore whether triggering a HAL thread via external interrupt >> is possible and/or desirable. I would certainly like that option, >> as it would reduce position sampling jitter to sub-ns levels for >> one board, and no more than 1 us ever on multiple boards. >> Michael has some other reasons for allowing external interrupts >> on some systems, but doesn't want to go all the way through to >> HAL threads with it. Does anyone else have thoughts on this, >> or want to be able to trigger HAL threads externally? I can >> imagine some other projects that might benefit from this. >> >> Thanks for any thoughts, >> >> Jon >> now >> >> -------------------------------------------------------------- >> ---------------- >> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! >> Discover the easy way to master current and previous >> Microsoft technologies >> and advance your career. Get an incredible 1,500+ hours of >> step-by-step >> tutorial videos with LearnDevNow. Subscribe today and save! >> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/414 > 0/ostg.clktrk >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
