CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Help!! I want to wake up from Sleep mode with Int_RDA

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
zerotnt



Joined: 11 Nov 2004
Posts: 1

View user's profile Send private message

Help!! I want to wake up from Sleep mode with Int_RDA
PostPosted: Thu Nov 11, 2004 3:17 am     Reply with quote

How to wake up CPU PIC18F458 from Sleep mode by Using Int_RDA ;
In datasheet 18F458 show me set UART In synchronous slave mode for wake up from sleep but i don't understand. How to setup it ? when i used predirective #useRS232, CPU can't wake up; Please Show me for Example Program Please .... Very Happy
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Thu Nov 11, 2004 6:52 am     Reply with quote

Just define the registers and set them manually per the datasheet Very Happy Microchip has arleady done it for you.
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Thu Nov 11, 2004 7:13 am     Reply with quote

What kind of serial communication are you using? Is it aynchronous (RS-232) or synchronous mode? An important difference between these two modes is that in synchronous mode you have a physical clock line in addition to the data lines.

If you are using asynchrounous communication you can not wake up from a character receive; in synchronous mode you can:
Quote:
24.3.1 WAKE-UP FROM SLEEP
The device can wake-up from SLEEP through one of
the following events:
<cut>
8. USART RX or TX (Synchronous Slave mode).
<cut>
Other peripherals cannot generate interrupts, since
during SLEEP, no on-chip clocks are present.

In synchronous mode the external clock is used for clocking in the data, but in async mode there is no clock available and so no data is clocked in.

A possible work around in async communication is to connect the signal to the ext1 pin as well. Then you can wake from sleep by a negative edge from the start bit on ext1. Depending on baud rate and start-up time for the processor you will miss a few of the first incomming characters. A higher level protocol can detect this error and ask for retransmission.
young



Joined: 24 Jun 2004
Posts: 285

View user's profile Send private message

PostPosted: Thu Nov 11, 2004 9:01 am     Reply with quote

Is that any enabled inturrupt will weak up the sleep mode, right?
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Thu Nov 11, 2004 9:06 am     Reply with quote

Yes, any interrupt can wake up the processor
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Thu Nov 11, 2004 9:06 am     Reply with quote

No, only certain ones can
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Thu Nov 11, 2004 9:12 am     Reply with quote

Okay, my previous 2 posts are to get a point across to some of the posters. You don't always get the correct answers so always read the datasheet first!

Quote:
Power-down mode is entered by executing a SLEEP
instruction.
If enabled, the Watchdog Timer will be cleared but
keeps running, the PD bit (STATUS<3>) is cleared, the
TO (STATUS<4>) bit is set, and the oscillator driver is
turned off. The I/O ports maintain the status they had
before the SLEEP instruction was executed (driving
high, low, or hi-impedance).
For lowest current consumption in this mode, place all
I/O pins at either VDD or VSS, ensure no external circuitry
is drawing current from the I/O pin, power-down
the A/D and disable external clocks. Pull all I/O pins
that are hi-impedance inputs, high or low externally, to
avoid switching currents caused by floating inputs. The
T0CKI input should also be at VDD or VSS for lowest
current consumption. The contribution from on-chip
pull-ups on PORTB should also be considered.
The MCLR pin must be at a logic high level (VIHMC).
12.13.1 WAKE-UP FROM SLEEP
The device can wake-up from SLEEP through one of
the following events:
1. External RESET input on MCLR pin.
2. Watchdog Timer Wake-up (if WDT was
enabled).
3. Interrupt from INT pin, RB port change or
peripheral interrupt.
External MCLR Reset will cause a device RESET. All
other events are considered a continuation of program
execution and cause a “wake-up”. The TO and PD bits
in the STATUS register can be used to determine the
cause of device RESET. The PD bit, which is set on
power-up, is cleared when SLEEP is invoked. The TO
bit is cleared if a WDT time-out occurred and caused
wake-up.
The following peripheral interrupts can wake the device
from SLEEP:
1. PSP read or write (PIC16F874/877 only).
2. TMR1 interrupt. Timer1 must be operating as an
asynchronous counter.
3. CCP Capture mode interrupt.
4. Special event trigger (Timer1 in Asynchronous
mode using an external clock).
5. SSP (START/STOP) bit detect interrupt.
6. SSP transmit or receive in Slave mode
(SPI/I2C).
7. USART RX or TX (Synchronous Slave mode).
8. A/D conversion (when A/D clock source is RC).
9. EEPROM write operation completion
Other peripherals cannot generate interrupts since during
SLEEP, no on-chip clocks are present.
When the SLEEP instruction is being executed, the next
instruction (PC + 1) is pre-fetched. For the device to
wake-up through an interrupt event, the corresponding
interrupt enable bit must be set (enabled). Wake-up is
regardless of the state of the GIE bit. If the GIE bit is
clear (disabled), the device continues execution at the
instruction after the SLEEP instruction. If the GIE bit is
set (enabled), the device executes the instruction after
the SLEEP instruction and then branches to the interrupt
address (0004h). In cases where the execution of
the instruction following SLEEP is not desirable, the
user should have a NOP after the SLEEP instruction.
12.13.2 WAKE-UP USING INTERRUPTS
When global interrupts are disabled (GIE cleared) and
any interrupt source has both its interrupt enable bit
and interrupt flag bit set, one of the following will occur:
• If the interrupt occurs before the execution of a
SLEEP instruction, the SLEEP instruction will complete
as a NOP. Therefore, the WDT and WDT
postscaler will not be cleared, the TO bit will not
be set and PD bits will not be cleared.
• If the interrupt occurs during or after the execution
of a SLEEP instruction, the device will immediately
wake-up from SLEEP. The SLEEP
instruction will be completely executed before the
wake-up. Therefore, the WDT and WDT
postscaler will be cleared, the TO bit will be set
and the PD bit will be cleared.
Even if the flag bits were checked before executing a
SLEEP instruction, it may be possible for flag bits to
become set before the SLEEP instruction completes. To
determine whether a SLEEP instruction executed, test
the PD bit. If the PD bit is set, the SLEEP instruction
was executed as a NOP.
To ensure that the WDT is cleared, a CLRWDT instruction
should be executed before a SLEEP instruction.
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Thu Nov 11, 2004 9:19 am     Reply with quote

Quote:
Is that any enabled inturrupt will weak up the sleep mode, right?

See my post above! I refer to chapter 24.3.1 of the 18F458 manual which explains all the events that can awake the processor from sleep.

Additional info: I just stumbled across the UART_WAKEUP_ON_RDA parameter for the Setup_uart() function. Apparently PICs with Enhanced UART (EUART) hardware can awake from an asynchronous receive as well. Too bad the 18F458 has a normal UART.

Edit: Mark's post refers to the PIC16F874/877 processors which is slightly different from you PIC18F458.


Last edited by ckielstra on Thu Nov 11, 2004 9:36 am; edited 1 time in total
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Thu Nov 11, 2004 9:29 am     Reply with quote

And from the datasheet:

Quote:

During Sleep mode, all clocks to the EUSART are
suspended. Because of this, the Baud Rate Generator
is inactive and a proper byte reception cannot be
performed. The auto-wake-up feature allows the
controller to wake-up due to activity on the RXx/DTx
line, while the EUSART is operating in Asynchronous
mode.
The auto-wake-up feature is enabled by setting the
WUE bit (BAUDCONx<1>). Once set, the typical
receive sequence on RXx/DTx is disabled and the
EUSART remains in an Idle state, monitoring for a
wake-up event independent of the CPU mode. A wakeup
event consists of a high-to-low transition on the
RXx/DTx line. (This coincides with the start of a Sync
Break or a Wake-up Signal character for the LIN protocol.)
Following a wake-up event, the module generates an
RCxIF interrupt. The interrupt is generated synchronously
to the Q clocks in normal operating modes
(Figure 20-8) and asynchronously, if the device is in
Sleep mode (Figure 20-9). The interrupt condition is
cleared by reading the RCREGx register.
The WUE bit is automatically cleared once a low-tohigh
transition is observed on the RX line following the
wake-up event. At this point, the EUSART module is in
Idle mode and returns to normal operation. This signals
to the user that the Sync Break event is over.


So some PICs can be woken by the UART and others cannot. All the more reason to read the datasheet for the device in question.
young



Joined: 24 Jun 2004
Posts: 285

View user's profile Send private message

PostPosted: Thu Nov 11, 2004 10:03 am     Reply with quote

Well i have some problem to understand the datasheet. some genuis guy like you could guide me.
the follwing is my situation:
I am using USART to communicate with the PIC to let the pic do something according to the data I sent to it, when PIC received the letter for collecting data, the PIC will statrt collecting data, and save to extrenal eeprom, When I send letter to PIC to read data, PIC will send data back from external eeprom to PC.

I am also able to setup WDT to collect data every few seconds when PIC was weak up by WDT timer without INT_RDA.

but I could not put INT_RDA and WDT function simutanously. what I want to do is when I send letter to command the PIC to collect data at weak up by WDT oeriod, when I send letter again (the PIC could collecting data from PIC to PC. however, when I send letter again the data was not received by PIC correctly at this moment because sometimes it is in sleep.

How could I use int_rda just for command and wdt to weak separately without interfacing each other?
young



Joined: 24 Jun 2004
Posts: 285

View user's profile Send private message

PostPosted: Thu Nov 11, 2004 10:26 am     Reply with quote

according to your posting. I feel that no matter how I could not put them to work simoutanously because
Code:
During Sleep mode, all clocks to the EUSART are
suspended. Because of this, the Baud Rate Generator
is inactive and a proper byte reception cannot be
performed.


so I have to avoid it anyway, Am I right.

Will a rest button put the PIC into a restart situation? like put the PIC into a waiting loop from int_rda? if this is the situation, I may find a solution?
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Fri Nov 12, 2004 10:48 am     Reply with quote

Summary of all the above:
- PIC processors with an Ehanced USART (EUSART) can awake from sleep by sending a special character to the Rx-pin.
- The PIC18F458 has a standard USART, not enhanced, and can not awake from sleep by sending data to the Rx-pin.

A possible solution could be to make a small modification to your hardware where you connect the received data to both the Rx pin and the INT0 pin. This way you can still awake from sleep on data reception because the received data will trigger the INT0 interrupt. A drawback of this aproach is that because of start up delays the first few characters received will be missed. This however can be solved in your protocol, for example by starting every message with a series of dummy characters.

Life might be easier without putting your processor to sleep...
From your problem description I don't see why you put your processor to sleep. Is this because you want to save power? If yes, than the PIC18F458 is not best processor to start with, there are other PIC processors with much lower power consumption.

So, why are you using sleep() ?
young



Joined: 24 Jun 2004
Posts: 285

View user's profile Send private message

PostPosted: Fri Nov 12, 2004 3:06 pm     Reply with quote

I would like to know which processor is better for power saving purpose? thank you.
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Fri Nov 12, 2004 5:21 pm     Reply with quote

It would be nice to answer my question before asking a new question yourself.....

Microchip has a whole line of low current processors, called "nanoWatt" Technology devices. See this link. The lower the voltage, the lower the power consumption, and these devices can run on voltages down to 2.0V !

Depending on memory requirements and number of I/O-pins you can make a selection. For you it might be usefull to look for the EUSART feature as well.
A favourite that's small and cheap with EUSART support is the 16F688 but the number of I/O pins and memory are limited.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group