Hi Jan-Erick Thanks again for your patience and help. I am truly grateful. Let me throw out some more details here first. I'm confident my PCB layout will support the full Monty (40MHz) (the up side of my RF design experience) but I'm using 4MHz crystals (4.096 to be exact)from my old designs so I'd like to use those but if I can't there is no great love lost. There will be a a GPS receiver on the second serial port. The good news is that there is not that much data it will send out standard NEMA message strings by default I think I can turn them all off so it will send a message like a GGA that is about one hundred or so characters long at one second intervals. I'll need to parse the message and adjust some digital attenuators based on the message. (There is no big hurry on parsing the message and adjusting the attenuator it can happen in the foreground) I will also need to read three A/D channels once every 3330msecs. All that needs to happen in the ISR is to read the value and put it in the appropriate place. I can process the result in the fore ground as long as it gets done before the next interrupt interval for that channel then that will be quick enough. (for the record they are current level detect (current converted to a voltage with an op amp). antenna bias voltage detect oscillation detect (RF level converted to a voltage with detector an op amp) In my button/switches ISR ( I only check the state of port bits and record them and move on or after so many interrupts based on what I've stored away I decide that a de-bounced switch closure has occurred and push a command into a circular buffer for foreground processing. (I'm leaving out a lot of the detail here I have a mode that looks for a button down and then an up before it qualifies as a good press and another mode that the user can hold it down (e.g. to adjust the brightness of the lcd with out having to press the button a hundred times) so I don't need the up for that particular switch if a global variables are set. So I'm reading your message and I'm confused...obviously confusing me is not a difficult task. It seems to me that it is not the time between events that matters. It is the time to process each event and still get back to the remaining events because all the asynchronous events could happen at once. A character could arrive at both serial ports right as the user was pressing a button. (technically as the button ISR was executing is more correct) So I need to be able to have an ISR button event interrupted for a higher level event (serial character) and not lose the button event information...because I was able to process the high level ISR event[s] and get back to the low level ISR "in time" Or said another way I think that I should be able to read a character on the serial port[s] during the button ISR and not lose a button press because my serial ISRs were fast enough to get it over with and get back to the button press ISR before my user gets his finger on and off the button? The A/D conversions are like the button press because but they can be made to happen when the button ISR aint by setting the interval not to coincide with the button ISR but the serial ports will be asynchronous. (I'm still a little fuzzy on this part) A/D channels are different in the sense when the conversion is done they will hang around so if that is interrupted they are not going away I just want to take care of it before the next one so I "think" I'll always be able to get to them and handle them in time provided I my fore ground is not too larded up. So this a very long way to say I think the problem is different than you described because of asynchronous events. Anyway thanks in advance Jan-Erick or anyone else that puts the effort into reading this tome. I have to go pick up my son. Phillip Things should be as simple as possible but no simpler Phillip Coiner CTO, GPS Source, Inc. Your source for quality GNSS Networking Solutions and Design Services, Now! -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of Jan-Erik Soderholm Sent: Wednesday, June 28, 2006 2:39 PM To: piclist@mit.edu Subject: RE: [PIC] C18 resource remaining metric/test Phillip wrote : > Sent: den 28 juni 2006 22:13 > To: 'Microcontroller discussion list - Public.' > Subject: RE: [PIC] C18 resource remaining metric/test > > > Hi Jan-Erick > Thanks I was writing a response to Olin. > So I just read your message. > This of course clears up a lot. > Once again I apologize for saying one thing when I meant another. > I certainly appreciate the everyone's help and don't intend > to antagonize anyone by wasting their time. No problem. :-) When seeing the "clear TMR3IF" with the wrong comment, it was clear what was the "problem"... :-) > I used the high level interrupts for the serial ports and the > low level interrupts for button presses/ switch de-bouncing. > My reasoning was that I didn't want to be servicing a > switch/button press which compared to a serial character > is very slow and could be preempted without much effect > and might make me miss a character if it were at the > same level of priority as a serial character. > So in my mind the switches/buttons that have a lower priority > should be a serviced with lower priority interrupt. > (Don't hesitate to correct me if you see a better way to > structure things. OK, let's back a step. Using the double-prio-interrupt feature is OK if you have *any* interrupt that in itself takes more time to execute then the longest acceptable delay for any *other* interrupt. Now, let's take your case. You have two interrupts enabled, TMR3-overflow and USART-receive, right ? A USART-receive interrupt can not come faster then the baudrate x10 (aprox). I do not remember if you sepecified the baudrate, but *generaly* speaking, you have quite a *lot* of instruction cycles between each received character. E.g, at 9600 baud you have aprox 1 ms between each USART interrupt. That is up to 10.000 instructions (@40Mhz). One can do a lot of processing with 10.000 instructions... Now the kayboard check routine. Does it realy take that many cycles to check if some PORT-bit is low/high ? I hope you don't have things like debouncing-delays in the ISR itself ! So the question is, what would hold the processor in the switch/button routine for that long that a USART interrupt would be missed ? Note also that an ISR should normaly be stable in runtime and have no points where it could be "stuck" for some unknown time. Usualy, when one have this problem, parts of the ISR (the parts that would have no problem to be "interrupted" by another interrupt) could be moved out of the ISR into the main code. Regards, Jan-Erik. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist