Hi, Using at89c51 i want some data to copy from program memory to external Data memory.. without using memcopy()... any idea ?
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
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. That statement is not self-evident, its incorrect. On the contrary, the only way "inc P2" can safely be used IS with a shadow register technique. Thus, its not a discussion "based" on shadowing P2, rather I'm pointing out that shadowing P2 should be considered whenever P2 is manipulated. That's all I have to say on the matter for now.