[lkml]   [2005]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: tricky challenge for getting round level-driven interrupt problem: help!
alan, thanks for responding directly.

the internet is down at the moment (at least, bt's bit is) so
your continued direct responses, if you have the time, greatly

i can't get http or ssh access to _anywhere_, but bizarrely,
smtp is getting through.

[sod bt. royally.]

On Wed, May 04, 2005 at 02:50:01AM +0100, Alan Cox wrote:

> On Maw, 2005-05-03 at 22:56, Luke Kenneth Casson Leighton wrote:
> > it only does level-based interrupts and i need to create a driver
> > that does two-way 8-bit data communication.
> Level triggered is generally considered a feature by people less than
> 200 years old 8)

lots of experience, then, you'd say? my experience with doing this
kind of stuff is kinda limited (doesn't stop me trying) so your
response is really appreciated.

> > i would genuinely appreciate some advice from people with
> > more experience than i on how to go about getting round
> > this stupid hardware design - in order to make a RELIABLE,
> > non-race-conditioned kernel driver.
> Assuming you are using the core Linux IRQ code


> then you shouldn't have
> any great problem. The basic rules with level triggered IRQ are that
> - You must ack the IRQ on the device to clear it either specifically or
> as part of some other process.
> - The device must raise the IRQ again if the irq condition is present
> *at* or after the point of the IRQ ack (or in many implementations 'just
> before' in fact)
> the core Linux code deals with masking on the controller to ensure IRQ's
> dont get called recursively, and ensuring an IRQ gets rechecked/recalled
> on the unmask/exit path if it is still asserted.
> So an implementation is much like a serial port fifo, assert the IRQ
> until the PC has fetched all the bits. In fact the IRQ line is
> essentially "NOT(fifo_empty)" and rechecked each time a byte is fetched.


> *WAY* simpler than nasty edge triggered stuff 8)

bleh :)


i believe i get it: you raise a level-triggered interrupt which _stays_
raised until such time as your fifo is empty.

the original protocol that was written [by somebody even less
experienced than i] was designed the way it is because the PIC chip
that's connected to the ARM only has *one* interrupt.

that interrupt is triggered:

* on a port read (there are four 8-bit ports!)
* on a port write
* by the serial port
* by the timer

[skip this bit if you're busy, it's just background info]

so there's now a _thousand_ lines of hand-written assembly code
which took well over a year to write and debug on the PIC, that
implements the state-machine to deal with the GPS on the serial
port, interleaving the "device status" info into the GPS data
stream, getting the GPS data stream over the 8-bit port and
receiving LCD commands over the 8-bit port, interpreting them
and then feeding the LCD.



assuming that i can handle the pic having only a single interrupt, then
does the process go something like this (for read, e.g.):

1) the ARM unmasks read interrupts when it's ready.

2) when the PIC has data to be read (which is only ever a single byte),
it asserts the level-triggered read interrupt to the ARM.

3) the ARM receives the interrupt, and reads the byte. the _act_ of
reading the byte causes an edge-triggered interrupt to the PIC.

5) the first thing the PIC does in its [one] ISR is to de-assert the
read interrupt. why? because there is only a one byte buffer.

we have an additional step in the chain - step 4 - which is:

4) in the ISR, the ARM goes into a tight loop checking that the
PIC has cleared the level-triggered interrupt.

the reason for checking this is so that when we come out of the
ISR on the ARM, the PIC is *SOOO* slow - it's only 6mhz after
all - that sometimes (frequently, in fact - about 1 in every
50 times) it hasn't got round to clearing the level-driven
interrupt by the time we come out of the ARM ISR (!)

the problem we're having is actually worse than that.

sometimes something goes screwy and _despite_ having this loop-check,
we get duplicated characters.

sometimes, even worse, we lose sync, and the ARM sits there in the

i was getting _so_ fed up with this that i was thinking that there
was a problem with the approach being taken.

hence the redesign to do alternate read-write-read-write, and making
reads exclusive of writes, etc.

awful. just awful :)

... so - in your opinion, alan, is the old approach we had
actually _on_ the right lines?

also, are you going to ukuug in august, it being _in_
aberystwyth and all :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-04 23:03    [W:0.088 / U:2.604 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site