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>

>  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.

>
>  (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!

>  Mark, being weird this AM
>

Dan