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.
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)
--
it would be valuable to discuss and reviews API's in linuxcnc on a broader
scale, for instance a decent abstraction of the motion command and status
interface. That would potentially have a lot of mileage.
another open question in this context is how to handle different architectures,
as we are departing from the Ford-T style of choice ('you can have Linuxcnc on
any box provided the box has a PC motherboard running RTAI inside' ;). Probably
the linux kernel has some guidance to give here.
I would think in the future 'abstraction' should have more weight in the sense
of 'abstracting over different architecures' than over 'abstraction of over
various of x86PC+RTOS combinations'.
- Michael
> My boards have the
> capability
> to provide an interrupt through the parallel port. They are capable of
> sampling encoder position to latches and then interrupting the CPU to
> read the position and do the servo loop. If it could then interrupt the
> CPU, you could have latency jitter of a couple hundred ns, as long as the
> servo thread completed before the next interrupt.
>
> Jon
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
