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.
Is there ever going to be compiler support for the EMI0CN register to expand the realm of PDATA variables in C51? Seems to me, this would be a great time saver on these devices... GRH
Apparently, you can do some pretty clever stuff with the "far" memory type; eg, see this suggestion from Jon Ward for accessing arrays via I2C: http://www.8052.com/forum/read.phtml?id=24473 Maybe there's some mileage in that?
The EMI0CN register is an SFR on the Cygnal devices that allows you to select a 256-byte page of on-chip XDATA to use for PDATA moves (MOVX @R0/@R1). The chips that have this SFR also have 1K of on-chip XDATA (which the 256-bytes of PDATA is mapped into). When you use variables in XDATA, the compiler loads the DPTR and then uses the MOVX A,@DPTR or MOVX @DPTR,A instructions. The address range is 64K bytes. When you use variables in PDATA (which is a 265-byte page of XDATA), the compiler loads the address in R0 or R1 (8-bit register) and uses the MOVX @R0/@R1,A and MOVX A,@R0/@R1 instructions. The address range is 256 bytes. The compiler can already use the on-chip XDATA and the on-chip PDATA of the Cygnal devices. For XDATA, you simply tell the linker that it has 1K of xdata. For PDATA, you must modify the startup code to set the EMI0CN register to indicate the page to use for PDATA variables then you must tell the linker what page that is (so that the linke doesn't overwrite the PDATA area with XDATA variables). If we expanded the PDATA address space beyond 256 bytes, an addition load operation would be required for each memory access. And, that would take MORE code space than simply using XDATA. For example, to expand the PDATA space to 1K, the following instructions would be generated.
MOV EMI0CN, #(BIT9-BIT8) ; 3 Bytes MOV R0, #(BIT7-BIT0) ; 2 Bytes MOVX A, @R0 ; 1 Byte
MOV DPTR, #(BIT15-BIT0) ; 3 Bytes MOVX A, @DPTR ; 1 Byte