MOV PORT, A not working appropriately.

Do we have to guess that you have some random generic 8051 chip?

No interest at all to tell us?

No interest at all to tell if the processor supports configuration of in/out for a port or just output with a weak pull-up?

No reason to tell us if there is something magic that makes your processor require two MOV P2,A after each other?

No reason to tell us how confusing you think it is for the processor to look at a bit on a port to decide if it should rotate left or right and then write back the result of the rotation to the bit that decides what rotation direction to use? Your sw comments doesn't exactly tell what _you_ think should happen when the code is run...

This is my Keil info:

IDE-Version:
µVision V4.72.9.0
Copyright (C) 2013 ARM Ltd and ARM Germany GmbH. All rights reserved.

License Information:
eduardo reis
home
LIC=----

Tool Version Numbers:
Toolchain: PK51 Prof. Develpers Kit Version: 9.52.0.0
Toolchain Path: C:\Keil\C51\BIN
C Compiler: C51.Exe V9.52.0.0
Assembler: A51.Exe V8.02b
Linker/Locator: BL51.Exe V6.22
Librarian: LIB51.Exe V4.29
Hex Converter: OH51.Exe V2.7.0.0
CPU DLL: S8051.DLL V3.91.0.0
Dialog DLL: DP51.DLL V2.62.0.1

The target is:
AT89C52

And my ASM file is just that one.

I just had this exercise: read from one port, rotate according to a pin from another port.

What is weird is that in another project/ exercice. This one:

ORG 0000
JMP 0100
ORG 0100

LOOP3: MOV R0,#7
LOOP1: CLR C
MOV A,P1
RRC A
MOV P1,A ;It works here
DJNZ R0,LOOP1

MOV R0,#7
LOOP2: CLR C
MOV A,P1
RLC A
MOV P1,A ;but not here
DJNZ R0,LOOP2

END

How to configure the pins as outputs?

Thanks, I'm gonna organize my code from now on.

Is there a way to edit a post. I couldn't find it.

A classic 8051 have no input/output configuration. The pins are always outputs but the pins have strong drive low, while only weak pull-up to hold them high.

So when using them as inputs you write a one to the bit position. Then external electronics can override the pull-up and force the pin low. So while a write of 0cFF makes all pins usable as inputs, the reading of the port will indicate the actual pin state after external electronics have had a chance to override.

But that also mean that when you write a zero to the port pin, it gets locked as low and will read back as low.

Do you now see an issue with having a loop that multiple times reads and writes the port and tries to shift the result?

Hi there,

I have no pull-up resistor because I'm just debugging it on the keil environment. I don't have the actual components to run it. I'd like to make sure that it is not a programming error before think that it is a bug on the keil debugger.

My project is not a big deal, it is just homework. So, It is not about the loop, and it is not the specific value in the Accumulator. I'm just wondering why In one loop it set the pin values successfully. And in the next one it doesn't happen.

Is this pull-up resistor "configuration" important if I'm only running the code on the Keil debugger?

"Do you now see an issue with having a loop that multiple times reads and writes the port and tries to shift the result?"

Not exactly. This is my code/issue:

                ORG             0000h
                JMP             0100h
                ORG             0100h


        MOV     R0,#7

LOOP1:  CLR     C
                MOV             A,P1
                RRC             A
                MOV             P1,A ;This one works perfectly
                DJNZ    R0,LOOP1

                MOV     R0,#7

LOOP2:  CLR     C
                MOV             A,P1
                RLC             A
                MOV             P1,A ;But, for some reason, this one just send the 
;value to the latch
                DJNZ    R0,LOOP2

                END