Searching \ for '[PIC]: 16F877 PORTE Strange behaviour' 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=port
Search entire site for: '16F877 PORTE Strange behaviour'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16F877 PORTE Strange behaviour'
2002\03\05@191543 by Haris I. Volos

flavicon
Hi!

I have recently posted a message about controlling an HD44780 display
because I couldn't make my code to work, finally I managed to initialise the
lcd and display its cursor.

The problem is when I make the RS(which is connected to RE2) input of the
LCD high so I can enter characters to the LCD instead of commands, in my
surprise I discover that the RE2 pin goes high only for a very small
fraction of time and then goes back low!!! I have a
bsf PORTE,2
as the last command prior an endless loop(label  goto label)  and when I
measure the level in RE2, is low. (I am using RE0 for E and RE1 for RW lcd
inputs and port B<3-0> for data.)

After further investigation I discovered if I either set RE1 or RE0 then
output of the pin(RE1 or RE0) is high and the other pin output is low
regardless of its preview state! An if I set RE2 high afterwards all the
pins are low!
Port B status is always what is should be.

I have checked my circuit no short circuits exists between the pins or
supply rails.

Any ideas?

Thanks in advance,

Haris

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


2002\03\05@192413 by Tony Nixon

flavicon
picon face
"Haris I. Volos" wrote:
>
> Hi!
>
> I have recently posted a message about controlling an HD44780 display
> because I couldn't make my code to work, finally I managed to initialise the
> lcd and display its cursor.
>
> The problem is when I make the RS(which is connected to RE2) input of the
> LCD high so I can enter characters to the LCD instead of commands, in my
> surprise I discover that the RE2 pin goes high only for a very small
> fraction of time and then goes back low!!! I have a
> bsf PORTE,2

Check that the analog convertor is not enabled for PORTE.

BSF will read PORTE, and if analog, will always read logic 0, and thus
set pins to 0 other than the BSF pin.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
spam_OUTsalesTakeThisOuTspambubblesoftonline.com

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


2002\03\05@194501 by Ashley Roll

flavicon
face
Hi Haris,

Check that you've disabled the analogue inputs on the PORTE pins and also
check that you aren't accidentally turning on the PSP mode when you setup
the TRIS register for the port as the TRISE register also contains the
settings for PSP mode. (That one has gotten me before :)

Cheers,
Ash.

---
Ashley Roll
Digital Nemesis Pty Ltd
http://www.digitalnemesis.com
Mobile: +61 (0)417 705 718




> {Original Message removed}

2002\03\05@194709 by Bob Barr

flavicon
face
On Wed, 6 Mar 2002 02:13:35 +0200, "Haris I. Volos" wrote:

{Quote hidden}

I'd suggest doing your bsf/bcf operations on a 'shadow' register
rather than on the port directly. You then write the shadow register's
contents to the port.

The bsf and bcf instructions (as well as several others) reads in the
whole port, modifies the bit you want to change and writes the whole
port back out. If a bit that you're not modifying reads back the wrong
state, it will be written back out exactly as it was read.

This has caused innumerable problems for many people. There's lots of
info in the archives on read-modify-write problems.


Regards, Bob

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


2002\03\06@035734 by Kevin Blain

flavicon
face
It's a problem that occurs when the analogue bits are switched on.

Bsf is a Read modify write instruction, and as such, it reads in the
whole port value, modifies the bit, then writes it back. When in
analogue mode, the port pins always read zero.

There are four solutions (sort of) to this

1. disable analogue mode (if you can)
2. use a copy register for the port latch
3. try and do it with movlw instead
4. use a pic18f452 (cheaper and has a register for the latch)

Regards, Kevin

> {Original Message removed}

2002\03\06@085303 by Haris I. Volos

flavicon
----- Original Message -----
From: "Bob Barr" <.....bbarrKILLspamspam@spam@CALIFORNIA.COM>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Wednesday, March 06, 2002 2:42 AM
Subject: Re: [PIC]: 16F877 PORTE Strange behaviour

> I'd suggest doing your bsf/bcf operations on a 'shadow' register
> rather than on the port directly. You then write the shadow register's
> contents to the port.
>......

This is the solution! It solved the problem at once!

Thanks everyone for the quick response.

Haris

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\03\06@133847 by Sergio Masci

picon face
> > I'd suggest doing your bsf/bcf operations on a 'shadow' register
> > rather than on the port directly. You then write the shadow register's
> > contents to the port.
> >......
>
> This is the solution! It solved the problem at once!
>
> Thanks everyone for the quick response.
>
> Haris

Actually, xcsim directly supports port consistancy checking. If your program
writes to a real port such as A or B using one of the dreded read modify
write instructions (e.g. bsf, addwf, iorwf etc) it checks that the result is
consistant with what should be in the port. It does this as part of its
multi-processor simulation stratergy. Since it simulates multiple processors
and other I/O devices connected together at the CPUs I/O pins, it is able to
correctly determin the effective state of an I/O line when it is being
driven by several devices. This is this fed back to the simulated I/O port
of the target CPU so that when the program reads the port it gets a true
picture of the rest of the system and not just a copy of some RAM location.
You can get the simulator to trap when a read modify write instruction
generates a side effect, then it is a simple mater to work backwards to find
which CPU caused the I/O line to be driven against expectations.

Regards
Sergio

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


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