Hi Enoch, > My editor (Emacs) apologizes. It does not like your asm code > indentation. Which one do you use, BTW.
Uhm. my own one. And a different one for each file. Probably. ;) > > > Second: Your patch steps behind what amforth has already > > solved years ago: If an interrupt source has to be cleared > > *within* the ISR, it will block the controller with your new code > > In my soft interrupts handling scheme I am interested in Atmel's type I > interrupts only. They are described by Atmel as follows: > > """ > There are basically two types of interrupts. The first type is > triggered by an event that sets the interrupt flag. For these > interrupts, the Program Counter is vectored to the actual Interrupt > Vector in order to execute the interrupt handling routine, and *hardware > clears the corresponding interrupt flag*. > """ > > The other type, like the USART, does need special asm code. Your serial > driver is a case in point. And this is the major concern I have with your patch. I dont like the idea of having two different interrupt handlers for subtle different interrupt classes. In your notation, all amforth interrupts a first level interrupts. May I suggest, that you implement the second level interrupts just like they are described in the wikipedia: as a thread for the multitasker (see below). I should re-write the usart handler with forth code instead of the assembler, nobody seem to believe me that it will work ;) > > I once spent a lot of time to deal with the reasons. I wrote > > a small article for the German Forth Group, unfortunatly (for you) > > in German. It seems, I should translate it into (my version of) English > > ASAP. There I explain the current interrupt handling in more detail. > > Google Translate does magic, please forward a link. http://www.forth-ev.de/repos/vd/2011-02/Interrupts.tex > Note that there is an overflow mark. If the developer encounters hard > interrupts overflow he should increase this queue size (or check up his > code). This can be done through some asm .equ convenience. IMHO a little too late. The interrupt was lost. > Did you really try it, i.e., reenabling interrupts within an ISR? You > do it and your 'intcur' gets crushed. Its difficult to test. The program flow indicate that it should work: An interrupt occures. The current interrupt handler sets the T flag and the program flow continues. Soon after the forth VM is entered and detects the T flag. Everything with disabled further interrupts so far. The inner interpreter immediately calls the forth-ISR and both the T-flag and the curint information is no longer needed for the whole forth ISR word. Thats why I think that that re-enabling interrupts within the Forth-ISR is safe and does not cause any trouble. The only place that IMHO may be casue trouble is the final ISR-END which calls RETI. That may have to be expanded to something that checks the GIE flag to either call RETI (if set) or a simple RET (if cleared). But my impression is, that RETI is smart enough to handle both cases itself. I should re-read the datasheets ;) > After receipt of a data buffer from a certain communication euipment I > want to lanuch immediately a processing activity, i.e., right from the > ISR and not wait for a round robin task to visit. You can implement a priority task scheduler as well. PAUSE is not the ultimate tool for everything ;) Matthias ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
