Searching \ for '[PIC] wake from sleep using serial port on 16F77' 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/ios.htm?key=serial
Search entire site for: 'wake from sleep using serial port on 16F77'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] wake from sleep using serial port on 16F77'
2010\07\30@151635 by Dwayne Reid

flavicon
face
Good day to all.

We are in the process of adding ModBus communications to a mature product.  This is a box that lives in a hazardous location (explosive atmosphere) and the certification process is fairly onerous.  This certification process has to be repeated any time that anything within the box changes.

I mention this to explain why I'm trying to avoid changes to the existing PC board.

The unit uses a 16F77 and does not currently make use of the on-board USART.  Because we always try to look to the future, the serial RX & TX lines as well as several Port D pins were brought to a header, along with power and Gnd.

The unit spends most of time asleep so as to minimize current consumption.  It wakes once per second to update its clock and will wake immediately should any user button be pressed, as well as when any external sensors trip.

It works pretty well.  Sleep current is somewhere 150uA - mostly analog stuff that is always working.  It will run without sunlight - and drive its output solenoids - for a least two months and still leave the battery charge sufficiently high to avoid freezing down to -40C or so.

Now the customer wants to add ModBus capability to the unit.  Aside from the continuous current consumption that the RS-485 chip requires, its pretty straight ahead kind of stuff.  FWIW - we are using LTC1483 as our RS-485 interface - it was the lowest-current device we could find (Idd = 500uA worst case).  I'd be happy to hear of any lower-current parts, though.

We are implementing the ModBus interface on a little add-on card that connects to the main card via ribbon cable.  Yeah - we have to go through the whole certification process again but the certifying authority tells us that the cost will be significantly less if we don't change the existing PC board and just add on the new board, connected with a cable.

Anyway, the last hurdle to overcome was how to wake our unit from sleep when a RS-485 transmission occurs.  The idea was to wake up, wait for the next transmission to occur (the packet that woke the device would have been lost), see if the slave address matches, then go back to sleep if it doesn't.  The people who are writing the ModBus stuff at the control end are OK with having to send a dummy packet to wake our box.

But: how to wake the unit from sleep?

We could patch the existing PCB to allow something from the ModBus interface board to generate an interrupt.  That is actually fairly easy - there is an existing node that will wake the PIC anytime current flows out of that node (normally HI; current flow towards Gnd wakes the PIC).  But: we don't want to modify the PC board.

We came up with a solution that I haven't previously seen and I thought I'd share it with the PIClist.

The USART on-board the 16F77 can be configured for either Synchronous or Asynchronous operation.  The data sheet says that Synchronous operation can be used communicating with external eeproms or a/d or d/a converters - something we have never needed.  But: there it is.

It turns out that the USART can generate an interrupt that will wake the PIC if is configured for Synchronous Slave mode and then receives a character.  Even better: the USART TX pin is the clock input for Synchronous Slave mode.  That means that pin is already part of our expansion header.

All we had to do was place a resistor (4k7) between the USART TX and RX pins, then configure the USART to be in Synchronous Slave mode before going to sleep.  The resistor does not affect normal operation of the USART when talking or listening to the RS-485 buss.

It works like a charm.  The incoming data is treated as if it were a clock signal - we wind up with garbage in the USART receive buffer but we don't care.  When 9 or more data edges are seen, the PIC wakes.  We then set the USART into Async mode, flush the receive buffer, then wait for a new packet to begin.

Hope this is helpful to someone.

dwayne

-- Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing


'[PIC] wake from sleep using serial port on 16F77'
2010\08\02@043730 by Michael Rigby-Jones
flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam@spam@mit.edu [piclist-bouncesspamKILLspammit.edu] On
Behalf
{Quote hidden}

I have probably missed something here, but the USART will also generate
an interrupt when it receives a character in asynchronous mode.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2010\08\02@084151 by Olin Lathrop

face picon face
Michael Rigby-Jones wrote:
> I have probably missed something here, but the USART will also
> generate an interrupt when it receives a character in asynchronous
> mode.

Yes, but that requires the clock running, so can not be used to wake the
processor from sleep.  Some of the newer UARTS do have a wakeup capability.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\08\02@090019 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam.....mit.edu [EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu] On
Behalf
{Quote hidden}

the
> processor from sleep.  Some of the newer UARTS do have a wakeup
capability.
>
Right - as I suspected I was overlooking something! Thanks.

I suppose running in synchronous mode you are going to need at least 8
clock cycles to get an interrupt, worst case that could be 8 complete
bytes if those bytes happened to be 0xFF. I wonder if you could switch
the pin to an output and toggle it to 'manually' preload the USART with
7 bits prior to sleeping?  The bus conflict problem would need to be
fixed (simple resistor would probably suffice) even assuming this is
possible.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2010\08\02@135757 by Dwayne Reid

flavicon
face
At 07:00 AM 8/2/2010, Michael Rigby-Jones wrote:

>I suppose running in synchronous mode you are going to need at least 8
>clock cycles to get an interrupt, worst case that could be 8 complete
>bytes if those bytes happened to be 0xFF. I wonder if you could switch
>the pin to an output and toggle it to 'manually' preload the USART with
>7 bits prior to sleeping?  The bus conflict problem would need to be
>fixed (simple resistor would probably suffice) even assuming this is
>possible.

I don't think that will work - I *think* that the TRIS bit for the TX pin is overridden when the USART peripheral is enabled.  But - it doesn't matter.  The nature of the incoming serial bit-stream is such that I am guaranteed to see more than enough edges to fill the receive shift-register, and thus generate an interrupt.

I mentioned this on the PIClist because I had not previously seen this technique used to wake a PIC from sleep and thought that others might benefit from it.

dwayne

-- Dwayne Reid   <dwaynerspamspam_OUTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2010\08\02@143546 by Isaac Marino Bavaresco

flavicon
face
Em 2/8/2010 14:57, Dwayne Reid escreveu:
{Quote hidden}

The problem with the U(S)ARTS of most PICs is that they need the clock
to be running. The receiver samples the incoming signal synchronously
with the clock. If the clock is not running then the USART will not see
the signal.

You could connect another interrupt-capable pin together with the RX
pin, INT (usually RB0) or some interrupt-on-pin-change (usually
RB4-RB7). Then this second pin will detect the transition and wake the PIC.


Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

2010\08\02@153136 by Dwayne Reid

flavicon
face
At 12:35 PM 8/2/2010, Isaac Marino Bavaresco wrote:

>The problem with the U(S)ARTS of most PICs is that they need the clock
>to be running. The receiver samples the incoming signal synchronously
>with the clock. If the clock is not running then the USART will not see
>the signal.

That may be the case on some PICs but does NOT appear to be the case for the 16F77.  We are currently putting the PIC to sleep (clock is stopped) and it wakes after receiving 9 clock edges fed into the TX pin (which is the synchronous slave Clock pin).

The reason for this whole exercise was to avoid making a change to the existing PC board layout.  This technique does that.

dwayne

-- Dwayne Reid   <@spam@dwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2010\08\02@154421 by Isaac Marino Bavaresco

flavicon
face
Em 2/8/2010 16:31, Dwayne Reid escreveu:
> At 12:35 PM 8/2/2010, Isaac Marino Bavaresco wrote:
>
>> The problem with the U(S)ARTS of most PICs is that they need the clock
>> to be running. The receiver samples the incoming signal synchronously
>> with the clock. If the clock is not running then the USART will not see
>> the signal.
> That may be the case on some PICs but does NOT appear to be the case
> for the 16F77.  We are currently putting the PIC to sleep (clock is
> stopped) and it wakes after receiving 9 clock edges fed into the TX
> pin (which is the synchronous slave Clock pin).
>
> The reason for this whole exercise was to avoid making a change to
> the existing PC board layout.  This technique does that.
>
> dwayne


If it works, great. I personally never used the 16F77.


Isaac
__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

2010\08\02@155615 by Olin Lathrop

face picon face
Dwayne Reid wrote:
> At 12:35 PM 8/2/2010, Isaac Marino Bavaresco wrote:
>> The problem with the U(S)ARTS of most PICs is that they need the
>> clock to be running. The receiver samples the incoming signal
>> synchronously with the clock. If the clock is not running then the
>> USART will not see the signal.
>
> That may be the case on some PICs but does NOT appear to be the case
> for the 16F77.  We are currently putting the PIC to sleep (clock is
> stopped) and it wakes after receiving 9 clock edges fed into the TX
> pin (which is the synchronous slave Clock pin).

Right, because you were using it in synchronous mode where the clock comes
in with the data.  Isaac is correct when the module being used as a UART,
but not as a USART.

Some newer PIC UARTs also have a wake up feature.  I've never used it, so I
don't remember if the first byte is lost.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\08\02@171910 by Dwayne Reid

flavicon
face
At 01:56 PM 8/2/2010, Olin Lathrop wrote:

>Right, because you were using it in synchronous mode where the clock comes
>in with the data.  Isaac is correct when the module being used as a UART,
>but not as a USART.

That distinction is good to know.  Thanks for the clarification.

I've noticed that some PICs have UARTS and some have USARTS - but have not looked further than that because I didn't need to.  Now I know to pay particular attention to those subtleties when I use one of those chips.

Many thanks!

dwayne

-- Dwayne Reid   <KILLspamdwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2010\08\02@173406 by Olin Lathrop

face picon face
Dwayne Reid wrote:
>> Right, because you were using it in synchronous mode where the clock
>> comes in with the data.  Isaac is correct when the module being used
>> as a UART, but not as a USART.
>
> That distinction is good to know.  Thanks for the clarification.
>
> I've noticed that some PICs have UARTS and some have USARTS - but
> have not looked further than that because I didn't need to.  Now I
> know to pay particular attention to those subtleties when I use one
> of those chips.

In re-reading that I realize I should have said UART and USRT, in other
words Universal Asynchronous Receiver/Transmitter versus Universal
Synchronous Receiver/Transmitter.

Synchronous means the clock is explicitly sent, which is why the PIC can
wake up without the module's clock running.  In asynchronous mode the clock
is implied, and PIC implementations sample the single signal at 16x (or
sometimes 4x) the expected baud rate.  Since this clock is derived from the
instruction clock, the module can't receive characters during sleep.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\08\02@181607 by alan.b.pearce

face picon face
> The problem with the U(S)ARTS of most PICs is that they need the clock
> to be running. The receiver samples the incoming signal synchronously
> with the clock. If the clock is not running then the USART will not
see
> the signal.

Are you saying that you still need the processor clock when the USART is
running in synchronous mode like he is using to generate the initial
interrupt?

He clearly explained that the first character received is acting as the
clock to the synchronous mode, which is why he doesn't need the
processor clock.
-- Scanned by iCritical.

2010\08\02@193421 by Isaac Marino Bavaresco

flavicon
face
Em 2/8/2010 19:15, RemoveMEalan.b.pearceTakeThisOuTspamstfc.ac.uk escreveu:
>> The problem with the U(S)ARTS of most PICs is that they need the clock
>> to be running. The receiver samples the incoming signal synchronously
>> with the clock. If the clock is not running then the USART will not
> see
>> the signal.
> Are you saying that you still need the processor clock when the USART is
> running in synchronous mode like he is using to generate the initial
> interrupt?
>
> He clearly explained that the first character received is acting as the
> clock to the synchronous mode, which is why he doesn't need the
> processor clock.

I missed him saying about synchronous mode. I thought only of
asynchronous mode.

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

2010\08\02@234857 by William \Chops\ Westfield

face picon face

On Aug 2, 2010, at 2:19 PM, Dwayne Reid wrote:

>> you were using it in synchronous mode where the clock comes in with  
>> the data.

> Now I know to pay particular attention to those subtleties when I  
> use one of those chips.

Note that whether you need a sync or an async serial port tends to be  dictated by external requirements (the protocol and device you expect  to speak to).  It's not like you can say "It would be nice to go into  sleep mode while I'm waiting for data; I guess I'll look for a USART  rather than just a UART."

BillW

2010\08\03@111930 by Bob Blick

face
flavicon
face

On Mon, 2 Aug 2010 20:47:56 -0700, "William Chops Westfield" said:

> to speak to).  It's not like you can say "It would be nice to go into  
> sleep mode while I'm waiting for data; I guess I'll look for a USART  
> rather than just a UART."

Or just use an MPS430 where the oscillator can run your choice of
peripherals while the processor is in sleep mode.

Cheerful regards,

Bob

-- http://www.fastmail.fm - Faster than the air-speed velocity of an
                         unladen european swallow

2010\08\03@112157 by Olin Lathrop

face picon face
Bob Blick wrote:
> Or just use an MPS430 where the oscillator can run your choice of
> peripherals while the processor is in sleep mode.

Which sounds like pretty much the same thing as idle mode on many of the
newer PICs.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\08\03@193123 by Dwayne Reid

flavicon
face
At 03:34 PM 8/2/2010, Olin Lathrop wrote:

> >> Right, because you were using it in synchronous mode where the clock
> >> comes in with the data.  Isaac is correct when the module being used
> >> as a UART, but not as a USRT.

Yep.

Here is the relevant text from the 'F77 data sheet:

10.4 USART Synchronous Slave Mode
Synchronous Slave mode differs from the Master mode, in that the shift clock is supplied externally at the RC6/TX/CK pin (instead of being supplied internally in Master mode). This allows the device to transfer or receive data while in SLEEP mode.

Anyway, the system wakes up from sleep reliably using this technique.  The real charm is that the only hardware addition was a single resistor between the TX & RX pins on the little add-on board.

Hopefully this is of some benefit to someone someday.

dwayne

-- Dwayne Reid   <spamBeGonedwaynerspamBeGonespamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturin

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