Michael,
you might actually be faster coming out of idle mode than interrupting
a running program. You mentioned being triggered by a timer. My
experience is that you need to add one timer increment to the
theoretical possible interrupt latency based on the time you started
the timer. Often timers work with prescalers, these prescalers could
be running all the time and when you start a timer with 1 us increment
time, it might not be excactly one microsecond until the first
increment. The fastest timer resolution provides the best granularity.
AFAIK, interrupt response time for the fast interrupt, not saving any
registers because there are some dedicated ones, takes 12 cycles from
IRQ to Interrupt service entered (saw that in a presentation from ARM).
hth, Bob
--- In lpc2000@yahoogroups.com, "Michael J. Pont" <Michael.Pont@t...>
wrote:
>
> I'm trying to work out some interrupt response times for the LPC2000
family.
> My main concern is with the response to timer interrupts.
>
> I can work out exactly what the range of response times should be in
> "Normal" (full power) mode.
>
> What about Idle mode?
>
> There won't (obviously) be an instruction executing, so I don't need
to wait
> for this to finish.
>
> Is there any other source of delay?
>
> I don't know enough about the underlying hardware to know what the
> difference is - at a silicon level - between Idle mode and normal
mode, and
> whether it takes time to make this switch.
>
> Can anyone help?
>
> Thanks,
>
> Michael.
>
> PS.
> I can, off course, take some measurements (and intend to do so).
But I'd
> like to have a better understanding of the theory too.