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.
Hi Ken, I understand that the 8051 has 256 bytes of internal data. Well, after declaring variables and array's, I get the error
*** ERROR 107: ADDRESS SPACE OVERFLOW SPACE: DATA SEGMENT: _DATA_GROUP_ LENGTH: 0062H Target not created
GetMACInput(strSrcDest); printf("MAC Address......... "); printf("%02X:", strSrcDest->SrcMAC1 >> 8); printf("%02X:", strSrcDest->SrcMAC1 & 0x00FF); printf("%02X:", strSrcDest->SrcMAC2 >> 8); printf("%02X:", strSrcDest->SrcMAC2 & 0x00FF); printf("%02X:", strSrcDest->SrcMAC3 >> 8); printf("%02X", strSrcDest->SrcMAC3 & 0x00FF); printf("\r\n");
In addition to the 8051 register banks and bit-addressable area, the stack resides in internal RAM too, positioned after IDATA up to the end of internal RAM. With your "maximum amount of internal data", is the remaining stack size big enough for your function return address nesting and interrupts' context saving? Given the symptoms you describe, that would be the first place I'd look.
I don't quite understand. Am I to understand that I don't necessarily have access to the entire 256 bytes, but less than 256 bytes due to Stack Size/ Nesting and interrupt context saving? >>...the stack resides in internal RAM too, >>positioned after IDATA up to the end of >>internal RAM idata is supposed to be able to access the entire 256 bytes of internal ram. I am not sure what you mean by after idata? I suspect the Stack is being saved in Ram, limiting the size of ram. I guess what you mean by Function returns and stack size is something like this...
Function0(){ Function1() } Function1(){ Function2() } Function3(){ Function4() } Function5(){ Function6() } Function7(){ Function8() }
"Am I to understand that I don't necessarily have access to the entire 256 bytes, but less than 256 bytes due to Stack Size/ Nesting and interrupt context saving?" Yes, you can't use all the idata space. The stack needs some of it. ">>...the stack resides in internal RAM too, >>positioned after IDATA up to the end of >>internal RAM" What Dan meant was that the stack starts in idata above your idata variables. "I am curious about Function calls and the space required. Do the nested Functions require Ram Space? Is there a difference between void Func1() and int Func1()?" For every function nesting the return address (two bytes) is pushed onto the stack. Interrupt service routines (sometimes) push considerably more data (PSW, registers etc) onto the stack. Values aren't returned from functions on the stack so there is no difference between int and void in this context. "I'm not exactly sure what interrupt context means. I am using an interrupt" When the ISR is called the 'context' of the uc is saved. The 'context' is the contents of any registers that will be changed in the ISR, so that they can be restored on exit. "I wish the compiler would have complained. The program compiles just fine" It would be very difficult if not impossible for the compiler to calculate worst case stack usage. You'll have to do that yourself! Stefan
Hi, I am programming in C. I've never looked at registers or Memory space. Is there a way to figure it out in C, without actually looking at registers and Memory space? In order for me to use the maximum amount of internal ram, Maybe I can somehow figure out how much ram space my code is actually taking without debugging and looking at memory space? I don't exactly know how to figure out how much space the stack is taking? How much memory does each call to a function take up? Does it make a difference if the function returns a int, rather than a void? Thanks for your help,
"Am I to understand that I don't necessarily have access to the entire 256 bytes, but less than 256 bytes due to Stack Size/ Nesting and interrupt context saving?" Yes, at a minimum, a single register bank is used consuming 8 bytes (addresses 0x00-0x07) out of the 256, your "data" consumes whatever it does out of the address range 0x08-0x7F, your "idata" consumes whatever it does out of the address range 0x08-0xFF (starting where "data" ends), and finally the stack gets any bytes remaining from the end of "idata" up to 0x100 (assuming you have not specified any functions to be reentrant). "I am not sure what you mean by after idata? I suspect the Stack is being saved in Ram, limiting the size of ram." Yes, see above. By convention, C runtime startup initializes the stack pointer with the address of the last byte of "data", or in your case "idata", memory used. "I guess what you mean by Function returns and stack size is something like this... Function0(){ Function1() } Function1(){ Function2() } Function3(){ Function4() } Function5(){ Function6() } Function7(){ Function8() } I am curious about Function calls and the space required. Do the nested Functions require Ram Space?" A function call pushes a 2-byte return address on the stack. Using your example, the last function is nested 10 function calls deep = 10 PC saves = 20 bytes of stack used. Plus any additional stack used by library calls in Function8(). Plus any processor context saved when that library routine gets interrupted... You get the idea. You've got to account for the stack space required for the worst case. "Is there a difference between void Func1() and int Func1()?" Not as far as the stack is concerned (assuming a non-reentrant model). "I'm not exactly sure what interrupt context means." Sorry, I probably should have said processor context saved (and restored) by the interrupt service routine. The 8051 hardware itself pushes the program counter on the stack during the ISR "call" process. ISR prolog (context save) and epilog (context restore) code handles safely saving and restoring the processor context to the state it was before the interrupt for those processor resources that the ISR uses (e.g., usually ACC and PSW, possibly some of R0-7, etc., depending on your ISR). This processor context is saved on the stack in addition to the PC. "I wish the compiler would have complained." The compiler/linker does not necessarily know how much stack you'll need. As a side note, you would be well-advised to better understand the 8051 architecture, since the architecture plays a big part in the effective use of C on this microcontroller that was never designed with C in mind.
"Maybe I can somehow figure out how much ram space my code is actually taking without debugging and looking at memory space?" Have the linker process output a memory map file. The memory map will show you how much of what memory space is used.
"I am programming in C. I've never looked at registers or Memory space." To program a microcontroller in any language, you MUST fully understand the hardware. You need to read the datasheet for your device. "Maybe I can somehow figure out how much ram space my code is actually taking without debugging and looking at memory space?" If you take a look at the .cod or .lst file assembler outputs in conjunction with the function call tree in the .map file I think you could figure out worst case stack usage by adding two bytes per function for the deepest level of nesting, than adding all the registers pushed in each ISR. Stefan