Hi, Using at89c51 i want some data to copy from program memory to external Data memory.. without using memcopy()... any idea ?
For a single byte:
code unsigned char code_var _at_ 0x1234; xdata unsigned char xdata_var _at_ 0x4321; xdata_var = code_var;
Hint: If you make the two variables structs, you can simply do the assignment, and the compiler will implement the copy in an effiecient manner! You will find that C51 uses memcpy() to implement the assignment leaving you no better off. I can think of few reasons to aviod using memcpy() other than avoiding the significant memory space that memcpy() takes up. However, almost all non-trivial programs will have memcpy() in them already.
"You will find that C51 uses memcpy() to implement the assignment leaving you no better off." I have seen cases where it didn't - but that was back with v6.?? Maybe it's different now? It was also only a small structure. "the significant memory space that memcpy() takes up." How big is it? (all the mapfiles I have to hand must be trivial - can't see a memcpy anywhere...)
Sethu, Assuming you're coding in C51, the memcpy function is pretty efficient. Consider using that. If you're coding in A51, well...you're already aware of the movc instruction; the rest of the loop you can probably figure out. If you decide to use movx @r0 for the destination, however, beware crossing page boundaries as "inc P2" won't necessarily produce what you expect.
"inc P2" won't necessarily produce what you expect. can you elaborate on that Erik
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.