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'm using the Philips 89c51RD which has 1KB RAM. I also have some devices mapped from 0x0000 to 0xFEFF, I'm acessing these devices using "XBYTE[DEVICE_ADDR]=DEVICE_DATA" (where DEVICE_DATA is the address of the memory mapped i/o and DEVICE_DATA is the data byte wrote to the specific device). The questions are: 1) Is there some way of using the entire 1KB extended RAM and not drive the A15 to A8 pins low(I'm using these pins for address decoding)when accessing the extended ram? 2) Otherwise, is it possible to configure the address range of the internal (extended)memory (xram) to start at 0xFF00 (with only 256 length in this case) so I can guarantee that the external pins A15 to A8 never goes low when accessing ram memory? How can do that, just setting startup.a51? Thanks, Fernanda.
Well, I skimmed the data sheet for your device. It doesn't seem like Philips gave you many options for mapping that internal RAM. It seems as though it always shows up at the bottom of the extended memory space. Access seems always to be via the usual 8051 P2/P0 multiplexed address/data bus. The easiest way out might be for you to redesign your address decoding logic to map your devices above the RAM instead. Note that 256 bytes of that RAM is the internal 8051 RAM (data and idata), so there's really 768 bytes of "xdata" on the chip. I'm not sure that the chip isn't going to occupy all three pages of xdata space. If you really only have 256 bytes of xdata address space free, that could be a problem. You might study the data sheet and check the app notes to see if there's something I missed on my glance through the Philips docs.
So what you are telling me that any access to the internal extended ram will drive the external address bus and will not be possible to map the internal memory to start from FF00h?
Hi, Any access to the internal extended ram will NOT drive the external address bus, the Philips chip has a bit called EXTRAM in the AUXR sfr register which allows you to either access the internal 1k (EXTRAM = 0) and will not affect the PORTS, or external ram (EXTRAM = 1) which will affect the PORTS. It will not be possible to map the internal memory to start from FF00h but as far as I can see the only problem you have to worry about is ensuring that you have selected the correct 'xram address space' when addressing the 1st 1k of internal/external ram. Hope this helps, Mark.
Yes, but can the device not drive the ports based on the address? The EXTRAM bit looked like all-or-nothing to me. I suppose you could write a slightly more complex routine for device access:
; U8 ReadHw (volatile U8 xdata* addr) PUBLIC _ReadHw _ReadHw: ; mask interrupts PUSH IE SETB EA ; enable external bus PUSH AUX SETB EXTRAM ; read external HW byte MOV DPL, R7 MOV DPH, R6 MOVX A, @DPTR MOV R7, A ; restore original state POP AUX POP IE RET
Drew, The device will ALWAYS drive the ports regardless of the state of EXTRAM for addresses above 0x0400, but below this:- with EXTRAM = 0 it will access internal ram, ports NOT driven. or;- with EXTRAM = 1 it will access external ram, ports ARE driven. Thus if there are any I/O devices below this threshold address (0x0400) then your code could become somthing like:-
U8 ReadHw(volatile U8 xdata *addr) { if (&addr < 0x400) { /* save EA */ /* clear EA */ /* save AUXR */ /* set EXTRAM = 1 */ /* read device */ /* restore AUXR and EA (in that order) */ /* return i/o read data */ } return *addr; /return i/o read data */ }
Thanks for the clarification.
Many thanks for your help, Fernanda.