Post by thread:[PIC]: Interrupt USART + TMR0 Fast int architectu

Jan-Erik Soderholm wrote: > Bob Axtell wrote : >>3. INT adds a lot of overhead. If all you need to do is set a >>few flags in global registers, there is no need to save W, >>status, FSR, or PClath if all you need to do is set a few flags. But the moment you have to move anything around (Rx characters) you're forced to save and restore everything. {Quote hidden}> > And, on the PIC18-line, that (saving of the "important" regs) > is done on the fly without any extra cycles. So *very* short > ISR's can be much faster on the 18's then on the 16's (if you > need the context saving). > > And, yes, this doesn't work well (or at all) if you use both > interrupt priority levels, since there is only one set of > shadow context registers... Well, you can't get everything, > can you ? :-) :-) Sure you can. Use a different processor family<G>. So the 18's are only 'half baked' since they should have had TWO sets of shadow context registers if there are two levels of interrupt priority. Wasn't it the TI TMS9900 that had a hardware register which pointed to RAM where ALL the other registers were kept as offsets from the base pointer. Changing context meant adding or subtracting the register count from the registers pointer. One could have multiple threaded and reentrant code by simply managing the registers pointer. I never programmed them but remember looking at them back in the 80's and thinking, 'nice way to do it'. Robert

Robert Rolf wrote : > Wasn't it the TI TMS9900 that had a hardware register > which pointed to RAM where ALL the other registers were kept > as offsets from the base pointer. And the SUN Sparc processor series, just to mention a current one. If I don't remember wrong, it used a 16-reg "window" from a 128 register "file" as the working regs. One pointer moved the window up and down the file. Jan-Erik.

Robert Rolf wrote: > So the 18's are only 'half baked' since they should have > had TWO sets of shadow context registers if there are two > levels of interrupt priority. That's only one side of it. The other side is probably more cost. It seems reasonable to me to put extra hardware resources to a separate high priority interrupt, and let the lower priority interrupt handle context saving in software. At least it doesn't sound "half baked". > Wasn't it the TI TMS9900 that had a hardware register > which pointed to RAM where ALL the other registers were kept > as offsets from the base pointer. > Changing context meant adding or subtracting the register > count from the registers pointer. One could have multiple threaded > and reentrant code by simply managing the registers pointer. > I never programmed them but remember looking at them back > in the 80's and thinking, 'nice way to do it'. Yes, the 9900 did have such an architecture. They were also considered rather slow for their day. Everything is a tradeoff. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

> > Wasn't it the TI TMS9900 that had a hardware register > > which pointed to RAM where ALL the other registers were kept > > as offsets from the base pointer. > > And the SUN Sparc processor series, just to mention a > current one. If I don't remember wrong, it used a 16-reg > "window" from a 128 register "file" as the working regs. > One pointer moved the window up and down the file. But in the case of the Sparc that entire register file was on-chip, with the typical speed of on-chip regsters. In the case of the 9900 the 'registers' were realy in RAM, with the speed disadvantage of off-chip access. But in those days the speed gap between on-chip and off-chip was much smaller. Those were the days! I was 16, I had never even seen a computer but I enjoyed reading the descriptions of all those weird CPU's in the Osborne books. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

>>3. INT adds a lot of overhead. If all you need to do is set a >>few flags in global registers, there is no need to save W, >>status, FSR, or PClath if all you need to do is set a few flags. >But the moment you have to move anything around (Rx characters) >you're forced to save and restore everything. Maybe. It depends how your non-interrupt code is set up. It may actually be more efficient to disable interrupts around code that is handling the FSR when reading bytes from a buffer, for example, and then you do not need to save the FSR inside the interrupt routine. This may even give you shorter average latency, and will save you other hassles, like race conditions between the mainline and interrupt code.