In the isr keep things simple. When a uart interrupt occurs, copy the received byte to a RAM location, or even better, a circular buffer. Outside of the isr other routines can check for the data that has been placed in the RAM/buffer. Disable the interrupts for the few cycles it takes to access the data, then re-establish interrupts. ISR based routines can communicate with flags or communication bytes in RAM, such as the positions of the head and tail of the circular buffer. When a routine uses these resources it is responsible for leaving them in the proper state. For example, if a byte is removed from a circular buffer then the "tail address" byte would be incremented/decremented accordingly. BTW, if you have a timer-based interrupt that occurs once every ms, you can have it maintain several different software counters that count down and stick at 0. A user can shove a value into the counter and when the counter is at 0 you know X ms have elapsed. I generally have the interrupt also maintaining a single byte counter that does NOT stick at zero. Watching bit 0 of this counter tells you when a 1ms transition has occured so you can synchronize the loading of your "sticky" down counter. A "free running" byte UP counter can be used to do on-the-fly timing. Capture its value, add that to the time delay you want, then when the free running timer matches that value, you know X ms have elapsed. (If you don't synchronize, then error can be up to 1 ms) Fr. Tom McGahee ----- Original Message ----- From: "Edward Cooper" To: Sent: Thursday, March 25, 2004 12:20 PM Subject: [PIC:] Multiple interrupt handling > Hi Piclist > > I have some code which handles a string from the serial port in the ISR > (using USART receive interrupt), effectively hanging the processor for > a short time. During this period I will have multiple TMR0's occurring > of with I can't miss one because its using them to rack up a timer (in > milliseconds) for a time critical process. > > Now I'm not entirely clear if another interrupt can occur while one is > in process? I'm thinking it can't because it would just mess up the > PUSH and POP process, or would it!? > > Basically the TMR0 process is very short, I just need it to occur while > the processor is still dealing with the serial receive. > > I think I should really look into handling this serial receive outside > of the interrupt? > > Cheers > Ed > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu