[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Problems when polling interrupt register
I would suggest that you don't use any polling at all. The standard
approach would be to use blocking reads. In a blocking read the following
1. The application calls read on the device
2. The device driver detects that no data is available and puts the
application on a wait queue
3. The interrupt is received
4. The wait queue is signaled and the data is returned to the application.
This approach also implies that several bytes can be buffered in the device
driver between each read from the application.
>Do you think this is possible? If so, can I request the interrupt as
>SA_INTERRUPT and avoid that the interrupt is interrupted?
SA_INTERRUPT means that the interrupt itself is not shared between
different devices. It has nothing to do with if interrupts are enabled
or not. Constructions like the following code can be used to make
sure that you are not interrupted.
unsigned long flags;
Also note that the normal interrupt handlers already has interrupts
disabled while processing. If you need to do much stuff in the
interrupt handler you should register a bottom-half handler to
avoid locking out the interrupts too much.
>Where can I connect the interrupt pin on the chip to the developer board?
The Port A pins can be used for interrupts. The Port A pins are available
on pin headers on the card (refer to schematics). Note however that some
of these pins are controlled by the serial transceiver. If you don't use
serial port 2 you can for example use PA4.
Behalf Of Jonsson, Marcus
Sent: Thursday, September 27, 2001 12:25 PM
Subject: Problems when polling interrupt register
I really hope that someone can help me with this one. Sorry if you have received this mail twice, but I have had some trouble with the subscription of the list.
I'm using the Developer Board LX's parallel ports (both of them) in manual mode
to communicate with a chip. To do this I have followed Axis example of how to
write a device driver. The driver only takes care of the write and read
operation of bytes and has no part in the actual addressing within the chip. The
rest of the work is done inside the application, i e in user space.
Instead of using the interrupts in the chip, I have used polling to check for
events. When data is ready to be read on the chip, a Data In bit is set in an
interrupt register. By reading the register the bits are cleared. This register
is being continuously polled when a read operation is carried out. This may have
caused some problems because sometimes this bit is lost (the whole register
value actually). I have spoken to the manufacturer of the chip, and they say it
might be a problem of rescheduling of the process within the actual read operation of the
register, and because of that the value of the register is lost.
Do you think this might be the case? If so, is there an easy solution?
I have been thinking that one solution might be to use the interrupt signal of
the chip and let the driver read the interrupt register and store it in some
variable. Then the application can poll the driver instead of the register by
using an ioctl, or something. This way very little has to be rewritten in the
Do you think this is possible? If so, can I request the interrupt as
SA_INTERRUPT and avoid that the interrupt is interrupted?
Where can I connect the interrupt pin on the chip to the developer board? I have
thought about using the nmi external interrupt pin, but it seems to be
hard-wired high, and if possible I would like to avoid making any permanent
changes on the board.