Hi Jan-Erick Crystal: I did not realize the HSPLL PLL mode could be made to work like that but it is great to know. So I'm sure you know what my next question is....Can I run the HSPLL with my trusty crusty 4.096MHz crystal for 16MHz internal eh? GPs receiver: There are resistors to program the GPS receiver to default to 9600. I see no reason not to run both ports at 9600. (It is a module from Sony. It really has good sensitivity and the price is right ublock has a good module too (their sensitivity specs are marketing hype but it is still very good performer that I might add a foot print for later so I have a second source. They are both available as a chip sets too. Later on I plan to switch to the chip set mode to save a few bucks but you have to do micro vias/BGAs so it is not for PCB layout feint of heart or those with out reflow soldering capability. The modules can be made to work using fairly standard PCB layout techniques & proper grounding. ) ISR Traps: There are no traps (at least not intentionally) in any of my ISRs it either is or aint and we move one. So it is fairly short/terse. AD interrupts. All three to channels to sample at 330msecs intervals (this works out to 3 times per second not once every 3 seconds but the concept is the same...sorry if I was not clear) If the result for all three is processed/acted on before the next 3330msec interval then all is fine. They can be in synch i.e. all be told to sample at the same time or in series as long as they each happen every 330mses. I have read the last part of your message but I need to do some research and let it sink in but on the first pass it makes perfect sense. I'll write back later when I have a plan Thanks again for your help and and very grateful for your time and expertise 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: Thursday, June 29, 2006 5:10 AM To: piclist@mit.edu Subject: RE: [PIC] C18 calculating the interrupt loading Phillip wrote : > I'm confident my PCB layout will support the full Monty > (40MHz) (the up side of my RF design experience)... One of the reasons there is a HSPLL mode (10 Mhz xtal, 40 Mhz internal) is to get lower RF interference. > 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. Fine, as long as you have enough processing cycles... :-) > There will be a a GPS receiver on the second serial port. Running at 9600 baud or so ? 1200 maybe ? > (There is no big hurry on parsing the message and adjusting > the attenuator it can happen in the foreground) And of course you have to translate "no big hurry" into real micro/milli seconds... :-) > 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. OK, so a rather short ISR's once each 3 seconds. Shouldn't be a problem. > > 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. Fine, also seems to be a fairly short ISR. > (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 ou > 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. OK, but there is nothing that will "trapp" the processor in the button-ISR for some undefined lenght of time, right ? > 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. Yes, my example was mor or less based on the scenario with *two* interrupt sources. With more then two, one have to add up the time to be sure. > 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) Only if the time spend in the button-ISR would make you miss the *next* character ! Note that you do not have to read the serial character "at once", it have to be read before the next character is received. The USARTs are double buffered so they can have one character waiting in the RXREG while another (the next) character is currently received. > 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? Or in yet another way, the serial character can wait in the RXREG until the button-ISR have finished, since it will always finish before the next serial character is completely recevied. Now, if that is *NOT* the case, you have a real trouble ! The solutions can be : 1 Using the two-level interrupt priority feature. 2 Redesign of the button-ISR (making it run faster). 3 Running the processor faster. > 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) Now the ADC conversons are run at 3 sec intervalls, right ? Is it of a great importance that the ADC valus are processed within some minimum delay ? Or do you have the full 3 sec intervall to process them ? If so, I don't see any real problem and the fact that the ADC interrupt and the button- (timer-) interrupts "fires" at the same time doesn't matter much. The interrupt logic will "serialize" the processing. That is, when the processor runs the RETFIE at the end of you main ISR, the processor will at once "see" the other xxxxF flags and a new interrupt will fire at once. It will "only" introduce a slight delay for the second interrupt source. You can introduce your own priorities in the main ISR by the order of the tests of the F-flags, in the case that multiple F-flags should be set. Such as, if the two USARTS are running at different speeds, I'd make sure to process the faster one before the slower, in the case that both F-flags should happen to be set at entry of the main-ISR. > A/D channels are different... Different from what ? > 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... Just as the character in the RXREG in the USART ! It will no "go away" until the next character is fully received (and you will also have to "overflow" bit set in that case). > 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. Again, just as the serial character... > So this a very long way to say I think the problem is > different than you > described because of asynchronous events. No, that *was* what I described. The interrupts can be used to process asynchronous events, it just a question on having control over the processing times of each ISR and the allowed delays before begining processing of each ISR. Those two factors have to "match"... 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