Searching \ for 'Wakeup time from sleep on 16C84???' 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/time.htm?key=time
Search entire site for: 'Wakeup time from sleep on 16C84???'.

Truncated match.
PICList Thread
'Wakeup time from sleep on 16C84???'
1997\05\24@220215 by Bo Berglund

flavicon
face
I want to know if there is information available on the time delay
>from arrival of a wakeup interrupt to actual processing start on a
16C84.
I want to use my '84 as a code receiver and have it sleep
between transmissions. Codes are sent at 1200 baud and I use
a 1MHz resonator as clock source (configured as XT type).
Is the wakeup time short enough and stable enough to not miss
the first information bit?
In the documentation they say that the time delay is 1024 clock
cycles, but what about the time for the oscillator to start?
Is this startup time temperature dependent? If so how much?

I hope someone out there knows the answer to this one... :-)


Cheers!

Bo Berglund
PaddelvŠgen 10, S-17545 JŠrfŠlla, Sweden
e-mail: spam_OUTbo.berglundTakeThisOuTspammailbox.swipnet.se

1997\05\24@220634 by Allen J. Kook

picon face
yes ther is a slight time delay because it has to resume where had left off.
its prbably not that long of a delay though probably a cyle or two

1997\05\24@233154 by John Payson

picon face
> I want to know if there is information available on the time delay
> from arrival of a wakeup interrupt to actual processing start on a
> 16C84.

The time, in XT mode, is 1024 cycles minimum, where those cycles are
whatever speed the crystal runs before it stabilizes.

> I want to use my '84 as a code receiver and have it sleep
> between transmissions. Codes are sent at 1200 baud and I use
> a 1MHz resonator as clock source (configured as XT type).

> Is the wakeup time short enough and stable enough to not miss
> the first information bit?

Dicey at best.  At 1200 baud, the wakeup will probably eat a good chunk of
your start bit, but probably none of the first data bit.  If you really want
to do this, I'd guess you should probably sample the first data bit about
1000us after you wake up (sample the rest at 833us intervals thereafter).
Dwibble an unused port pin when you sample the first data bit and check with
a scope to see how well centered it is.

> In the documentation they say that the time delay is 1024 clock
> cycles, but what about the time for the oscillator to start?
> Is this startup time temperature dependent? If so how much?

The startup time will be somewhat dependent upon ambient temperature, the
make of crystal, the caps you use with it, the phase of the moon, etc.  If
you're lucky, though, it will more-or-less consistent.

> I hope someone out there knows the answer to this one... :-)

It will be highly dependent upon many factors.  The only thing you can do
is experiment (and if you mass-produce this thing, test each unit to ensure
that it samples the first bit within a small tolerance of center).

Depending upon what else your CPU is doing, another option might be to use
an RC oscillator and adjust your baud rate so it's correct (i.e. analyze the
incoming data to determine how fast or slow your RC is, and adjust your read
logic accordingly).  This would have the advantage that the oscillator would
start "instantly", but would have the disadvantage that you'd need to deal
with the RC's inaccuracies.  This is assuming, btw, that you're not going to
be idle for so long between data bytes that the ambient temperature will
change significantly.  If you are, then you're sunk.

1997\05\25@013146 by Bruce Cannon

flavicon
face
Why not use a faster osc?  10Mhz would both speed startup and reduce the
temp dependent freq variation by a factor of ten, right?

>I want to use my '84 as a code receiver and have it sleep
>between transmissions. Codes are sent at 1200 baud and I use
>a 1MHz resonator as clock source (configured as XT type).
>Is the wakeup time short enough and stable enough to not miss
>the first information bit?

1997\05\25@044520 by Bo Berglund

flavicon
face
part 0 702 bytes

Bo Berglund
PaddelvŠgen 10, S-17545 JŠrfŠlla, Sweden
e-mail: .....bo.berglundKILLspamspam@spam@mailbox.swipnet.se


----------
From:   Bruce Cannon[SMTP:bcannonspamKILLspamCCNET.COM]
Sent:   den 25 maj 1997 07:16
To:     .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
Subject:        Re: Wakeup time from sleep on 16C84???

Why not use a faster osc?  10Mhz would both speed startup and reduce the
temp dependent freq variation by a factor of ten, right?

>I want to use my '84 as a code receiver and have it sleep
>between transmissions. Codes are sent at 1200 baud and I use
>a 1MHz resonator as clock source (configured as XT type).
>Is the wakeup time short enough and stable enough to not miss
>the first information bit?


1997\05\25@124719 by John Payson

flavicon
face
> The reason for the low clock speed is that I MUST get the thingie
> to use as low current as ever possible. If I look in the data sheet
> it seems like the curent consumption is approx proportional to
> the clock rate, hence this low clock freq.
> I am trying to replace an EPLD logic circuit with the PIC16C84
> and the requirement is that operating current has to be below
> 500 uA. With the sleep trick I can probably get it down there as
> average current because of the low signalling duty cycle.
> But I think that 10 MHz clock will raise current too much.
> Code packets consist of 4 chars at 1200 baud which effectively
> keeps the PIC out of sleep for about 33 ms.

I don't know what else your application is doing, but might it be possible
to use a 32KHz PIC and just leave it running all the time?  1200 baud is
possible on such a device of you're not doing anything else while waiting
for a character.  If you had an interrupt on the start bit, you may even
be able to do other processing while waiting for characters but I've never
done it that way.

1997\05\25@150023 by Bo Berglund

flavicon
face
part 0 1920 bytes
After reception I have to dig out the information which is hidden in the 4 chars
and find out if I am the addressee, in which case I must act on the data.
The bits are scrambled to make it work with a simple logic circuit (3 bits are
stuffed into each character) so I have 12 bits of real info here. 8 bits are a
unit address and 4 bits are actual data.
With the new circuit I want to also expand on the coding so i might add some
more codes - giving more things to decode.
Well, I just have to figure out the best way I guess...

Cheers!

Bo Berglund
PaddelvŠgen 10, S-17545 JŠrfŠlla, Sweden
e-mail: EraseMEbo.berglundspam_OUTspamTakeThisOuTmailbox.swipnet.se


----------
From:   John Payson[SMTP:supercatspamspam_OUTMCS.COM]
Sent:   den 25 maj 1997 13:52
To:     @spam@PICLISTKILLspamspamMITVMA.MIT.EDU
Subject:        Re: Wakeup time from sleep on 16C84???

{Quote hidden}

I don't know what else your application is doing, but might it be possible
to use a 32KHz PIC and just leave it running all the time?  1200 baud is
possible on such a device of you're not doing anything else while waiting
for a character.  If you had an interrupt on the start bit, you may even
be able to do other processing while waiting for characters but I've never
done it that way.


1997\05\26@100533 by Larry G. Nelson Sr.

flavicon
face

At 10:41 AM 5/25/97 +0200, you wrote:
{Quote hidden}

Larry G. Nelson Sr.
TakeThisOuTL.NelsonEraseMEspamspam_OUTieee.org
http://www.ultranet.com/~nr

1997\05\28@093502 by Josef Hanzal

flavicon
face
>I don't know what else your application is doing, but might it be possible
>to use a 32KHz PIC and just leave it running all the time?  1200 baud is
>possible on such a device of you're not doing anything else while waiting
>for a character.  If you had an interrupt on the start bit, you may even
>be able to do other processing while waiting for characters but I've never
>done it that way.

Example of the 1200 Bd receiver code (interrupt initiated) can be found in
Microcomputer Journal September/October 1995, pg. 67. The project is a low
power data logger, running about a year from one 9V battery. If you would
satisfy with the code only without further comments, I can send it, but
there is lots of other ideas perhaps useful for your project.

1997\05\28@094812 by Ross McKenzie

flavicon
face
Hello Josef,

Does this code allow for 2 stop bits? I would be interested if yes.

Regards,

Ross McKenzie
Melbourne Australia

At 15:25 28/05/97 +0200, you wrote:
{Quote hidden}

1997\05\28@100735 by Raak, Cory

flavicon
face
part 0 899 bytes
{Quote hidden}

1997\05\29@084439 by Josef Hanzal

flavicon
face
>Does this code allow for 2 stop bits? I would be interested if yes.
>
>Regards,
>
>Ross McKenzie
>Melbourne Australia
>

Hi Ross,

The code does not check the start and stop bits, so you can have any number
of them, 1, 1.5 or 2. The asynchronous protocol specifies the stop bits as a
minimum time, so you can always have more.

Before enabling interrupts, load the RCCNT variable with 8 and clear RCBF
flag. Select appropriate edge for the external interrupt - if using MAX232
or similar, then high to low transition. It is also possible to use only
current limiting resistor and two diodes to ground and +5V (or no diodes at
all since there are protection ones in the PIC), then the signal polarity is
inverted and you need to select rising edge.
At least litle comments of the code: At 32 kHz and 1200 Bd you have 7 clocks
to process a bit. After receiving interrupt, there is 3 to 4 cycles latency
and another 6 instructions you spend saving W and STATUS registers. Other
words you do not have time to check the start bit. If there is only external
interrupt enabled, you could skip testing the INTF bit and test RB0 instead
for valid start bit. Having one interrupt only would be anyway necessary,
since you could miss a character while servising the other interrupt, the
response has to be immediate.You could also add a stop bit test at the end
of the interrupt routine, but here the time is spared to process the
received character in the main loop.

Original code, tested and working (better say copied from working program
and made look prettier):

       CBLOCK xxx
       TEMPW, TEMPS, RCCNT, RCDATA, FLAGS
       ENDC

       ORG     4
INTER:  MOVWF   TEMPW           ;SAVE REGISTERS
       SWAPF   STATUS,W
       MOVWF   TEMPS
       BTFSS   INTCON,INTF
       GOTO    ...ANOTHER INTERRUPT SERVICE
       BCF     STATUS,C

I0:     BTFSC   PORTB,RB0       ;8 BIT LOOP  (OR BTFSS FOR INVERTED POLARITY)
       BSF     STATUS,C
       RRF     RCDATA,F
       BCF     STATUS,C
       DECFSZ  RCCNT,F
       GOTO    I0

       BSF     FLAGS,RCBF      ;SET CHARACTER RECEIVED FLAG (RECEIVE BUFFER
FULL)
       MOVLW   8               ;RESTORE RCCNT
       MOVWF   RCCNT

       BCF     INTCON,INTF     ;CLEAN UP AFTER INTERRUPT AND RESTORE REGISTERS
       SWAPF   TEMPS,W
       MOVWF   STATUS
       SWAPF   TEMPW,F
       SWAPF   TEMPW,W
       RETFIE

In the main loop you work about this way:

MAIN:   BTFSS   FLAGS,RCBF
       GOTO    MAIN
       BCF     FLAGS,RCBF
       MOVF    RCDATA,W
       ....PROCESS THE CHARACTER
       GOTO    MAIN

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++
Possible enhancements, not tested:

       ORG     4
INTER:  BTFSC   PORTB,RB0       ;TEST START BIT (OR BTFSS FOR INVERTED POLARITY)
       RETFIE
       MOVWF   TEMPW           ;SAVE REGISTERS
       SWAPF   STATUS,W
       MOVWF   TEMPS,F
       BCF     STATUS,C

I0:     BTFSS   PORTB,RB0       ;8 BIT LOOP
       BSF     STATUS,C
       RRF     RCDATA,F
       BCF     STATUS,C
       DECFSZ  RCCNT,F
       GOTO    I0

       NOP
       BTFSS   PORTB,RB0       ;TEST FIRST STOP BIT
       BSF     FLAGS,RCFE      ;SET FRAMING ERROR FLAG

       BSF     FLAGS,RCBF      ;SET CHARACTER RECEIVED FLAG (RECEIVE BUFFER
FULL)
       MOVLW   8               ;RESTORE RCCNT
       MOVWF   RCCNT

       BCF     INTCON,INTF     ;CLEAN UP AFTER INTERRUPT AND RESTORE REGISTERS
       GOTO    $+1             ;TWO CYCLES NOP
       BTFSS   PORTB,RB0       ;TEST SECOND STOP BIT
       BSF     FLAGS,RCFE      ;SET FRAMING ERROR FLAG

       SWAPF   TEMPS,W
       MOVWF   STATUS
       SWAPF   TEMPW,F
       SWAPF   TEMPW,W
       RETFIE

Testing start bit would be certainly helpful to avoid false reception
initiated by spikes on the RB0 pin, but testing stop bits seems less useful
to me. Even if you discover framing error what would you do ? Trash the byte
? Ask for resend ?

Regards

Josef Hanzal
Czech Republic
RemoveMEeuroclassspamTakeThisOuTpha.pvtnet.cz

1997\05\29@185444 by Lee Jones

flavicon
face
> Testing start bit would be certainly helpful to avoid false
> reception initiated by spikes on the RB0 pin,

Hardware UARTs/USARTs resample the input signal 1/2 bit time
after detecting an edge.  If the signal is still there, it is
considered a valid start bit.  If not, it's ignored as noise.

> but testing stop bits seems less useful to me. Even if you
> discover framing error what would you do ? Trash the byte ?
> Ask for resend ?

Hardware USARTs generally return a framing or overrun error
and (I think) along with the data which was received.  Upper
level software then chooses what do to with the octet (ask
for resend, etc).
                                               Lee Jones

1997\05\30@093737 by John Payson

flavicon
face
>
> > but testing stop bits seems less useful to me. Even if you
> > discover framing error what would you do ? Trash the byte ?
> > Ask for resend ?
>
> Hardware USARTs generally return a framing or overrun error
> and (I think) along with the data which was received.  Upper
> level software then chooses what do to with the octet (ask
> for resend, etc).

Different UART's behave differently things when they receive an
incorrectly-framed packet.  The approach I took in my interrupt-driven
software UART (which I personally would like to see done in hardware) is
to hold the last 32 bits that came in [sampled with a 3xbaud clock] and
grab a byte whenever a properly-aligned byte has been shifted in.  IMHO,
this should allow the UART to correctly-align itself after a framing error
much faster than the conventional techniques (other approaches include
delaying start-bit detect until the next *falling edge*, or regarding the
missing stop bit as the next byte's start bit).  Does anyone know if any
hardware designer has ever done a UART this way?

1997\05\30@182350 by Andy Kunz

flavicon
face
At 08:40 AM 5/30/97 +0000, you wrote:
>Different UART's behave differently things when they receive an
>incorrectly-framed packet.  The approach I took in my interrupt-driven
>software UART (which I personally would like to see done in hardware) is
>to hold the last 32 bits that came in [sampled with a 3xbaud clock] and
>grab a byte whenever a properly-aligned byte has been shifted in.  IMHO,
>this should allow the UART to correctly-align itself after a framing error
>much faster than the conventional techniques (other approaches include
>delaying start-bit detect until the next *falling edge*, or regarding the
>missing stop bit as the next byte's start bit).  Does anyone know if any
>hardware designer has ever done a UART this way?

Nice concept, but 3x might not be too much fun to implement in h/w.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\05\31@012411 by John Payson

flavicon
face
> At 08:40 AM 5/30/97 +0000, you wrote:
> >Different UART's behave differently things when they receive an
> >incorrectly-framed packet.  The approach I took in my interrupt-driven
> >software UART (which I personally would like to see done in hardware) is
> >to hold the last 32 bits that came in [sampled with a 3xbaud clock] and
> >grab a byte whenever a properly-aligned byte has been shifted in.  IMHO,
> >this should allow the UART to correctly-align itself after a framing error
> >much faster than the conventional techniques (other approaches include
> >delaying start-bit detect until the next *falling edge*, or regarding the
> >missing stop bit as the next byte's start bit).  Does anyone know if any
> >hardware designer has ever done a UART this way?
>
> Nice concept, but 3x might not be too much fun to implement in h/w.

I'll admit that a shift register wired this way will be three times (or
five times, or whatever) times as large as the one in a conventional UART.
The extra 20/40/whatever bits of shifter should be offset, however (IMHO)
by the simpler framing logic: rather than having to count the incoming
bits, you can just look for the proper pattern:

  100--d--d--d--d--d--d--d--d--1

When the shifter contains the leaidng "100" and the final "1", then sample
all of the "d"'s and clear the shifter.  Should be quite simple and
effective, and would allow recovery of many framing errors conventional
units can't handle (for example, many uarts will *never* resync if fed an
endless stream of ASCII text and they mistakenly sync on bit 7 of a byte).

Personally, I'd think there would be two logical methods of UART design:
one would be to use a shift register and look for a pattern.  The other
approach would be to have the transmit and receive use seperate
clock/counter circuits and have the receive clock run at either 1/2 or 1/3
the bit rate *when there is actually data there* (otherwise keep the clock
zeroed).  If "1/2 the bit rate" is chosen, then sample the start bit after
the first clock, and data bits after clocks three, five, seven, etc.  If
"1/3 the bit rate" is chosen, then time could be divided into "stable" and
"transition" zones; if the signal changes during a time it's supposed to
be stable, an error could be flagged.

While this latter approach would require seperate programmable dividers
for transmit and receive, this would have the benefit of allowing distinct
TX/RX rates and also allow the divide-by-16 in most UARTs to be replaced
with a divide-by-two.  In addition, the idle current for a UART that was
waiting to transmit/receive data could be reduced because the divider
wouldn't have to be running except when transmission or reception was in
progress.

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