• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 21 subscribers
  • Views 1219 views
  • Users 0 members are here
2025 survey

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.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

accessing external data and program memory

Shahsi Banavara


Whenever ,an external data memory is accessed, by using DPTR, the corresponding
DPL and DPH values has to be appear in the Low order address bus (PO) and high order address Bus(P2).

As per the following programme

  #include<reg51.h>
   2          
   3          unsigned char xdata temp _at_ 0x8000;
   4          void main( void)
   5          {
   6   1      while(1)
   7   1              {
   8   2      
   9   2              P0=0X88;
  10   2              P2=0X88;
  11   2       temp=0xf0;
  12   2       P3=temp;
  13   2              }
  14   1      }



I have loaded 0X8000 to DPTR.

Before accessing the external memory at 8000, Simply I am sending at P0 and P2 with 0x88.

When the instruction P3= temp, executes 0xF0 is appearing on the p3.

HOWEVER THE P0 AND P2 VALUES ARE STILL REMAINING SAME , WITHOUT CHANGING TO THE ADDRESSED VALUE
(0x8000).THIS IS WHAT HAPPENS WHILE USING THE DEBUGGER .
Please let me know , why this is so and ,let me know if my understanding is correct.
How about the above subject when accessing the external programme memory

  • 0

    The P0 and P2 are just registers, they are not equal to ports. During the mcu read cycle, the ports are drived by the internal address bus or the data(P0 port) bus, they are not connected to the P0 and P2 registers.
    Pls download a 8051 datasheet, you will get the answer.

  • 0 in reply to Bob Mum

    You may be surprised to note that the Keil Simulator does not simulate the RAM signalling process. For example, ALE does not toggle, /RD and /WR don't wiggle either.

    Why is that, you may ask?

    Well, uVision2 doesn't simulate to that level of granularity because it doesn't need to. If that were a part of uVision2, then YOU would have to define what you want to happen when ALE wiggles. And that defeats the idea of having a simulator that runs fast and that is fast to start using.

    Actually, if you need to see /RD, /WR, ALE, and other signals wiggle, then you are really looking for a full-up SPICE simulation of your hardware. If that's what you need, take a look at the following URL.

    http://www.keil.com/pr/labcenter_010320.htm

    These guys have integrated their SPICE model with uVision2 to give you the best of both simulation worlds.

    Jon