How to use movc in keil?

can you elaborate on that

INC P2 is a read/modify/write instruction. Just because you last wrote a 0x2F (for example) to P2, doesn't mean that's necessarily what its going to read on the next read cycle of the read/modify/write of "INC P2".

NEVER assume Ports will return what you last wrote to them without know precisely how the attached hardware will affect the data read back. In the case of P2 being used as an external high address bus, unless you have some fairly strong pullups (which isn't always the case), you'll likely read some combination of the last P2 write value and the last addr-hi value place on the port...randomness depending on bus capacitance of the design.

can you elaborate on that

INC P2 is a read/modify/write instruction. Just because you last wrote a 0x2F (for example) to P2, doesn't mean that's necessarily what its going to read on the next read cycle of the read/modify/write of "INC P2".

NEVER assume Ports will return what you last wrote to them without know precisely how the attached hardware will affect the data read back. In the case of P2 being used as an external high address bus, unless you have some fairly strong pullups (which isn't always the case), you'll likely read some combination of the last P2 write value and the last addr-hi value place on the port...randomness depending on bus capacitance of the design.

Maybe that was confusing. Another way to put it:

Reading port 2 does not read the output latches, rather, it reads the values felt on the pins. Thus, a logic 1 on an output latch may be temporarily forced low at the pin by external pin capacitance...namely an address bus.

Did that make sense?

Did that make sense?

NO! quoting "the bible"

Some instructions that read a port read the latch and others read the pin. Which ones do which? The instructions that read the latch rather than the pin are the ones that read a value, possibly change it, and then rewrite it to the latch. These are called "read-modify-write" instructions.

Erik

...and INC P2 is one of those instructions.

OK. Now I know where I'm getting confused. You're right about the read/mod/write.

The P2 problem I'm thinking of arises not when you increment, rather when you push P2...which is the case when you may have interrupt routines that want to use P2-R0/R1 for xdata and you wish to preserve.

In this case, PUSH P2 doesn't cut it. You have to keep an image of P2 and push that instead. This, then, means that all forground use of P2 must keep the P2 image in sync.

(I hope I'm remembering this correctly. I don't have the problem in front of me but I recall it biting me in the ass years ago)

OK. Now I know where I'm getting confused. You're right about the read/mod/write.

The P2 problem I'm thinking of arises not when you increment, rather when you push P2.

where is the confusion?
PUSH is a READ, not a read-modify-write.

Have a look in "the bible"

Erik

where is the confusion?
PUSH is a READ, not a read-modify-write.

And what does it read? The register or the pins?

Since you evidently do not have the link to "the bible" here it is

here are the links to "the bible"
Chapter 1
http://www.semiconductors.philips.com/acrobat/various/80C51_FAM_ARCH_1.pdf

chapter 2
http://www.semiconductors.philips.com/acrobat/various/80C51_FAM_PROG_GUIDE_1.pdf


chapter 3
http://www.semiconductors.philips.com/acrobat/various/80C51_FAM_HARDWARE_1.pdf


Erik

I have "the bible" and have for over 15 years.

Answer my last question. What does PUSH read when you "PUSH P2".

I'll save a post and lead to the next question, (assuming you answer):

Q: How does one save the contents of P2?

This is a common problem when the forground process uses P2 for movx a, @rn instructions, yet an interrupt routine expects to use P2 for other means (pdata access, for example). How does the interrupt routine save P2 (so it can later restore it of course)? As stated earlier, PUSH P2 is unreliable because, according to "the bible", it does not read the register.

Answer my last question. What does PUSH read when you "PUSH P2".
Question
is there a modify involved?

Q: How does one save the contents of P2?
with a shadow register

Erik

with a shadow register

Precisely!!! And this is why "INC P2" by itself doesn't work in the aforementioned model (where P2 is to be maintained across interrupts) ...as it MUST increment the shadow register before it increments P2.

"As stated earlier, PUSH P2 is unreliable because, according to "the bible", it does not read the register."

I wonder if you can provide a page number to back that statement up?

I wonder if you can provide a page number to back that statement up?

Intel-MCS51 Family-user manual.pdf
Order No.:272383-002
February 1994
Page 3-9

Do I need to copy the entire page?

"Do I need to copy the entire page?"

No, not at all. You just need to explain how it is relevant to the PUSH instruction.

No, not at all. You just need to explain how it is relevant to the PUSH instruction.

Its relavent because "PUSH P2" doesn't necessarily push the value that's presently in the P2 output latch.

Should I put up a short code example?

Precisely!!! And this is why "INC P2" by itself doesn't work in the aforementioned model (where P2 is to be maintained across interrupts) ...as it MUST increment the shadow register before it increments P2.
This could have been umpteen posts shorter if you had introduced that you were discussing based on a shadow register earlier.
There is, in most designs no shadow registers, only the few cases where interrupts handle ports pins that are also used in main are they used. You discussed this on the basis of P2 without even bringing in that a shadow register was used.

Your initial statemnent "beware crossing page boundaries as "inc P2" won't necessarily produce what you expect" should have read "inc P2" can not be used when a shadow register is in use" and that statement is self-evident.

Erik