Hi,

how do you acknowledge the parallel port interrupt after handling it??
I'm using RedHat Linux 7.2, kernel 2.4.4 with RealTime Linux 3.1 extensions...


regards,
Trond

If you find out, please let us know


Hano

Well it turns out it wasn't so difficult after all... I just had to do:

unsigned int par_isr(unsigned int irq, struct p_regs *regs)
{
// do handling stuff here...
rtl_hard_enable_irq(7);
return 0;
}

Which is what I had been doing all the time, but the reason why it didn't work was because of wrong voltage level on the signal I had connected to the ack-pin... Instead of toggling between 0 and 5V, it had a low voltage of -1V, which was enough to stop my computer from fetching the interrupts.. it only got one every now and then, with random intervals. Should have seen that earlier...



-- Trond

how do it works? it's there a bool-like value that return if the voltage has flipped between low / high ? are there any includes to this calls?

Thank you

Hano

Good Day People !
Trond, can you help with parallel port. I began work with it and have many questions and troubles.

First. There so many code - is it slows down PP ? What that "RealTime Linux 3.1 extensions" ?
Second. Have you any examples how to write userspace programs using ppdev ? May be for good perfomance kernel module required ?

Thanks You.

Oleg.

I really haven't got much experience with this, but I'll try to answer the best I can...

Hano:
First you need to install your interrupt service routine (ISR) so that it is called every time an interrupt is issued. To get the state of the various pins, you have to read the par. ports registers, and test the bits corresponding to the pin you're interrested in. If the voltage is high, the corresponding bit will be set to 1, else it will be 0.
I'm not sure, but I think the only pin in the parallel port that is able to generate a hard interrupt is the ACK-pin (pin 10). But you have to allow it to do so first, by setting bit 4 of the par.port control register. (LPT_BASE+2). Using C, that should be something like:

const LPT_BASE=0x378;
int i;
i = inb (LPT_BASE+2);
i |= 0x10;
outb(i, LPT_BASE);

Now your routine will be called every time the ack-pin changes from low to high. (Assuming that you've correctly installed your ISR, using request_irq and so on...)

Take a look at the (online) O'Reilly book Linux Device Drivers, 2nd Edition, for lots of information about interrupt handling using plain linux:
http://www.xml.com/ldd/chapter/book/ch09.html


olecorn:
Generally, if you write time-critical code, depending on interrupts is a bad idea - if you're using plain linux, as it can have a pretty high interrupt latency. One good thing about interrupts is that you're 100% sure not to miss a single one (as opposed to polling), but you can never be sure when it will be handled.. if another (higher priority) task is running, your code won't be executed until the other process is finished, so you'll never know how long it will take from the interrupt is issued, 'til it's actually handled. But, on the other hand, if you're using a realtime os like QnX (or realtime extensions for linux, like rtlinux or rtai), things are a bit different. Take a look at http://www.rtlinux.org for more info about RTlinux, or http://www.aero.polimi.it/~rtai/index.html for info about RTAI. In short, what realtime is all about, is that it guarantees your code to be run when it's supposed to... let's say you have a polling routine that you want to run, say, 10000 times per second... Then it will do so, with precisely 100 uS intervals. Even linux itself gets suspended when your task needs the CPU :-) No matter what priorities the linux tasks may have, the realtime tasks always have the highest possible priority. RTLinux also gives you a very low interrupt latency, usualy (on a fairly new computer) not much higher than microsecond or two. FSMLabs (which are developing RTLinux) says that worst case interrupt latency on a 486/33MHz PC is well under 30uS... so imagine what you can get on a 1GHz+ machine :-) Take a peek at http://fsmlabs.com/developers/white_...whitepaper.htm for a short introduction to RTLinux..


About the ppdev, I'm not sure how to use it.. .I've never used it myself, but you could take a look at the following sites, for some info:

http://www.linuxfocus.org/common/src...205/ppdev.html

http://kernelnewbies.org/documents/k...ook/ppdev.html

http://people.redhat.com/twaugh/parp...portguide.html


Hope it helps...


Good Luck =)

-- Trond

Thanks Trond, that's good to know!


for the realtime issue, another possible approach is to fork your application , where the parent keeps doing the code you doesn't want to wait for the interrupts, and the child reads the interrupts. something like this:

int pid=fork();

while(!END) {
if (pid==0) { //wait here for your interrupts
//write to a pipe to parent
} else {
do your regular loop here and read the pipes
};
};
in this way you're guaranteed to not lose any of the interrupts (everyone is piped and kept in a buffer) but let you do other codes meanwhile)

Regards,
Hano