We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am going to use the Philips P89C668 which has 64k flash and 8k ERAM. This allow me to use P0 and P2 for I/O since no external memory chip will be connected. However, if the compiler generates code using a MOV P2,# followed by a MOVX @R0 this scheme will be screwed up. Is there a way to "tell" the compiler to keep its little fingers off P2 for MOVX. Erik
I think you have to change the momory modell from COMPACT into LARGE and/or you declared variables as pdata. When use this C51 generates MOVX @Rn code to access xdata. Chris
I'm using the default model (SMALL) Will it happen there ? Erik
However, if the compiler generates code using a MOV P2,# followed by a MOVX @R0 this scheme will be screwed up. Is there a way to "tell" the compiler to keep its little fingers off P2 for MOVX. Uhhh. The Keil C Compiler NEVER changes the value of P2. An effect of the MOVX @R0/R1 instruction is that it obtains the upper address byte from the P2 SFR. Since the chip you are using has more than 256 bytes of on-chip XDATA (ERAM is what I think Philips calls this) you need to determine if they did anything special to get the upper address byte for MOVX @R0/R1 instructions. I think that they "assume" it is 0 and do not use P2 for that. If you don't want the compiler to use the MOVX @R0/R1 instructions, don't use the PDATA memory type or COMPACT memory model. Jon
Jon, If I understand you correctly, then if I do not use PDATA and use the SMALL memory model, the compiler will NEVER do a MOVX @Ri. Pls confirm Thanks Erik
That's right. "PDATA" could be defined as "memory accessed via MOVX @Ri" We had similar issues with PDATA on the Triscend E5.
That's exactly right. Jon
I thing, the answer is to late but if you use SMALL then you will not have this problem. Chris