Sebastian Kuzminsky wrote: > A recent thread on emc-users discussed the value of hal drivers having > dedicated functions to read & write the gpios, without reading & writing > everything else (ie: encoders, stepgens, pwmgens). The utility of this > interface is clear. This interface is easy to provide for hardware > where the I/O is threadsafe, such as PCI cards, but it's harder to do it > on hardware where the I/O is not threadsafe, such as EPP. To ensure > atomicity in RTAI of the EPP address cycles and the subsequent EPP data > cycles, the driver must turn off interrupts. > > > I've implemented this and it works well. The code is in my experimental > hostmot2 branch here: > > <https://code.launchpad.net/~seb-highlab/emc/hostmot2> > > The interesting bits are in hm2_llio_read() and hm2_llio_write(), > starting on line 649 of hostmot2.c: > > <http://bazaar.launchpad.net/~seb-highlab/emc/hostmot2/annotate/473?file_id=hostmot2.comp-20080324150436-3zy8ulsbxdch5jua-5> > > The code turns off interrupts before starting an EPP transaction and > re-enables interrupts when the transaction is finished. (It only does > this for the EPP boards, the PCI boards dont need it.) > > > A typical EPP transaction for this driver consists of two address cycles > and 16 data cycles, for a total of about 20 or 25 microseconds of no > interrupts. It occasionally (rarely) spikes as high as 75 microseconds. > > > There's a judgement call here, and I seek your advice. Is 25 > microseconds too long to run with interrupts off? >
Like everything, that depends on your application - servos are more forgiving than steppers. But IMO, yes. Disabling interrupts for X microseconds directly adds X microseconds to the latency/jitter times for the machine. A PC with 25uS of latency is not a very good realtime machine. One that occasionally spikes to 75uS of latency is not good at all. What makes this situation subtly worse is that the user will have no clue about this latency. When he runs the RTAI latency test, the driver won't be loaded, so the latency that it causes won't be detected. The user might run the latency test, get a 15uS for a result, determine his max speeds accordingly, then start EMC. But every once in a while he will get latencies twice as large as he did in the test. If he is doing software stepping or software encoder counting, he'll either be losing steps or skipping counts, and have no idea why. I have no doubt that this approach can be made to work reliably, IF everything is carefully documented, and every user understands the implications. I also have no doubt that even if somebody overlooks something it will work 99.999% of the time. However, there is no way I want to try to debug that remaining 0.001%. There is nothing worse than the bugs that happen only when event A happens in a narrow window between events B and C, and this seems like on of those situations. It might seem like an overly pessimistic view, but I'd rather forgo the fast GPIO updates on the EPP connected Mesa cards, than risk introducing latencies that could affect completely unrelated stuff. For example, consider the Mazak at the CNC workshop - I used it to argue for fast GPIO a few days ago, but it is a perfect example here as well. The Motenc-Lite board is accessed only from the servo thread, but we do software encoder counting in the base thread using a regular parport for the jogwheel. Supposed we decided to replace the Motenc with a Mesa 7i43 (through a second parport in EPP mode). We would still be accessing the Mesa only at the servo rate, but the driver would disable interrupts anyway, which would hurt the latency for the completely unrelated jogwheel counter. I'd rather be obsessively consistent - never disable interrupts and never block in a realtime thread. Regards, John Kasunich ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
