simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] two things


From: Theodore A. Roth
Subject: Re: [Simulavr-devel] two things
Date: Wed, 19 Nov 2003 22:53:06 -0800 (PST)

On Wed, 19 Nov 2003, John Regehr wrote:

> > 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.

I need to dwell on this a bit more but my first impression is that I like 
the idea. I think it will mesh well with a change I've been mulling over...

I'd like to change the IO register mapping to a lookup table instead of a 
linked list (shoud have done it that way in the first place). That would 
make your change more efficient. Both changes may make the peripheral 
specific logic simpler since it just needs to figure out if the intr should 
be added to the pending list (although, I think that's all that it should 
be doing now any ways).

I've started on my change, but have progressed very far. Plus I've got to 
get some pending patches reviewed and committed first.

Have started implementing this yet?

Ted Roth





reply via email to

[Prev in Thread] Current Thread [Next in Thread]