Banjo Spam schrieb: > Do the smilies indicate you are joking? > > In case someone misinterprets this, let me make clear: > TRS is "hooked" to TRMT. TRMT is not hooked to any > interrupt. TXREG is writable, and is hooked to TXIF, > which, maybe obviously, is hooked to an interrupt that > is enabled and disabled by TXIE. Note that the TXIE > enables the interrupt itself, but not the indication > of the TXIF flag. That is to say, it is valid to > disable the TX interrupt with TXIE and still check > TXIF for whether TXREG is empty or not This is ok. I do not want to be disturbed by an interrupt caused when the transmission is complete, so I disable it by 'clrf PIR1'. After having sent one byte will this interrupt source be reenabled??? > Am I clear from your description that with no > comparitor interrupts, the part continues > transmitting? And this also happens with a low number > of interrupts? And as the number of comparitor > interrupts increases, the likelyhood of part freeze > increases? > Yes, this is absolutly correct. A very strange behaviour. If I increase the amount of comparator interrupts by twisting the poti very fast it is more likely that the circuit freezes (waits for TRMT to become hi again which means that the transmission was completed). When twisting very fast the chance of bounces in the poti voltage increases so we are right back at the VERY FAST interrupt rates. > I think the problem is the interaction between the two > interrupts. Your more precise description indicates > that (and I can't see it directly in the code) maybe > the interrupt handler is returning in some cases > (within an inopportune code window) with the wrong > bank, and the test for TRMT is actually testing the > bit in the wrong bank > The bank setting is done in the STATUS-Register which is saved first in the interrupt handler. Are there any affections of TRMT by any interrupt on the chip? I don't see any, but why is the PIC sometimes waiting in vain for TRMT to become hi? regards Markus -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu