OOPS, I previously sent this to James Newton instead of the list... There are two techniques used for profiling: counting and sampling. In the first you instrument the code (or use a single-step capability of the processor or run under a simulator) to count the number of times certain code paths are followed. This could certainly be done on a PIC, but you'd have to account for the delay introduced. This is the usual technique supported by a simulator. In the second method you generate interrupts, either on a fixed interval, or on some (pseudo-)random interval. At each interval you sample the program counter. This could be done on 18C series PIC's only AFAIK because they are the only PICs that provide programmatic access to the stack. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) ----- Original Message ----- From: James Newton To: Sent: Monday, August 21, 2000 3:38 PM Subject: Re: [PIC]: PIC Profiler > I may be wrong here but without a time based interrupt (ROMZap has only user > placed calls to the monitor routine and I didn't think WLoader had any debug > ability, please correct if wrong) I don't see how profiling would happen. > > I certainly do agree that this would be a good place for it, and that it > could be done, but either an external interrupt, or timer ISR code would be > required. Not too hard, just would require some additional (precious) > overhead. > > Now, the ICD (is anyone from Microchip listening) should be able to do this > without any additional target chip hardware or software overhead. Just a > tweak (maybe) in the ICD "module" firmware and some GUI on the PC. > > The Parallax-inc.com SXKey for the Scenix.com SX PIC clones has a "Poll" > mode where the chip gets interrupted and the registers updated on the PC > screen every few hundred milliseconds and I've used that as an "seat of the > pants" profiler in the past. > > My experience is that 90% of the programs spend %80 percent of their time in > 5% of the code (or about) so it sort of jumps out at you. I've also been > (unpleasantly) suppressed at which 5% of the code it is on a number of > occasions. > > --- > James Newton (PICList Admin #3) > mailto:jamesnewton@piclist.com 1-619-652-0593 > PIC/PICList FAQ: http://www.piclist.com or .org > > -----Original Message----- > From: pic microcontroller discussion list > [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Dan Michaels > Sent: Monday, August 21, 2000 11:20 > To: PICLIST@MITVMA.MIT.EDU > Subject: [PIC]: PIC Profiler > > > Harold wrote: > > >> > >> And I'll bet you always know "exactly" how long all your > >> "critical" routines take to execute too. > >> > ..... > > Yes... Too Long! Anyone have any sort of histogram program to tell > me > >where the processor is spending all its time? > > > > PIC Prolifer - it just occurred to me that this may be something > that could be put into '877 ICD/debug/monitor that Tony and Wouter > have been doing. > > > best regards, > - danM > > -- > http://www.piclist.com hint: To leave the PICList > mailto:piclist-unsubscribe-request@mitvma.mit.edu > > -- > http://www.piclist.com hint: To leave the PICList > mailto:piclist-unsubscribe-request@mitvma.mit.edu ----- Original Message ----- From: Tobie Horswill To: Sent: Monday, August 21, 2000 7:07 PM Subject: [OT]: automotive sample/correction with slow refresh > Hi, > > I've started working on a "just for fun" project involving an > autonomous vehicle using a GPS receiver (Garmin GPS35) and one or more PICs. > The goal is to give the PIC a destination and then have it monitor the > vehicle's displacement through the GPS receiver and then correct it's > heading in real-time. The vehicle being a solar powered boat it will be > rather slow... > > My problem is the following. "Domestic" GPS receivers (as opposed to > dynamic GPS or military GPS) have a granularity of approximately 30-50 feet. > The boat may take anywhere from 10 seconds to a minute to travel that > distance depending on winds, currents and so on. The GPS needs a > displacement in order to find a heading, so even in the best of conditions > the PIC will only get the boat's heading every 10 seconds or so. So the > PIC's sample/calculate/correct refresh rate can be anything between 0.1Hz > and 0.016Hz. Many things can happen during that rather long period, the boat > could get turned around by a wave, it could hit something and deviate etc... > Under these conditions, I'm afraid the PIC's corrections will always be > erroneous and it will either end up in a sort of feedback loop zigzagging > (overshooting) or taking a very long time to correct small heading > discrepancies instead of keeping a straight line. > > Is there any way you can think of to shorten the sample period to let's > say 1 second without adding too much expensive hardware (gyroscopes, > accelerometers and such) ? Perhaps some kind of linear regression algorithm > or a PID loop? > > TH > thorswil@videotron.ca > > -- > http://www.piclist.com hint: To leave the PICList > mailto:piclist-unsubscribe-request@mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu