Searching \ for '[PIC]:Timeout' 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: 'Timeout'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Timeout'
2000\08\30@225054 by Jinx

face picon face
Could I have some advice please on a bunny question. I've used
WDT in some apps but this is quite different to what I've required
before

I've a program on a battery-powered F84 unit, so consumption is
critical.

There are two main sections of code - one uploads data, the other
downloads on a PB0 IRQ. I have to put a timeout of 90 seconds
between PB0 IRQs, ie after the last byte has been sent, PB0 must
be ignored for 90 seconds. Uploading occurs in normal-power mode
and then the unit goes to sleep. PB0 is used as a wake-up. WDT
would seem to be the best low-power method, but WDT should
desirably be active for only the 90 seconds to increment a counter that
can be looked at to reject PB0 IRQs. Once say 40 * 2 seconds WDT
wake-ups have occured then PB0 IRQs will be recognised again

Is there any way/trick to stop WDT wake-ups during the vast majority
of the time that they aren't needed or is it all or nothing ? During
uploading I can sprinkle a few CLRWDTs around to stop it interfering.
IIRC from a previous job a very short wake-up uses a sniff of extra
power, but I'd prefer a mini-sniff if possible

Without any external i/p, any suggestions for an alternative to WDT
that uses less power or is this as good as I think it gets ?

TIA

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@234321 by Bob Ammerman

picon face
A couple things:

If you set the WDT up with a relatively large prescale value it will only
wake every second or so. You should be able to go back to sleep in just a
few instructions. I would classify this as a 'micro-sniff' of power.

Remember, the WDT timeout interval isn't very accurate. If your 90 seconds
has to be pretty close you might have a problem here. One thing you could do
is 'calibrate' the WDT as follows:

Start a loop that does nothing but run up a counter. Do _not_ CLRWDT in this
loop.

When the WDT reset occurs take a look at the counter value.

This will give you  a pretty good idea of the WDT interval.

Of course variations in Vcc, temperature and the phase of the moon will
affect the WDT interval.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)


{Original Message removed}

2000\08\31@005251 by Jinx

face picon face
> wake every second or so. You should be able to go back to sleep in
> just a few instructions. I would classify this as a 'micro-sniff' of
power.

Thought as much, but better to ask now. Pity you can't get to Config

> Remember, the WDT timeout interval isn't very accurate. If your 90
> seconds has to be pretty close you might have a problem here

No real accuracy required, +/- 10% OK, just a nominal timeout.
Expect it will go up and down with temp. I'll look at worst case
scenarios, stick in the fridge and a warm (!) oven with a thermo
probe on the PIC and establish some sort of benchmarks. I'll post
the results just for the record

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\08\31@071207 by Andrew Kunz

flavicon
face
>Of course variations in Vcc, temperature and the phase of the moon will
>affect the WDT interval.

At the Masters, Microchip had an app-note to do rather accurate (< 1C as I
recall) temperature measurement using internal RC and WDT timeouts.  The RC osc
is temp comp'd but the WDT is not.  This allows you to use the differential in a
loop counter to give a pretty good idea of temperature.

Andy

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\08\31@081456 by M. Adam Davis

flavicon
face
Now that's cool!

It's fun to see the little tricks and "I never thought of that" ideas in
uControllers.

-Adam

Andrew Kunz wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\08\31@085716 by Jinx

face picon face
> >Of course variations in Vcc, temperature and the phase of the moon will
> >affect the WDT interval.
>
> At the Masters, Microchip had an app-note to do rather accurate (< 1C as I
> recall) temperature measurement using internal RC and WDT timeouts.  The
> RC osc is temp comp'd but the WDT is not.  This allows you to use the
> differential in a loop counter to give a pretty good idea of temperature.
>
> Andy

One of the things I was hoping to quantitise, finding the % spread over a
couple of dozen F84s. Don't need a thermometer right now but I might do
one day and it'd be nice to have my own empirical results for reference

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\08\31@090550 by Andrew Kunz

flavicon
face
>One of the things I was hoping to quantitise, finding the % spread over a
>couple of dozen F84s. Don't need a thermometer right now but I might do
>one day and it'd be nice to have my own empirical results for reference

That was asked.  They said that you can't even do that for chips within the same
lot - they're all over the place.  You should probably burn test code into the
chip to determine the calibration for that chip, then re-burn it with the
production code using that cal factor.

BTW, they are also saying 7mS rather than 9mS for the WDT min timeout now...

Andy

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


'[PIC]:Timeout'
2000\09\01@005713 by Jinx
face picon face
> That was asked.  They said that you can't even do that for chips within
> the same lot - they're all over the place

> Andy

I'm sure cost is a factor but if the WDT could be trimmed at time of
chip fabrication to be an accurate temp sensor (as well as a more
predictable timer) that would be quite a useful and marketable feature.
I'll still look into WDT spec v temp just out of curiosity. It may be that
"all over the place" isn't too bad after all

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\09\01@005727 by Jinx

face picon face
Can anyone offer explanations please. This code did not work
quite as I expected. It's a test routine for checking WDT/b0 IRQ
on the F84

b0 - IRQ i/p (pushbutton, 10k pulldown, debounced). NB even though
       Option has been set for rising edge trigger, IRQ occurs on falling
       edge - comments ?)
b6 - red LED
b7 - green LED

The flow is - push button to generate IRQ. Red LED on for 2s,
red LED off for 2s, green LED on for 2s, exit. The middle
section (zzz3) does show a low power sleep on a meter so I
assume zzz2 and zzz4 sleeps are working too

During this time, I expected b0 IRQs to be disabled. However,
without the explicit "bcf inte", b0 IRQs can still occur, even
though they should have been turned off by an implicit "bcf gie"
on entry into the ISR. If the pushbutton is pressed while the
green LED is on, it goes off and the red comes on, showing that
ISR has been re-entered

With "bcf inte" included, b0 IRQs are disabled as I thought they
should have been. Why is this so ? I can find no reason for it in the
documentation (it could be my paperwork that's deficient). What
also puzzles me is why if the PB is pressed while the green LED is
on (and IRQs are supposedly inactive), after the green goes off, the
flow immediately goes back to lighting the red LED, ie an IRQ seems
to be stored for processing after the current ISR is done, so why does
the "bcf intf" have no effect (assuming intf had somehow been set) ?

TIA

 org irq
 goto isr

entry    movlw  00h        ;...o oooo
           tris   porta
           movlw  01h        ;oooo oooi
           tris   portb
           movlw  0c8h      ;pull-ups off, WDT, r/edge b0 INT
           option

           clrf   porta
           clrf   portb
           bsf    inte           ;enable b0 IRQ
           bsf    gie

zzz1        sleep               ;wait for IRQ
               nop
               nop
               goto   zzz1       ;loop if WDT, resume after isr

;IRQ routine

isr        bcf    intf
           bcf    inte

           bsf    rled            ;red on
           movlw  0a0h
           movwf  count
zzz2     sleep                  ;timeout1
           incfsz count,f
           goto   zzz2
           bcf    rled            ;red off

           movlw  0a0h
           movwf  count
zzz3     sleep                  ;timeout2
           incfsz count,f
           goto   zzz3

           bsf    gled           ;green on
           movlw  0a0h
           movwf  count
zzz4     sleep                  ;timeout3
           incfsz count,f
           goto   zzz4
           bcf    gled           ;green off
           bcf    intf
           bsf    inte
           retfie

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\09\01@095701 by Jinx

face picon face
> b0 - IRQ i/p (pushbutton, 10k pulldown, debounced). NB even though
>         Option has been set for rising edge trigger, IRQ occurs on falling
>         edge - comments ?)

Apologies, reported believed problem, in fact I was using a previous
version of .asm with trigger level set to falling edge. However, problem
with b0 IRQ remains

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\09\01@124757 by Dan Michaels

flavicon
face
Jinx wrote:
>Can anyone offer explanations please. This code did not work
>quite as I expected. It's a test routine for checking WDT/b0 IRQ
>on the F84
.........
>During this time, I expected b0 IRQs to be disabled. However,
>without the explicit "bcf inte", b0 IRQs can still occur, even
>though they should have been turned off by an implicit "bcf gie"
>on entry into the ISR. If the pushbutton is pressed while the
>green LED is on, it goes off and the red comes on, showing that
>ISR has been re-entered
>

Hello Mr. Bad-luck [inside joke],

I think I have an answer to some of your problems [but only the
easy ones].

AFAICT, the docs aren't that clear about **all** of the weird interactions
between IRQs, sleep, and WDT, but looking at Fig 8-14 for the 16C84
(pg 2-767 in '95 databook) shows that the interrupt inputs have a
parallel "snaek" pathway that bypasses the normal IRQ channel and goes
straight to the wakeup from sleep ckt. So doesn't matter whether GIE is
enabled, but does matter if INTE is.

Pushing the button in your code while sleeping doesn't actually cause
an IRQ, but rather a direct wakeup from sleep.
==============

>With "bcf inte" included, b0 IRQs are disabled as I thought they
>should have been. Why is this so ? I can find no reason for it in the
>documentation (it could be my paperwork that's deficient). What
>

As noted above, without that "bcf inte" included, the button press
functions via the parallel sneak pathway just described, and then
it looks like a "2nd" time, since after you come out of the ISR-sleep
loop, and back into the real world, you get an actual IRQ.

Hope this helps ring out the problems.

As noted offlist, I think if I were writing this kinda thing, that
I would move the sleep-LED-blink sequencing stuff outside of the
ISR, and into a routine callable from the main program loop, and
simply use the IRQ to trigger the sequence by setting a flag.

An advantage of this approach is that you could actually insert this
kind if thing more easily into a normal program with fewer interdependency
problems.

best regards,
- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\09\01@193428 by Jinx

face picon face
> AFAICT, the docs aren't that clear about **all** of the weird interactions
> between IRQs, sleep, and WDT, but looking at Fig 8-14 for the 16C84
> (pg 2-767 in '95 databook) shows that the interrupt inputs have a
> parallel "sneak" pathway that bypasses the normal IRQ channel and goes
> straight to the wakeup from sleep ckt. So doesn't matter whether GIE is
> enabled, but does matter if INTE is.

Yes that's quite true, b0 will generate a wake-up whatever GIE is set to
and if INTE is set a true IRQ will be processed. As I said, I can stop b0
generating an immediate IRQ when s/w is already in an ISR, but the
problem still is that somehow the PIC stores a request, ready to process
it once the current ISR has finished. So far I've found no way to stop
this happening.

If <bcf intf> doesn't prevent it then where the heck is this request being
stored ? INTF would be the obvious cuplrit

If there really is an insurmountable problem when using WDT/SLEEP/
b0 inside an ISR I'd like to see it documented, so that I can abandon
that method and rewrite some code. If b0 can be completely disabled/
ignored I'd rather stick with the code I've got

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\09\02@141849 by Dwayne Reid

flavicon
face
>
>Yes that's quite true, b0 will generate a wake-up whatever GIE is set to
>and if INTE is set a true IRQ will be processed. As I said, I can stop b0
>generating an immediate IRQ when s/w is already in an ISR, but the
>problem still is that somehow the PIC stores a request, ready to process
>it once the current ISR has finished. So far I've found no way to stop
>this happening.

I guess that I am obtuse, but I still don't understand the problem!  Yes,
if you have GIE cleared but INTE set, the pic will wake up from sleep when
RB0 triggers (you select rising or falling edge as desired).  But if GIE is
NOT set, you will wake from sleep but NOT enter the ISR.  Now what happens
is up to you.  If you need interrupts, you have to clear INTF before you
enable GIE.  Remember - you had an event on RB0 - that is what woke you
up.  You have to clear the interrupt flag or it WILL cause an interrupt as
soon as you enable GIE.

Or - like I said, I am being obtuse and I don't understand your problem.

dwayne



Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 16 years of Engineering Innovation (1984 - 2000)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use .....listservKILLspamspam@spam@mitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\02@180256 by Jinx

face picon face
> >Yes that's quite true, b0 will generate a wake-up whatever GIE is set to
> >and if INTE is set a true IRQ will be processed. As I said, I can stop b0
> >generating an immediate IRQ when s/w is already in an ISR, but the
> >problem still is that somehow the PIC stores a request, ready to process
> >it once the current ISR has finished. So far I've found no way to stop
> >this happening.
>
> I guess that I am obtuse, but I still don't understand the problem!  Yes,
> if you have GIE cleared but INTE set, the pic will wake up from sleep when
> RB0 triggers (you select rising or falling edge as desired).  But if GIE
is
> NOT set, you will wake from sleep but NOT enter the ISR.  Now what happens
> is up to you.  If you need interrupts, you have to clear INTF before you
> enable GIE.  Remember - you had an event on RB0 - that is what woke you
> up.  You have to clear the interrupt flag or it WILL cause an interrupt as
> soon as you enable GIE.
>
> Or - like I said, I am being obtuse and I don't understand your problem.

> dwayne

No, I'm sure you're not being obtuse. IRQ/GIE/INTF etc I understand OK
and the s/w works (generally) as expected. The problem is that somehow
the F84 is storing a request from b0. If you read my post of a couple of
days ago you'll see that even with every register connected with b0 set
to completely disable or ignore an IRQ, if b0 is pressed during an ISR
the PIC will immediately jump back into a new ISR when the current one
has finished. Despite GIE, INTE and INTF being clear during the first ISR.
My question in that post was "where is that request being held ?" I spent
the best part of yesterday trying to track it down and am still none the
wiser, after all, there aren't that many places to look. I've yet to find
any
documented advice not to use WDT/SLEEP in an ISR for example, and
wondered if any other users had had this problem of unwanted stored
interrupt requests

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use listservspamKILLspammitvma.mit.edu?body=SET%20PICList%20DIGEST>

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