Using 256B internal memory on 8051

Hi Friends,

I'm using sdcc 2.8.0 #5117 to build code for a 8051 derivative that has

256 byte internal RAM. I'm using a small model and for some reason I'm unable to use the entire memory. When I look at the memory map I see that the sdcc uses the upper 128B for stack, and does not permit data to reside there. I've tried reducing the stack size and change the location of different memory components; I've also used the pack/nopack options, but I wasn't able to use more than 128B for data.

Does anyone know if that's doable and how?

Thanks, Runin

Reply to
runin225
Loading thread data ...

Haven't danced with an 805x for a while but this may be relevant:

"1.2 Addressing Modes The addressing modes in the 8051 instruction set are as follows:

1.2.1 Direct Addressing In direct addressing the operand is specified by an 8-bit address field in the instruction. Only 128 Lowest bytes of internal Data RAM and SFRs can be directly addressed. 1.2.2 Indirect Addressing In indirect addressing the instruction specifies a register which contains the address of the operand. Both internal and external RAM can be indirectly addressed. The address register for 8-bit addresses can be R0 or R1 of the selected register bank, or the Stack Pointer. The address register for 16-bit addresses can only be the 16-bit ?data pointer? register, DPTR."

IIRC, there is a way to tell sdcc to use that upper 128 byte region. Is the _xdata tag only for "real" external memory?

On the other hand, while the MCS51-family can handle external memory pretty well, if you're limited to just the internal memory area then you might be better off staying with assembly.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

I suppose so, since while internal and external RAM are bundled in 1.2.2 above, they need separate machine instructions (and there is even one more addressing mode, indirect addressing of program memory).

I know diddly squat about sdcc, but the upper half of the internal memory probably requires another classifier (idata or something), and the linker may also need to be instructed on how to split that area between stack and variables. There might also be different memory models for the compiler which will do this more or less transparently.

C is just fine if you don't overdo automatic variables and nested function calls, in which case you will quickly find yourself with a stack overflow. Of course it will be closer and closer to using a glorified macro assembler...

--
http://www.hut.fi/u/iisakkil/		--Foo.
Reply to
Mika Iisakkila

__idata it is indeed (and external is __xdata, vice _xdata, my bad).

It looks like the linker defaults to placing __idata variables at the bottom of the indirect memory area and the stack grows down from the top thereof. The other MCS51 memory models (medium and large) need external RAM so small looks like the way to go, with due care, as you note, to the stack.

True that.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

-- snip --

I've programmed for itty bitty chips in this circumstance, with C, and it works just fine. You have to pay attention to the restricted memory with every line of code you write, but it can be done, and IMHO it's a significant time-saver for all but the most accomplished of assembler coders (particularly when said assemble coder wants to retire, or go on vacation).

--
http://www.wescottdesign.com
Reply to
Tim Wescott

Thanks all for the assistance. Indeed, __idata did the work for me (I stayed in C with a little inlined assembly for now :-)

Runin

Reply to
runin225

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.