Searching \ for '[PIC]: Trouble with port output on 16F877' 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=output
Search entire site for: 'Trouble with port output on 16F877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Trouble with port output on 16F877'
2002\01\13@184749 by Rick Mann

flavicon
face
Am I just dense? I've read the Microchip docs, a fat book by Myke Predko,
and I've looked through the FAQ. But I have what appear to be bizarre
problems trying to write to the various port latches on the '877.

I've been working on interfacing a parallel LCD to a PIC 16F877. I
succeeded, but only after noticing a (possible) problem with port A. If I
execute the following instructions (all of port A is configured as output):

       bsf     porta,0
       bcf     porta,1
hold    goto    hold

then both RA0 and RA1 will be cleared (RA0 will be set momentarily). This
was causing the assertion of RS on the LCD to fail (or at least not last
long enough), because I was asserting RS via a port a pin, then pulsing E
via a different port a pin. I solved the problem by using port B pins
instead, and the same exact code (with the exception of the different port)
started to work.

At first I had RS connected to RA4, an open-drain output, so I moved both RS
and E to RA0 and RA1, but I kept having the same bsf/bcf problem.

Is there something simple I've overlooked? I also tried two different '877
chips, in case one was damaged, but they both fail the same way.

I also tried the following. I've put all the code so you can see exactly
what I've done. I have a bunch of LEDs wired to the pins of port C, through
a 100-ohm resistor to Vcc (each), so that the LEDs would light if a pin goes
low.

       list    p=16f877

       include    "p16f877.inc"

       org        0x000
       nop

start
       bsf      status,rp0
       movlw    b'00000000'
       movwf    trisc

       bcf      status,rp0
why     movlw    0xFF           ;   Can change this to 0x00
       movwf    portc

prob
       movlw   0x00
       movwf   portc

circle  goto    circle

       end

Up to the label "prob", the LEDs remain unlit. I would expect them to light
after "prob" executes. They don't. However, if I change the 0xFF at "why" to
0x00, then the LEDs are lit (and I can then change the 0x00 at "prob" to
0xFF, and they'll remain lit).

Thanks for any help,

Rick

--
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


2002\01\13@191450 by uter van ooijen & floortje hanneman

picon face
>         bsf     porta,0
>         bcf     porta,1

Did you find something about 'read-modify-write' problems or about 'updating
a port in subsequent instructions'? Solved by either
- instering a 'nop' between the two instructions
- modifying a 'shadow register' and copying that shadow to the real porta

Wouter van Ooijen

Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler for PIC uC's:  http://www.voti.nl/jal
PICs kopen? http://www.voti.nl/shop

--
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


2002\01\13@192859 by Byron A Jeff

face picon face
On Sun, Jan 13, 2002 at 03:30:08PM -0800, Rick Mann wrote:
> Am I just dense?

Nope. Not dense at all.

I've read the Microchip docs, a fat book by Myke Predko,
{Quote hidden}

This is a side effect of doing a read/modify/write operation on a port in
successive cycles. It's a confluence of a lot of issues:

- bsf/bcf operations read/write the entire port, not just the bit in question.
- read operations on a port always reads the actual pin state, not the output
 latch. This occurs even when the bit is configured for output.
- reads occur in the first quarter of the instruction cycle while writes
 occur in the last quarter of the instruction cycle.

So here's what happens:

- The bsf sets the output latch of bit 0 in the last quarter cycle of the
 instruction. The output driver starts to drive the pin high.
- Then in the first quarter cycle of the bcf, the PIC reads the entire port.
 But because the output drive hasn't had sufficient time to drive the pin
 high. So when the PIC reads the pins (not the output latches), it sees
 bit 0 still as low.
- In the write cycle in the last quarter cycle, the PIC writes the entire
 port. But since it read a 0 for bit 0, it writes a 0 for bit 0, therefore
 wiping out the effect of the bsf.

>
> At first I had RS connected to RA4, an open-drain output, so I moved both RS
> and E to RA0 and RA1, but I kept having the same bsf/bcf problem.

Actually it probably have worked a bit more consistently on RA4 with a pullup.

But the solutions are simple and well known:

1) Simply give the output driver time to drive the pin. Usually this is done
  by putting a NOP between successive RMW instructions to the same port. I
  do this with fastedious (sp) devotion.

2) Use shadow registers where maintains the state of the port. So in this
case you'd set the state of the shadow register, then transfer the register
to the port. It gets rid of the RMW on the port, thereby alleviating the
problem.

>
> Is there something simple I've overlooked? I also tried two different '877
> chips, in case one was damaged, but they both fail the same way.

This is completely consistent across the PIC line. It'll happen in every
part.

{Quote hidden}

Not sure about this one. The code looks right. There's no RMW issues/

Anyone?

BAJ
>
> Thanks for any help,
>
> Rick
>
> --
> 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
>

--
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


2002\01\13@195249 by Rick Mann

flavicon
face
Thanks, Byron, for the quick response. Now I understand. And I like the
shadow register solution.

on 1/13/02 4:26 PM, Byron A Jeff at spam_OUTbyronTakeThisOuTspamCC.GATECH.EDU wrote:

>> Up to the label "prob", the LEDs remain unlit. I would expect them to light
>> after "prob" executes. They don't. However, if I change the 0xFF at "why" to
>> 0x00, then the LEDs are lit (and I can then change the 0x00 at "prob" to
>> 0xFF, and they'll remain lit).
>
> Not sure about this one. The code looks right. There's no RMW issues/
>
> Anyone?

Actually, I solved the other problem. I was being stupid; it was working
correctly. In some other code I was loading the FSR with:

   movfw   gMyBuffer
   movwf   FSR

rather than the correct:

   movlw   gMyBuffer
   movwf   FSR

This was the root of a lot of "weird" behavior, coupled with the fact the my
LEDs were wired to turn on with 0's written to the port, confused me to no
end. When I wrote that those instructions (in my original post) were not
working, they were in fact working, just opposite to what I was expecting.

Thanks again for all the help!

--Rick

--
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


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