Hi Olin Thanks again for your help I'm think I addressed some of your questions in the messages to Bill and Jan-Erik The last part of your message answers my crystal question to Jan-Erik I asked right in the beginning (and you seemed to have ignored) why not use a standard UART interrupt that stuffs the received byte into a FIFO, then let the foreground code drain the FIFO as it gets to it? This seems even more appropriate now after you described more about your system. I did not ignore this or any advice from this group. As a whole the help I get here is first rate especially yours. I "think" I am doing what you are saying with a slight twist. If I get one of a set of chars I push a CMD in a circular buffer if I get a special char I push the following chars in a buffer to form strings it takes a few more instructions but I think it is worth it so that my main loop is just processing commands or a command and its associated string. Because of this "None of your interrupts require particularly low latency" I think I can get away with the extra instructions inside my serial ISR even using the silly compiler generated ones...I can always rewrite them in assembler if I need fewer instructions but right now I don't think I'm any where near the limit of instructions if I operate the serial ports at 9600 or switched up to 11,520 bytes/second. I also agree that there is no real need to have a priority scheme now but I don't see what it hurts. I want to build a PLL later in another similar design and it might require low latency ISR and I want to leverage this code there so I'm trying to structure it/ learn the ropes for a priority scheme now. I have another damn meeting. I would like to ask you some more questions about the filtering. I have just been averaging my AD interrupts (in another product) and would prefer to use filtering. 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 Olin Lathrop Sent: Thursday, June 29, 2006 5:30 AM To: Microcontroller discussion list - Public. Subject: Re: [PIC] C18 calculating the interrupt loading Phillip wrote: > so it will send a message like a GGA that is about one hundred or > so characters long at one second intervals. > > ... > > 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. > > ... > > 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 think you should have 3 interrupts, the UART, A/D conversion complete, and a timer. Buttons, especially ones that require debouncing, are usually easier to handle by sampling than by interrupting on closure or state changes. You need timing anyway for the debouncing, so you might as well base everything off a timer. I asked right in the beginning (and you seemed to have ignored) why not use a standard UART interrupt that stuffs the received byte into a FIFO, then let the foreground code drain the FIFO as it gets to it? This seems even more appropriate now after you described more about your system. The timer interrupt can have 1mS period. Every timer interrupt you check the switches, perform any debouncing logic, and update the global state of the official debounced switches state for the foreground code to look at. 50mS, which will be 50 ticks, is a good debounce time. Just about all switches will finish bouncing well before that, but it will still feel instantaneous to a human. You also start a A/D conversion every timer tick. In the basic version the A/D interrupt grabs the A/D value, updates the global value for that channel, and switches the A/D to acquiring the next channel. Note that 1mS is much much longer than the required acquisition time plus conversion time plus A/D interrupt handling time. The foreground code handles events like UART input byte available and debounced switches changed state. This can probably be a main event loop architecture for most things, although the UART input stream handler may benefit from being implemented as a pseudo thread due to the highly history-sensitive nature of parsing the data stream. That's the basic setup. However I would apply some low pass filtering to the A/D readings. You need a new reading only every 3.3 seconds, during which time you can take 1100 readings per channel and still only use a small fraction of the CPU. Two poles of LPF each with 8 shift bits per pole settles to about 93% in 1100 iterations. That sounds like a good match, especially since shifting by 8 bits is particularly trivial, and 2 x 8 bits is a lot of random noise attenuation. > 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. The latency to handle an interrupt after the condition has occurred is what matters. None of your interrupts require particularly low latency, so there is no need for a priority scheme. Even if only running at 16MHz (using your 4MHz crystal), you get 4 instructions/uS and 4000 instructions/mS. The most latency critical interrupt is the UART. Even at 115.2Kbaud baud you have 11,520 bytes/second, or 87uS/byte, or 347 instructions/byte. Can you imagine any one of the other interrupts taking 347 instructions? I can't. The A/D with filtering will be the most, but should still be much less than 347 instructions (unless maybe you do something silly like use a compiler for interrupt code). And that was for 115.2Kbaud. The GPS can probably be set for 9600 baud, in which case you get over 4000 instructs/byte. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products -- 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