Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Andy Neil
04/10/06 09:48
Read: 670 times

#113978 - Clarity prevails!
Responding to: Markus Kammersberger's previous message
Markus Kammersberger said:
i wondered about the movx instruction in combination with the addressing mode using R0 and R1. I want to store the value of the accumulator into external RAM. I know this works with "MOVX @DPTR,A", but what is the other instruction "MOVX @R0,A" for?

This is what Keil (among others?) call "PDATA"

It effectively gives you access to a single 256-byte "page" of XDATA.
MOVX @Rn is quicker & more compact than MOVX @DPTR because you only use a single address byte.

In the instructionset i found this declaration:

>If operand1 is @R0 or @R1, the Accumulator is moved
>to the 8-bit External Memory address indicated by
>the specified Register. This instruction uses only P0
>(port 0) to output the 8-bit address and data.
>P2 (port 2) is not affected. If operand2 is @R0
>or @R1 then the byte is moved from External Memory
>into the Accumulator.

What happens with the high byte of the address?

This is answered by the part that I've highlighted for you.
Is it set to 0?

No - see above
Is it set to the same value as the high byte of DPTR?

No - see above
Does it mean, that i only can address the first 256 byte of extenal RAM?

Not quite: it means that you can access a single 256-byte "page" of XDATA - where in XDATA that page might appear is up to you.

What happens if i have several peripherals mapped to the external RAM area (e.g. RAM, LCD, Flash, ...)?

Same as for any other application that mixes memory-mapped peripherals and external RAM!

Do i have to use a kind of bankswitching by setting the high byte of DPTR first?

Not quite: You need to ensure that the high address byte is appropriate; eg, by setting P2.

is the area addressed by using this operation an special area of 256 byte not really located in external RAM that only can be accessed via this algorithm?

No - it is just another way of acessing exactly the same physical address space, but quicker & more compact.

How is IRAM addressed and where is it located?

This is a completely different question, and depends on exactly what you mean by "IRAM".
If you mean the 8052 core's internal RAM, it is accessed using the MOV instructions.

List of 28 messages in thread
unclarity with movx instruction      Markus Kammersberger      04/10/06 09:32      
   Speed up      Kai Klaas      04/10/06 09:39      
      Mistake      Kai Klaas      04/10/06 09:48      
   Clarity prevails!      Andy Neil      04/10/06 09:48      
      Quicker?      Kai Klaas      04/10/06 09:54      
         Quicker!      Andy Neil      04/10/06 10:11      
            assumption...      Andy Neil      04/10/06 10:19      
            Finally, you are right!      Kai Klaas      04/10/06 10:21      
   MOVX @Ri      Jan Waclawek      04/10/06 09:52      
      since you did not have the time to find      Erik Malund      04/10/06 10:01      
      wrong answer      Erik Malund      04/10/06 10:03      
         Typo      Abhishek Singh      04/10/06 11:03      
         thanks Erik for the correction      Jan Waclawek      04/10/06 14:14      
   It is set to P0      Neil Kurzman      04/10/06 10:01      
      wrong again      Erik Malund      04/10/06 10:04      
         Yes I am      Neil Kurzman      04/10/06 11:55      
   an example      Jan Waclawek      04/10/06 14:21      
      Internal XRAM      David Smith      04/11/06 14:29      
         not really      Erik Malund      04/11/06 14:38      
            Ports' SFR are set to 1      Kai Klaas      04/11/06 19:54      
               not a port, a "page SFR"      Erik Malund      04/12/06 05:59      
         P2?      Kai Klaas      04/11/06 19:49      
            Doh!      David Smith      04/12/06 03:06      
   which derivative      Oleg Sergeev      04/11/06 00:06      
      do not allow?      Jan Waclawek      04/11/06 01:30      
         AT89S8252      Oleg Sergeev      04/11/06 23:58      
            Aaaaah, so. Thanks.      Jan Waclawek      04/12/06 00:49      
   Tanks      Markus Kammersberger      04/11/06 01:43      

Back to Subject List