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