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 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 is set and, if it is, it forces the XT you set with int! for the given vector. Sounds good. However, it seems like using reti in the generic ISR is a bad idea. When an interrupt fires, the AVR clears the global interrupt enable in status and it stays clear until the reti. But that means you could get a nested interrupt which would cause the previous interrupt to be dropped. I changed the reti to ret and then, of course, my "Forth" handler has to execute +int before it exits to get interrupts back on again. I also added a few lines of code so that if the Forth vector is 0, it doesn't try to execute it. This all seems to work (although I'm having another apparently unrelated problem with the code I actually want to write). Is there any downside to this? It seems like nesting interrupts would be Very Bad unless you have a way to keep a queue of interrupts pending, for example (which would be another neat project). ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Amforth-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
