Re: [Simulavr-devel] two things

[John Regehr]

> What actually causes the interupt to fire may not even be related to the
> register that contains the intr enable bit.
>
> Can you expand on your idea a bit? How do you envision the extra info
> helping simulavr fire off an interrupt?

Well, there is going to be some device-specific code that decides when
it's time to signal an interrupt, and at that point simulavr needs to
decide whether to jump to the interrupt vector or not.  I thought it might
make sense to factor out this decision ("does the interrupt fire or remain
pending?") rather than duplicating this logic in the interrupt code for
each device.

So for example, the firing condition for the TWI interrupt is:

  (SREG & 0x80) && (TWCR & 0x01)

Of course all interrupts have the first part, but the second is specific
to TWI.  I'm looking to factor out the connection between TWI and the TWIE
bit into a table somewhere.  It's probably also worth factoring out the
connection to the "flag" bit that corresponds to each interrupt vector:
the I/O bit that gets set when the interrupt wants to fire, which Atmel
thoughtfully provides in case we've decided to go with polling instead of
interrupts.

So to summarize: we can divide the work of dealing with interrupts into
(1) device-specific logic that decides when to fire and (2)
processor-specific logic that decides when to actually jump to the
handler.

John Regehr