Dan Larson wrote:
>
> On Tue, 29 Jun 1999 09:37:38 -0700, Mark Willis wrote:
>
> >
> >  Dan, startup delays are caused BY the startup timer...  I just said
> >that, in my perhaps unique way.
> >
> >  (How can a program run - as NO code runs while the startup timer is
> >counting, anyways?  <EG>)
> >
>
> Depends on how low Vss is <BG>

  Don't think so, !TO bit wouldn't make sense otherwise!  Quoth the F84
docs,

[ Power-up Timer (PWRT), which provides a
[ fixed delay of 72 ms (nominal) on power-up only. This
[ design keeps the device in reset while the power supply
[ stabilizes.

  Note the "Keeps the device IN RESET" there.  Sure, once that 72 ms is
over, the code'll start running, but not UNTIL then!  <G>

> >  So I just suggested, sync up AFTER both pics have gone through the
> >startup delay, through software sending an edge trigger to sync things
> >up.
>
> I just can't see how the clock Q's will align. I guess I'd have to ping
> an output on each and scope them for phase jitter, sync'ing on MCLR of
> the first PIC being reset repeatedly with a 555 timer or something.
>
> But if I was sure that the leading edge of MCLR going high resets the Q
> cycle counter of the clock, perhaps I can see the first PIC holding down
> the reset of the second PIC to sync. But, even if they can be made to sync
> consistently it still may not be on the same Q cycle.  I wish there were
> some more timing diagrams that showed Q cycle in relation to MCLR.

  Manual example - Think of two pics run at 1 Hz.  Stop the clock to the
first one that raises RB7 high, until the other PIC also raises RB7,
then let both continue - they're synchronized.  Proper gating should let
them do this at far faster clock speeds than 1 Hz, of course.  I'll do
that later though, have an appointment today <G>

> >  (Does someone else's software run while the startup timer's running?
> >Evil Minds want to know <G>  How do they DO that?)
> >
>
> If it is on someone else's PIC, it does!

  How does anyone's software run while the PIC's held in reset?  Hmmm...

> >  Mark, being weird this AM
> >
>
> Dan

  Mark