-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/4/2012 10:03 AM, Michael Haberler wrote: > > Am 04.11.2012 um 15:44 schrieb Jon Elson: > >> On 11/03/2012 08:55 PM, Charles Steinkuehler wrote: >>> While it looks to me like all the HAL code currently runs on >>> system timers, I intend to drive the HAL timing from >>> lower-level processes (either real hardware or the real-time uC >>> on the AM3558) via Interrupts, so I *WILL* want the ability to >>> declare an ISR and hook it to a DPC or have it wake a thread >>> based on a physical IRQ event. >> Yes, I also suggest keeping this in, if possible. > > First, nothing ever is lost in git. > > I, and likely the other folks working on RTOS ports are > unenthusiastic about porting unproven greenfield API's which have > not been used since inception, and likely remain so. I'm not > talking peanuts here - its over 2000 lines of dead code (fifo, sem > + irq) which are supposed to be read, understood and adapted, and I > dont see the volunteers banging the gates to do that just yet. > > If RTAPI irq's are considered important than I really wonder why > they have not been used so far. I would be hard pressed to find > any peripheral which does not have an interrupt capability but for > some reason they are mostly unused in linuxcnc; my conjecture is: > for the way HAL+RTAPI works, interrupts dont have a lot of > advantages to start with or else we would find more of them in > *used* code. 'grep -ri irq hal' says a lot. > > The stuff which is *potentially* needed most going forward is > *userland interrupt support*, which is exactly what is *not* > provided by the RTAPI irq code. > > My suggestion therefore is: > > you guys come up with working interrupt-driven code, and then we > will see if an API abstraction is worthwhile, and how it should > look > > there is a big chance that there's no point in abstraction > altogether because it's architecture-dependent to start with, or > the 'abstraction' turns out to be a boatanchor of an ifdef maze > catering for various RTOS flavors (been there - thanks, but no, > thanks). > > If there's still a case, there's a good chance it will look quite > different from the existing one. > > NB: I'm not saying 'no IRQ's' - I say: no more deadwood going > forward, we have too much of it.
All excellent points. Go ahead and chop away...I can review the existing IRQ code via git if necessary, but I suspect my time will likely be better spent finding *known working* examples of IRQ code online vs. the existing code which was last used or tested who-knows-when. When I piped up about keeping the code, I didn't realize just how unused it was. > Btw, the part of the new code which needs review and test cases > more urgently is the RTAPI PCI and I/O remap code. Can I encourage > the hardware manufacturing section of the Linuxcnc community to > look into this issue? (in your own interest.. you just dont want > types like me fumbling with PCI stuff) I'll see if I can help out with this when I start trying to talk to new hardware on the BeagleBone. First, however, I've got to get some infrastructure built up so I can start hacking. *wanders off to build yet another development environment* - -- Charles Steinkuehler [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCWpzIACgkQLywbqEHdNFyI7ACbBN5ziHOWBVKN4gaMl/HZ0Hsx euQAoOqWhXk3+DTzEQFkl5yj4bUgn9oK =QngW -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
