Searching \ for 'RTCC INTERRUPT AND SLEEP' 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/ints.htm?key=interrupt
Search entire site for: 'RTCC INTERRUPT AND SLEEP'.

Truncated match.
PICList Thread
'RTCC INTERRUPT AND SLEEP'
1995\10\25@213841 by doug r. boulware

flavicon
face
The Parallax simulator shows that a PIC16C84 will awaken from sleep by
an RTCC overflow interrupt that is triggered from the RA4/RTCC input
pin.

I have not found any documentation that confirms this, and cannot seem
to get it to occur on the actual chip.  I am attempting to awaken the
chip when a start bit from an RS232 serial input is detected.  The
serial input routine is interrupt driven from the RTCC and works fine
without the sleep instruction.

Can this be done ?

Regards,

Doug Boulware <spam_OUTdougrbTakeThisOuTspamfree.org>

* RM 1.3  *

1995\10\26@021450 by divanov

flavicon
face
... snip snip ...

> The serial input routine is interrupt driven from the RTCC and works fine
> without the sleep instruction.

The sleep instruction effectively stops the oscillator. You can
wake up the PIC by means of external interrupt, but your timing will
obviously be incorrect.

> Can this be done ?

I don't see any reasonable way to implement RS232 using the sleep
instruction. Please, correct me someone if I'm wrong.

Cheers,

RI

1995\10\26@043037 by Andrew Warren

face
flavicon
face
Doug R. Boulware <.....dougrbKILLspamspam@spam@SQUEAKY.FREE.ORG> wrote:
>
>The Parallax simulator shows that a PIC16C84 will awaken from sleep by
>an RTCC overflow interrupt that is triggered from the RA4/RTCC input
>pin.
>
>I have not found any documentation that confirms this, and cannot seem
>to get it to occur on the actual chip.  I am attempting to awaken the
>chip when a start bit from an RS232 serial input is detected.  The
>serial input routine is interrupt driven from the RTCC and works fine
>without the sleep instruction.
>
>Can this be done ?

Doug:

Sure, but contrary to what that substandard simulator shows, it can't
be done with only the RTCC pin.  Check out section 8.8.1, "Wake-Up from
Sleep", in the 16C84 Data Sheet; the only events which can wake up the
PIC are:

   External reset input on MCLR
   WDT timeout reset
   Interrupt from RB0/INT, PortB-change, or data EEPROM write-complete

Yuo might also want to take a look at Section 6.1, "TIMER0 (TMR0)
INTERRUPT", which says, in so many words, "The TMR0 module interrupt
cannot wake the processor from SLEEP...."

If your RB0 pin is available, I'd tie it to the RA4/RTCC pin and
configure the RB0 interrupt to occur when it sees the start bit.

That'll wake up the PIC; once awake, you can disable the RB0 interrupt
during the reception (so you don't get repeated RB0 interrupts), then
re-enable it just before you go to sleep.

-Andy

--
Andrew Warren - fastfwdspamKILLspamix.netcom.com
Fast Forward Engineering, Vista, California

1995\10\26@123540 by Mike Keitz

flavicon
face
>Yuo might also want to take a look at Section 6.1, "TIMER0 (TMR0)
>INTERRUPT", which says, in so many words, "The TMR0 module interrupt
>cannot wake the processor from SLEEP...."

To expand on that, the RTCC doesn't work at all during sleep, as the
synchronizer is driven by the internal PIC clock.  The prescaler (if
enabled) probably does continue to count, but the main register won't.

>If your RB0 pin is available, I'd tie it to the RA4/RTCC pin and
>configure the RB0 interrupt to occur when it sees the start bit.
>
There's really no need to use two pins, you could take all input through a
port B pin, and use the RTCC with internal clock to time the bits and cause
interrupts at the correct sample times.  Or, if the PIC has nothing to do
until it gets some more serial data, an ordinary software-timed receiver may
be all that's required.  At high baud rates, the (uncertain) time required
to re-start the oscillator may make it difficult to know where the center of
the start bit (that woke up the PIC) was and sample at the right time.
Sending a 'don't care' byte to wake up the PIC, then immediately following
it with real data may be a way around that.

-Mike

1995\10\27@234843 by doug r. boulware

flavicon
face
I wrote:

DB>The Parallax simulator shows that a PIC16C84 will awaken from sleep by
DB>an RTCC overflow interrupt that is triggered from the RA4/RTCC input
DB>pin.
DB>
DB>I have not found any documentation that confirms this, and cannot seem
DB>to get it to occur on the actual chip.  I am attempting to awaken the
DB>chip when a start bit from an RS232 serial input is detected.  The
DB>serial input routine is interrupt driven from the RTCC and works fine
DB>without the sleep instruction.

Andrew Warren replied:

AW>Sure, but contrary to what that substandard simulator shows, it can't
AW>be done with only the RTCC pin.  Check out section 8.8.1, "Wake-Up from
AW>Sleep", in the 16C84 Data Sheet; the only events which can wake up the
AW>PIC are:

AW>    External reset input on MCLR
AW>    WDT timeout reset
AW>    Interrupt from RB0/INT, PortB-change, or data EEPROM write-complete

AW>Yuo might also want to take a look at Section 6.1, "TIMER0 (TMR0)
AW>INTERRUPT", which says, in so many words, "The TMR0 module interrupt
AW>cannot wake the processor from SLEEP...."

AW>If your RB0 pin is available, I'd tie it to the RA4/RTCC pin and
AW>configure the RB0 interrupt to occur when it sees the start bit.

Thanks.  You confirmed my suspicion that the simulator is wrong.  Not
that its the first bug I've come across.  In case it's not general
knowledge, the Parallax simulator also does not handle the port B change
interrupt correctly.  The v2.42 I have will continually interrupt as long
as any of the respective port B pins are high.

I was trying to keep port B open for general I/O and use port A for
serial comm and interface to a National Semi 0831 serial A/D converter.
I'm playing around with a "Remote I/O" system that I communicate with
serially, similar to the "Stamp Expander" that Parallax sells, only
using the '84.

I have yet to get the Microchip simulator. Is it better than
Parallax's ?

Regards,

Doug Boulware <.....dougrbKILLspamspam.....free.org>

* RM 1.3  *

1995\10\28@014740 by Andrew Warren

face
flavicon
face
Doug R. Boulware <EraseMEdougrbspam_OUTspamTakeThisOuTSQUEAKY.FREE.ORG> wrote:

>You confirmed my suspicion that the simulator is wrong.  Not that its the
>first bug I've come across.  In case it's not general knowledge, the
>Parallax simulator also does not handle the port B change interrupt
>correctly.  The v2.42 I have will continually interrupt as long as any of
>the respective port B pins are high.
> ....
>I have yet to get the Microchip simulator. Is it better than Parallax's ?

   Doug:

   Depends on what you mean by "better".  If you mean "does it properly
   emulate the PICs' operation", "does it support EVERY SINGLE PIC that
   Microchip makes", "does Microchip promptly fix whatever minor bugs DO
   creep in", or "does it allow source-level debugging of code written for
   Microchip's MPASM assembler", or even "was it written by a chick", the
   answer is YES.

   If you mean, "does it have a user-friendly interface", the answer is NO,
   NOT YET.  By April, 1996, though, Microchip's simulator will be fully
   integrated into MPLAB, the new interface for Microchip's Windows-based
   PIC-MASTER emulator.

   -Andy

--
Andrew Warren - fastfwdspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California

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