I have continued to play with SUBJ:

I just ran a test in which I verified that startup is syncronous, within one
Tosc, to the rising edge of MCLR. There is one minor mystery mentioned in
point 2, below.

I used two F876's, a test driver and a device-under-test.

The driver was running from a 20MHz external oscillator. The DUT was running
from an 4MHz external oscillator.

I connected RB1 from the driver to MCLR on the DUT.

I connected RB0 from the DUT to drive RB0/INT on the driver.

The program on the raises RB1, and times how long until RB0/INT goes high.
This timing is to a resolution of 200ns (one instruction time).

The program on the DUT, immediately upon coming out of reset, sets RB0 high
and then sets the TRIS for PORTB to drive the signal.

A resistor pulls down the RB0->RB0 line when the DUT is in reset.

What I was able to observe:

1: My handy dandy scope shows me that the time interval from the rising edge
of MCLR until the rising edge of RB0 on the DUT has a jitter of at most 250
ns. This corresponds to Tosc on the DUT. This makes perfect sense.

2: Also, using the scope, I determined that the minimum time from the rising
edge of MCLR to the rising edge of RB0 appeared to be about 4.85 us. I found
this rather surprising based on the following analysis:

Here is the code from the DUT:

 org 0x0

 bsf PORTB,0        ;[1] Set to drive high
 movlw 0                ;[2] Get ready to set tris

 bsf STATUS,RP0 ;[3] Bank 1
 movwf TRISB       ;[4] Starting driving port B

pogo:
  goto pogo

There are four instructions to be executed here before RB0 is driven high,
but the first instruction should have to do a fetch before it can execute.
Thus, I expect at least a 5us delay after MCLR rises before things can get
started. But the minimum delay actual noted on the scope was only 4.85us.
Perhaps the first instruction is partially or fully fetched while MCLR is
still held low?

I do expect some delay, other than the raw execution time delay to account
for:

-- Setup time on the MCLR input relative to OSCIN

-- Some logic to syncronize MCLR to OSCIN to avoid a login hazard condition.

3: I wanted to make sure that there were no extra long or extra short delays
that I didn't happen to see on the scope, so I kept track of the shortest
and longest delay as seen by the driver. These differed by only 200ns (one
instruction time).  This seems to make sense too.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.