Searching \ for 'Wakeup from SLEEP timing on PIC16C84' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16C
Search entire site for: 'Wakeup from SLEEP timing on PIC16C84'.

Truncated match.
PICList Thread
'Wakeup from SLEEP timing on PIC16C84'
1998\09\14@163849 by Tom Crane

flavicon
face
Dear All,
       I am not getting the sort of timing on wakeup from the SLEEP
instruction on a PIC16C84 based system I'm working on that I had (naively?)
expected. The datasheet (DS30081F) is not explicit on this point I would be
interested if anybody could confirm/refute my findings.

I am clocking the chip at 4MHz and am executing some test code,

< Clear all bits in INTCON - ie. ensure GIE=0>
< Zero PORT registers & Turn PORT A & B to Inputs>
bsf     STATUS, RP0     ; Select Register Bank 1
bsf     OPTION_REG, INTEDG; Choose Int Interrupt on RB0 rising edge transition
bcf     STATUS, RP0     ; Reselect Register Bank 0
bsf     INTCON, INTE    ; Enable Int interrupt
bcf     INTCON, INTF    ; Clear Int Flag first
sleep                   ; Execute the SLEEP instruction
movf    PORTB, W        ; PIC has woken up, So read PORTB to clear its port cha
nge mismatch condition
bcf     INTCON, INTF    ; Clear the INTF flag which signalled the Int Interrupt
condition
< Zero PORT registers & Turn PORT A & B to Outputs>
bsf     PORTB, 7
bcf     PORTB, 7
<etc.>

When using an internal clock (ie. 4MHz crystal + usual 2 caps) I find that the
delay between applying a rising-edge signal to RB0 and detecting the signal on
RB7 is ~10mS, varying several mS from occasion to occasion.

When feeding the PIC with an external 4MHz clock the delay is ~200mS.

Presumably dependence on clock source is due to the 'oscillator driver' needing
to restart when running on internal clock - the datasheet describes it as being
turned off in sleep mode.

In any event, since my application needs to wake the PIC with a precision of 1
machine cycle - ie. 1uS w.r.t. the applied interrupt RB0 signal, I assume I'm
wasting my time messing about with the SLEEP instruction ?...

Regards.
Tom.
--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email:  spam_OUTuhap023TakeThisOuTspamvms.rhbnc.ac.uk
SPAN:   19.875
Fax:    01784 472794

1998\09\15@030959 by Dr. Imre Bartfai

flavicon
face
Hi,

the time you said makes me suspect that is is the Watchdog Reset. To
locate the nature of this phenomena I suggest to check the PD and TO bits
immediately after sleep.

Imre


On Mon, 14 Sep 1998, Tom Crane wrote:

{Quote hidden}

hange mismatch condition
>  bcf     INTCON, INTF    ; Clear the INTF flag which signalled the Int Interru
pt condition
{Quote hidden}

1998\09\16@023824 by Stuart Allen

flavicon
face
On Mon, 14 Sep 1998, Tom Crane wrote:
> Presumably dependence on clock source is due to the 'oscillator  driver'
needing
> to restart when running on internal clock - the datasheet  describes it
as being
> turned off in sleep mode.
>
> In any event, since my application needs to wake the PIC with a
precision of
> machine cycle - ie. 1uS w.r.t. the applied interrupt RB0  signal, I
assume I'm
> wasting my time messing about with the SLEEP instruction ?...
>
> Regards.
> Tom.

Hello,

It is correct that the oscillator has to start up, the time taken however is
specified as 1024 oscillator cycles. Which if its consistent, can be worked
around.

I have a similar problem, but with a 12C509. Wake up from sleep on pin
change resets the device, that takes 'typically 300uS'.

Regards,

Stuart.

1998\09\16@120806 by Tom Crane

flavicon
face
Thanks to all you replied.

First a typo correction: The '200mS' I wrote should have been 200uS -
which is a lot less than the internal osc value of ~10mS as expected.

>
> Hi,
>
> the time you said makes me suspect that is is the Watchdog Reset. To
> locate the nature of this phenomena I suggest to check the PD and TO bits
> immediately after sleep.

After the sleep instruction those bits are, !PD=0 & !TO=1 which is
correct for a sleep/wakeup rather than a WDT timeout.

I have a feeling I will not get the accuracy I need from sleep wakeup and
I'm going to go with polling in a loop instead.

Regards
Tom.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...