> And it works for all cases where the hardware does not need to be reset
> to some "interrupt-handled" state. e.g. some interrupts need to be
> cleared somehow (mostly by reading one or more bytes from pre-defined
> IO registers). If that is _not_ done within the ISR, the interrupt will
> re-fire
hi Al,
>
> Howeer, if you use int! to set a "Forth" interrupt vector, the default isr
> sets the "T" flag when an interrupt trips. It also stores the current vector
> in
> a location where the interpreter can find it.
>
> When the interpreter is about to dispatch it looks to see if the T flag
> Bad unless you have a way to keep a queue of
> interrupts pending, for example
> (which would be another neat project).
yes, a queue e.g. 8 vectors deep, then you must not care on T - when
q. not empty then int. has been fired, and forth will process them
in an order.. mind latency of forth..
P.
So I've been working with input capture interrupts today. I see that the UART
interrupts don't use the "Forth" system -- they just reprogram the vector and
use assembly.
Howeer, if you use int! to set a "Forth" interrupt vector, the default isr
sets the "T" flag when an interrupt trips. It also
