PIC16F88, PORTA strange behaviour

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Strange problem:

Setting an output low on PORTA, causes another output
on PORTA to go low too.

Below is the entire program. It should generate two signals:

---,   ,---,   ,---,   ,---,   ,---
   '---'   '---'   '---'   '---'
-,   ,---,   ,---,   ,---,   ,---
 '- -'   '---'   '---'   '---'

But instead gives this:

-,     ,-,     ,-,     ,-,     ,-
 '-----' '-----' '-----' '-----'
-,   ,---,   ,---,   ,---,   ,---
 '- -'   '---'   '---'   '---'

If I generate the second signal on an output of PORTB,
it all works okay.

L0000:  MOVLW  00
L0001:  MOVWF  0A
L0002:  GOTO   004
L0003:  NOP
L0004:  CLRF   04
L0005:  MOVLW  1F
L0006:  ANDWF  03,F
L0007:  BSF    03,5
L0008:  BCF    1F,4
L0009:  BCF    1F,5
L000A:  MOVF   1B,W
L000B:  ANDLW  80
L000C:  IORLW  0F
L000D:  MOVWF  1B
L000E:  MOVLW  07
L000F:  BCF    03,5
L0010:  MOVWF  1F
L0011:  MOVLW  00
L0012:  TRIS   5
L0013:  NOP
L0014:  NOP
L0015:  NOP
L0016:  BSF    05,2
L0017:  NOP
L0018:  NOP
L0019:  NOP
L001A:  BCF    05,3
L001B:  NOP
L001C:  NOP
L001D:  NOP
L001E:  BCF    05,2
L001F:  NOP
L0020:  NOP
L0021:  NOP
L0022:  BSF    05,3
L0023:  GOTO   013
END

Any suggestions?

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)



Re: PIC16F88, PORTA strange behaviour
Quoted text here. Click to load it

And also, when I change everything to use outputs
on PORTB, everything also works as expected. Is there
something seriously wrong with PIC16F88 ?

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)




Re: PIC16F88, PORTA strange behaviour

<Snipped>

Quoted text here. Click to load it
A data point...

As it happens, I've been doing something similar today on a '88 using
PortA 1..4 to generate four phase overlapping square waves.  I've not
had any problems.

Broken PIC?  A short or too much load on one of the port pins?

Nice part, though.

Cheers
--
Keith Wootten


Re: PIC16F88, PORTA strange behaviour

Quoted text here. Click to load it

Are you doing this without delays in the inter-port pin state changes?
That is, fast? If so, you've hit the fun errate of read-modify-write on a
port. Try using a pin on port A and a pin on another port, the problem
should go away. Microchip has a good description of this problem in one of
the PIC documents. I can't find it right now. It may have been in the Q&A
section of the PIC18 reference. Good luck.


--
- Mark ->
--

Re: PIC16F88, PORTA strange behaviour
Quoted text here. Click to load it

No, it's not that. When I pick two outputs on B there is no problem.
With two outputs on A, presto. Also happens with milisecond delay in
between. The code I included was just to demonstrate this behaviour.
I really start thinking it's a flaw in the F88, on the other hand I can
hardly believe that this has to be discovered on my workbench ;)

I'll try a workaround, updating the entire port instead of single
pins.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)








Re: PIC16F88, PORTA strange behaviour
On Thu, 2 Dec 2004 15:23:17 +0100, "Frank Bemelman"

Quoted text here. Click to load it

Whenever you use BCF and BSF instructions to set or clear bits on a
port, the entire port is read and then written.  If you have enough
loading on the output that it reads back as something other than what
you wrote (i.e. past the half-way point between the voltage supply
rails) then the latch for the port will adopt the forced value.  Try
your test with absolutely no loading on the output.


-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply
address is fake.)

Re: PIC16F88, PORTA strange behaviour - issue resolved!
Quoted text here. Click to load it

Damn, do I feel SILLY. It has happened before, and now it bit me
again. I used to have a wrapper for fiddling with single outputs,
using intermediate storage, which I didn't use here, and I do have
a serious load indeed (some leds on port A etc).

Thanks Robert ;)

#^*&^!! It won't happen again, I promise.

Thanks to all the other respondents too.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)





Re: PIC16F88, PORTA strange behaviour
Quoted text here. Click to load it

It's probably to do with your initialization stuff on PORTA.  I've never
used the '88, so I'm not sure what you might be missing.  Your ADCON0
initialization value should be looked into, but it doesn't appear that
would cause your problem.

Quoted text here. Click to load it

Get real.  ;-)  Seriously though, something this badly wrong would be
documented all over the net.

Quoted text here. Click to load it

I doctored your code up a bit, see below.  You should still add more
pseudo-ops for clarification.  A proper __CONFIG directive and comments
would be nice.  ;-)

LIST          P16%f88
RADIX         HEX
 INCLUDE       "p16f88.inc"

  MOVLW  00
 MOVWF  PCLATH  ;  CLRF PCLATH would do the same thing in half the time

 GOTO   004
 NOP
 CLRF   FSR
 MOVLW  1F             ; Select Bank 0
 ANDWF  STATUS,F
 BSF    STATUS,RP0     ; Select Bank 1
 BCF    ADCON1,4       ; Set for AVdd and AVss
 BCF    ADCON1,5
 MOVF   ANSEL,W        ; Get ANSEL value
 ANDLW  80             ;  strip all but first bit (unnecessary)
 IORLW  0F             ;  make A0 - A3 analog pins, (A4, B6 and B7 as
digital)
 MOVWF  ANSEL          ;  and write it back


 MOVLW  07             ; ?


 BCF    STATUS,RP0     ; Select Bank 0


 MOVWF  ADCON0         ;  I don't think you want to do this on a 16F88



 MOVLW  00
 TRIS   5              ;  DONT USE THIS INSTRUCTION (deprecated for eons
;-)


label:
 NOP
 NOP
 NOP
 BSF    PORTA,2
 NOP
 NOP
 NOP
 BCF    PORTA,3
 NOP
 NOP
 NOP
 BCF    PORTA,2
 NOP
 NOP
 NOP
 BSF    PORTA,3
 GOTO   label
 END


Re: PIC16F88, PORTA strange behaviour

Quoted text here. Click to load it

As Robert Scott pointed out, a different load on the pins can make one
port appear to work and another not. I hit this problem when trying to
toggle two different bits on the same port at the CPUs instruction rate
(10MHz on a PIC18F242), even with a very light load (scope probes only) on
the pins I experienced your problem. This high-speed problem is noted by
Microchip as problem to be worked around and as you've found, it can be a
problem at lower update rates depending upon loading.

Glad you have a solution.

--
- Mark ->
--

Re: PIC16F88, PORTA strange behaviour
Quoted text here. Click to load it

Yes, me too. I feel a bit silly, me saying 'No, it's not that', because
this problem has happened to me before. But all is well that ends well ;)

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)




Re: PIC16F88, PORTA strange behaviour
Quoted text here. Click to load it


your program looks like it should work, you should not use the tris instruction
anymore though.I haven't checked the datasheet some pics use porta for ad
conversion check that you have set the pins to digital. Your reading the port
pins very soon after changing them if there is too much load its possible that
theyy havent had time to settle.

Re: PIC16F88, PORTA strange behaviour
On Thursday, in article
Quoted text here. Click to load it
......

When something works on one port but not on another for ANY micro
my suggestions are

        Check the port has been fully initialised for correct mode
          and o/p type.

        Check the connections on the pin if necessary open circuit
        the pin from the rest of the circuit and test again.

Looks suspiciously like something external to me though.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline