Searching \ for '[PIC]:portB external interrupts (interrupt on chan' 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: 'portB external interrupts (interrupt on chan'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:portB external interrupts (interrupt on chan'
2000\11\09@110325 by Mike Mansheim

flavicon
face
I did not receive any replies to a post on this subject a
few days ago - please let me know if I did something wrong
(post too long??)
This is a considerably shorter version of the question:

On a 16F876, can the port B "interrupt on change" feature
be used reliably for external interrupts, _IF_ there is no
other usage on port B?  Or, as I read on Andy Warren's
answer page, is this feature still only good for waking
the processor up from sleep mode?

Thanks,
Mike Mansheim

--
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\11\09@112606 by Bob Ammerman

picon face
Mike,

Sorry nobody helped the first time. I saw your post and figured someone
would answer.

The "interrupt on change" feature _will_ work reliably with a couple of
caveats:

Any time you read the port you will reset the 'current value' condition for
the pins.

So, if you take an interrupt and read the port to see what changed it will
reset the interrupt condition. This is good.

Where you get in trouble is if _another_ change in the input occurs just at
the moment you are reading the port. In this case you can miss it.

But, if you know for certain that a second change on any of the inputs
cannot occur before you get into your interrupt handler and read the status
you will be ok.

That's probably as clear as mud.

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


{Original Message removed}

2000\11\09@113852 by Simon Nield

flavicon
face
I don't remember your original post, so it may well have been a little verbose :)
I may be missing something here but I have used the interrupt on change for a software UART without
any problems... prehaps Andy was just suggesting one good use for the feature ?

Regards,
Simon

--
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\11\09@135907 by Morgan Olsson

picon face
Bob Ammerman wrote:
>Any time you read the port you will reset the 'current value' condition for
>the pins.

...and if you have routine(s) that need the value more than once, read Port B into an register, and do it as soon as that interrupt is detected, and clear interrupt flag.  Then the hardware can detect a new change while the software is busy evaluating the old change.

I have had no problem at all with interrupt on change on a PIC16F877, even with using some pins as output and using the ICD (uses pins on Port B).

You may also byte-write (movwf and clrf) to port B without disturbing interrupt on change, just do not do any kind of reading except for the one instance in interrupt routine. (Remember that BSF/BCF actually begins by executing a read...)

Regards
/Morgan

--
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\11\09@143102 by Andrew Warren

flavicon
face
Mike Mansheim <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> I did not receive any replies to a post on this subject a few days
> ago - please let me know if I did something wrong (post too long??)
> This is a considerably shorter version of the question:
>
> On a 16F876, can the port B "interrupt on change" feature be used
> reliably for external interrupts, _IF_ there is no other usage on
> port B?  Or, as I read on Andy Warren's answer page, is this
> feature still only good for waking the processor up from sleep
> mode?

   Sorry, Mike; I didn't see your post, otherwise I would have
   answered it.

   If you NEVER access the PORTB register (i.e., you neither read
   it nor write it, either directly or through the FSR), the
   "interrupt on change" feature will work fine whether the
   processor's awake or asleep.

   In your case (I just found your original message and read it),
   you ARE reading PORTB in your ISR, so it's possible that that's
   what's making your code fail.  I know that you believe that the
   I/O pins can't be changing state at the moment that you read
   PORTB, but it seems clear that they actually are.  Could there
   be switch-bounce or other noise on your PORTB inputs?

   One way to solve the problem, if you have available pins, is to
   tie your inputs to BOTH Port B and another port, then ONLY check
   the input states by looking at that other port.

   Good luck...

   -Andy


=== Andrew Warren --- .....aiwKILLspamspam@spam@cypress.com
=== Cypress Semiconductor Corporation
=== Interface Products Division, S.D.
===
=== The opinions expressed above do
=== not necessarily represent those of
=== Cypress Semiconductor Corporation.

--
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\11\09@143445 by Andrew Warren

flavicon
face
Simon Nield <PICLISTspamKILLspamMITVMA.MIT.EDU> wrote:

> I may be missing something here but I have used the interrupt on
> change for a software UART without any problems... prehaps Andy was
> just suggesting one good use for the feature ?

Simon:

No, I was saying that if the PORTB register is accessed by your code,
then the ONLY 100%-reliable use for the interrupt-on-change feature
is for waking the processor from sleep mode.

To see what Mike was asking about, point your browser to:

   http://home.netcom.com/~fastfwd/answers.html#PIC00088

-Andy


=== Andrew Warren --- .....aiwKILLspamspam.....cypress.com
=== Cypress Semiconductor Corporation
=== Interface Products Division, S.D.
===
=== The opinions expressed above do
=== not necessarily represent those of
=== Cypress Semiconductor Corporation.

--
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\11\09@144815 by Andrew Warren

flavicon
face
Morgan Olsson <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

> You may also byte-write (movwf and clrf) to port B without
> disturbing interrupt on change, just do not do any kind of reading
> except for the one instance in interrupt routine. (Remember that
> BSF/BCF actually begins by executing a read...)

Morgan:

No, you can't avoid reading PORTB by using MOVWF, CLRF, etc.

EVERY instruction that accesses PORTB reads it; the "write"
instructions just throw away the values that they read.

-Andy


=== Andrew Warren --- aiwspamspam_OUTcypress.com
=== Cypress Semiconductor Corporation
=== Interface Products Division, S.D.
===
=== The opinions expressed above do
=== not necessarily represent those of
=== Cypress Semiconductor Corporation.

--
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\11\10@042828 by Morgan Olsson

picon face
Andrew Warren wrote:
>Morgan Olsson <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU> wrote:
>
>> You may also byte-write (movwf and clrf) to port B without
>> disturbing interrupt on change, just do not do any kind of reading
>> except for the one instance in interrupt routine. (Remember that
>> BSF/BCF actually begins by executing a read...)
>
>Morgan:
>
>No, you can't avoid reading PORTB by using MOVWF, CLRF, etc.
>
>EVERY instruction that accesses PORTB reads it; the "write"
>instructions just throw away the values that they read.
>
>-Andy

In practice that seem not to be the case.  Can you give some pointer to an document describing movwf and clrf doing reads?

In my current project I frequently move debug information out on port B (using the lowest three bits set as outputs) both during interrupt and in main, and I have never observed any side effects.

/Morgan

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




2000\11\10@182259 by Andrew Warren

flavicon
face
Morgan Olsson <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> > EVERY instruction that accesses PORTB reads it; the "write"
> > instructions just throw away the values that they read.
>
> In practice that seem not to be the case.

   Morgan:

   If you design a test for the behavior I described (e.g., a
   variable-frequency square-wave input to PORTB, a foreground
   routine that does nothing but write to PORTB in a tight loop, an
   ISR that toggles a PORTA pin on every PORTB change,  and two
   external counters whose readouts you can compare), you'll see
   that it is, indeed, the case.

> Can you give some pointer to an document describing movwf and clrf
> doing reads?

   No.

> In my current project I frequently move debug information out on
> port B (using the lowest three bits set as outputs) both during
> interrupt and in main, and I have never observed any side effects.

   Some PICs don't miss portb-change interrupts even if the
   pin-state changes during an explicit read; if you're using one of
   those chips, you'll never see the problem.

   If you're using one of the chips that DOES have the problem,
   though, the fact that you haven't seen it in your current
   project doesn't mean that it doesn't (or won't) happen.

   -Andy


=== Andrew Warren --- RemoveMEaiwTakeThisOuTspamcypress.com
=== Cypress Semiconductor Corporation
=== Interface Products Division, S.D.
===
=== The opinions expressed above do
=== not necessarily represent those of
=== Cypress Semiconductor Corporation.

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




2000\11\10@214807 by Dwayne Reid

flavicon
face
At 03:07 PM 11/10/00 -0800, Andrew Warren wrote:

>     Some PICs don't miss portb-change interrupts even if the
>     pin-state changes during an explicit read; if you're using one of
>     those chips, you'll never see the problem.

Hi Andy.

I assume by the above statement that there certain versions of PIC that
don't have the problem?  Do you recall which part numbers those might be?

dwayne



Dwayne Reid   <spamBeGonedwaynerspamBeGonespamplanet.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 hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\11\11@072047 by Morgan Olsson

picon face
Andrew W, you are right according to the text in the docs: the text say not only reads, but also writes to Port B ends the mismatch condition.

However I have found tests showing agaist it

Also it is nonconsistent with how for example TMR0 prescaler is affeted of any kind of writes to TMR0, but is unaffected by read.


>> Can you give some pointer to an document describing movwf and clrf
>> doing reads?

>    No.

Neither can I.

And since TIMER0 and some other regs is not affected I find it hard to believe that Mchip should use extra silicon to decode other cycles for them.  Especially as it is better function if Port B  match reg is not affected by movwf and clrf.

Against this asumption is i believe probably the core is easiest implemented such that read enable is active during beginnig of every instruction.

assumptions...

For testing I have used this:
The PortB interrupt on change is driving an decode routine for an incremental rotary encoder.  The interrupt then occours on every phase change, and the routine is setting a warning flag and LED if it detects one step missing (i.e both phases changed since last int)  That would effectively catch any missed interrupts.

I have used a DC motor to rotate the encoder at high speed, and the LED lits distinctively at a certain rpm (where the interrupt can´t process more updates), not a glitch below that rpm, been running for hours.  Even though I have debug routines both in main and in the interrupt that writes to port B, and also a 4kHz TMR0 interrupt running other routines.

This is not a proof, it might just be much luck during tests, but i find it hard to believe.

I´ll try to make up a better test

/Morgan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu?bodyT%20PICList%20DIGEST




2000\11\11@073115 by Morgan Olsson

picon face
Hej Dwayne Reid. Tack för ditt meddelande 03:45 2000-11-11 enligt nedan:
>At 03:07 PM 11/10/00 -0800, Andrew Warren wrote:
>
>>    Some PICs don't miss portb-change interrupts even if the
>>    pin-state changes during an explicit read; if you're using one of
>>    those chips, you'll never see the problem.
>
>Hi Andy.
>
>I assume by the above statement that there certain versions of PIC that
>don't have the problem?  Do you recall which part numbers those might be?
>
>dwayne

I it would be interesting to see how they could solve that.  I believe it would need some double buffering like in the software solution I propose later below.

According to the schematics in the current docs, both Mid Range Reference Manual fig 9-5, and F877 datasheet fig 3-4, according when the update of the compare register in port B: In the lower right corner it shows that the Read enable for the port must be active during Q3 for the compare register to update.

Now, turning to fig 9-12 and 9-13 in Mid Range Reference Manual, it says reads latch the data in the end of Q1.

So if we read the port we get the data it have in end of Q1.

The schematics implies that the port read signal is active also through Q3 (otherwise the Port B, if following the schematic, would never update),
and during Q3 the compare register is updated. (latch enable bu Read port ANDed with Q3)

Any port change that occurs between (end of) Q1 and (end of) Q3 will neither be read in by the current read instruction, nor will it generate a new interrupt.

As I see it, the only way to solve this is by writing to the compare register, what we really have fetched from the port for decoding in our software.
And according to the port schematics there really IS a way of doing this!  =)
I have not tried this, but believe this do work:

Hardware:
Put resistors in series with the inputs that we are going to monitor using Port B interrupt, so that we temporarily may set them to outputs.

Software:
We use the port B as usual, and in the interrupt we read port B as usual, but then, we set the pins to outputs, and write the port.
Now we do a read with the pins still set as outputs, and thus guaranteed exactly the same data that we read are latched into compare register!
Then we clear the RBIF flag, and set pins as inputs.

Now we may process the read in state of Port B, while the hardware watch out for guaranteed any change.

Even if the data has changed during the writeback the RBIF get set as soon as we make the pins inputs, and we may check for this before or after our processing of input data depending on if we need to detect every change in sequence, or only import the last state.

Untested, but I think it should work.  Can someone spot a problem?


...Um, now after lunch I remember having discussed something like this here a couple years ago.  Not yet tested though.



Looking at the doc of PIC14000, 40122b.pdf, i used then, there is another schematic  solution for i´ts interrupt on change for port C, and i sense that solution is not waterproof.  The same solutionis in 'C84 doc 30445b.pdf, and also in the F84 datasheet i fetched last minute.

So the new design in i.e Mid ref man, and the new 'F877 chip datasheet is probably the improvement they have done.



BTW, can somebody tell if there is a place I can get more details than are in the mid range ref man, of PIC internal timing, especially what happens during Q1, Q2, Q3, Q4 in CPU and pheripherals?

Regards
/Morgan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservspamTakeThisOuTmitvma.mit.edu?bodyT%20PICList%20DIGEST




2000\11\11@104626 by Andrew Warren

face
flavicon
face
Dwayne Reid <PICLISTEraseMEspam.....MITVMA.MIT.EDU> wrote:

> > Some PICs don't miss portb-change interrupts even if the
> > pin-state changes during an explicit read; if you're using one
> > of those chips, you'll never see the problem.
>
> I assume by the above statement that there certain versions of PIC
> that don't have the problem?  Do you recall which part numbers
> those might be?

Dwayne:

The interrupt-on-change warning in the 16C71x datasheet (which covers
16C71, 16C710, 16C711, and 16C715) specifically references the 16C71.
From that, I infer that the 16C710, 16C711, and 16C715 DON'T have
the problem.  One could extrapolate and assume that all PICs designed
since the 16C710 also don't have the problem, but I don't know for
sure.

-Andy


=== Andrew Warren - EraseMEfastfwdspamix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

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




2000\11\11@144926 by Dwayne Reid

flavicon
face
At 07:47 AM 11/11/00 -0800, Andrew Warren wrote:

>The interrupt-on-change warning in the 16C71x datasheet (which covers
>16C71, 16C710, 16C711, and 16C715) specifically references the 16C71.
>  From that, I infer that the 16C710, 16C711, and 16C715 DON'T have
>the problem.  One could extrapolate and assume that all PICs designed
>since the 16C710 also don't have the problem, but I don't know for
>sure.

Many thanks, Andy.  I've just gotten boards back, ready to stuff, where I
am using a 12c671 to emulate an obsolete counter / LCD driver chip being
clocked at 25 KHz, where the clock, latch, reset lines are quite narrow
pulses.  I'm using INTF for the clock input (don't need to save context)
and RBIF for latch and reset lines.  I'm driving the shift register chain
that actually drives the LCD glass with explicit writes to the port (no
R-M-F instructions).  I guess I'll find out soon enough whether it works or
not.  Latch strobes occur at about 150 Hz rate - any missed interrupts
should show up pretty quick.

Thanks again!

dwayne



Dwayne Reid   <RemoveMEdwaynerspam_OUTspamKILLspamplanet.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 RemoveMElistservTakeThisOuTspamspammitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\12@054121 by Morgan Olsson

picon face
Andy, you are completely right :)

Also clrf and movwf to PORTB make the compare latch update :/

I simply tested using an working project that use Interrupt on change on PortB, deleted the read from port and instead tried movwf PORTB and clrf PORTB, and that too cleared the mismatch after changin input signal level to PORTB, and execution could leave interrupt.  (even though it never *read* PORTB of course)

So I have to move my debug port to another port.

I still can´t figure why the debug outputting on PORTB so far have not disturbed the functionality, but i reckon have just been lucky.

Dwayne, i don´t know about the details on your project, but maybe you can arrange so you do not need to respond to a change in PORTB during your output on Port B session.  When your output sesson is done, load the Port B compare register with last known state thus:

Have resistors in series with PORTB inputs

Disable interrupt (not needed if you are already there)

Make all PORTB pins outputs

Write last known state to PORTB (last state processed by you program, which your program shall sample upon interrupt on change, appears on pins during Q4)

Write last known state to PORTB *again* (this time, in Q3 the data in the previous output, now on the pins, are latched into compare register.)

Make relevant PORTB pins inputs

Clear interrupt flag

Now, if state on pins have changed since last interrupt on change, the hardware will set that flag again immediately.

Enable interrupt (not needed if you are already there; instead act upon flag)


I have to do something similar in order to free pins for moving my debug port.  One nice thing is that we using the above scheme can do anything to port B, then reload compare register with last known state.  Of course, any singal that change, and then change back again during the process will not be catched, but i know i do not have such fast signals.  Thenice thing is we will NEVER miss a signal of longer duration, and it also get rid of the known problem of the hardware missing any change occurring between Q1 and Q3.

Good luck Dwayne, and thanks Andy for pointing out that movwf and clrf do "read-discard" on port B.  And probably other regs.

Regards
/Morgan

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamspamspamBeGonemitvma.mit.edu




2000\11\12@091059 by Morgan Olsson

picon face
I wrote, according the new design in newer PICs:

>Any port change that occurs between (end of) Q1 and (end of) Q3 will neither be read in by the current read instruction, nor will it generate a new interrupt.

Duh, my hands were typing without brain engaged...

Well, we are already in interrupt service, and the compare register updates the new state during Q3, so we can´t clear RBIF until we make new access to the port.  I.e if we try retfie we wil get to the interrupt routine again and then read th eport again, so it solves by iself.

/Morgan

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu




2000\11\12@203536 by Andrew Warren

face
flavicon
face
Morgan Olsson <PICLISTSTOPspamspamspam_OUTMITVMA.MIT.EDU> wrote:

> thanks Andy for pointing out that movwf and clrf do "read-discard"
> on port B.  And probably other regs.

   You're welcome, Morgan... And, yes, those instructions behave
   the same way when applied to other registers, too.

   -Andy


=== Andrew Warren - spamBeGonefastfwdSTOPspamspamEraseMEix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu




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