Richard, I think we're not on the same frequency or something.
> The power-on default is with the INTERNAL 1kB block of XRAM disabled, and > with the external memory timing in the default (4-clocks) mode as well. So if you use it stand-alone, without external RAM or ROM, you will have no access to the internal XRAM. This also means that SDCC cannot perform xdata initialization. If you connect external RAM and intend to use that instead it can, as long as timing is ok. > This MCU is, after all, a one-clocker, though it uses four cycles to effect > external memory interfacing. It would be really useful to know just how > SDCC will treat accesses to the internal XRAM if it is mapped into code > space. Preliminary experiments suggest that the on-chip XRAM actually > allows the MCU to execute code faster than it can do so from FLASH, so it is > of significant interest. If the internal RAM is mapped into code space but not into xdata SDCC can read it with MOVC or execute code from it. If the ISP routines can fill it, then SDCC can use it (until power has gone off). If you use --xram- movc SDCC will use MOVC instructions to read from it instead of MOVX. If the internal RAM is mapped into both xdata and code space you can create self-mofiying code, but SDCC does not bring any help. It would also be possible to use less instructions to access an array or struct because MOVC can do the A+DPTR calculation which MOVX cannot. Again this is not something SDCC can do right now. > Those "page" modes have no effect on the execution of the code, though they > do have effect on external memory timing. They make it possible to execute > code from external memory faster than from internal FLASH, though I haven't > rigorously proven this ... yet. Preliminary experimentation, however, > suggests that the originally specified maximal clock rate of 50 MHz is > attainable with external memory or from internal XRAM mapped into code > space. Note that there is significant (1 extra clock cycle) impact each > time a "page" boundary is crossed when using external memory, as the high > address bus has to be latched, and that takes an additional cycle. Finally it would also be possible to copy code from ROM into RAM for faster execution. This is best handled by a combination of SDCC and an external tool like srecord. Link the code as it should run. I suggest the use of -- codeseg or its pragma to put the code in a named segment and tell the linker to locate that segment at the RAM location in code space. After the linkage use srecord to move the named segment to a different address in real (and unused) code memory in the hex-file. Before any code in this segment is executed it must be moved into place by some startup routine, _sdcc_external_startup() comes to mind, but another .asm is fine too. Just make sure to enable the internal RAM in code space and maybe disable it in xdata before using it. If you also need to adjust the clock that is best done once running from RAM since you state the ROM will be too slow. > There's no danger of having this MCU mess up the way in which SDCC does the > initialization to which you refer. If the firmware doesn't change the > SFR's, all the same defaults apply to it as apply to a "standard" 8052. But the standard 8052 doesn't have internal xram. > I'm not aware of any impact of operations on P2 on addressing of the > internal XRAM. It can have effect on external hardware, though. In > "page mode 1", both the high and low address bytes propagate through > P2, and only the data is on P0. This should have no effect on the > behavior of the compiler, however, as the addresses remain what they > are. Not if you use MOV P2,#0x01 followed by MOVX A,@R0. If the internal 1k RAM is mapped at 0x0000 this can only access between 0x0000 and 0x00FF, not 0x01yy. And the question still is, will it latch the P2 register value as the high address byte before outputting the value in R0 as the low address byte? > Just their paths are changed. If you're curious about the page modes > and their effects, you might want to see Maxim's App Note 26. > > http://www.maxim-ic.com/appnotes.cfm/an_pk/26 I admit I have not looked into it. > I am curious what the compiler does with code that is moved about in code > space, as the way in which one would use the on-chip XRAM block would be to > load it from FLASH after changing the memory map. Does it allow copying > from one area of code space to another? No it does not unless the fragment was meant to live there. > BTW, MOVX A, @Ri works the same on this MCU as on the others. I've dropped > DS89C4x0's into a number of existing applications and found no problems so > far with instruction execution, though the timing is very different. Then I can only guess that P2 will be latched before this instruction or that you haven't seen everything yet. > regards, > > Richard Erlacher Regards in return, Maarten Brock ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
