hi am using 89c55 and wrote a code in c which acquires data from a serial device performs calculations and the gives an alarm when an abnormality is detected. when i compiled i got as Program Size: data=9.0 xdata=7569 code=4140. i used large memory model.it works well when i checked with keil simulator but when i burnt into my uc i don see any output. iam new to uc's should i add any eeproms before burning?? please help me out. thanks in advance.
regards, deepthi
Do you Have 8K of external RAM?
no i don have external ram but the chip has 20 K Flash Memory, 256 Bytes On-chip RAM,hex file was 14k in size which i have burnt into uc..
thanks andy for that response.ur right i should have had 8k external ram, and iam sure u might get irritated with my silly questions and mistakes,but am a starter and need some help from experts like u... can u just tell me if there is any way to reduce the xdata size.i mean how can i change the variables or code to fit in available flash memory. and please tell me what does this code and data indicate in program size after compiling..
The flash memory is for code - the instructions telling the processor what to do.
The data memory (RAM) is for variables, i.e. letting the program keeping track of what it is doing.
Your program needs a lot of RAM compared to what your processor supports. It is unlikely that the program can be shrinked to fit.
thanks for that information per..now i am clear why i have to have an external ram..please help me in using this ram, as how to interface to my uc.. and how do i burn a code into that..and should i include any extra code to access variables from that ram..
now i am clear why i have to have an external ram..
That's not all that clear yet.
Looking at your programs memory usage, it looks like your have a fairly small program (~4kB) that requires huge amounts (for a '51 program) of space (~8kB) for its variables.
You should look at what's actually in those ~8kB. Are there constants (lookup tables, strings, etc) that could be moved to code memory instead? Are there statically allocated variables that don't need to be static? Does the program use memory overlaying?
i don know what is memory overlaying..please explain me what that is. and as u said my code size is 4kb only, these are the variables am using.
float in=1,out[1000],th1=0,th2=0,spkf=0.0075,npkf=0; char squr[1000],low=0,high=0,der=0,mwi=0; float hr=0,rr=0,rr_r=0,out1=0; int z=0,m=0; unsigned char e=0,h=0,r=0,v=0,i=0,q=0,b=0,d=0,l=0; char k[1066],dat=0,y;<pre/>
i don know what is memory overlaying..please explain me what that is.
The exact details are described in the C51 compiler manual.
It is a way to save memory used for variables by figuring out which variables do not exist at the same time, and making those variables use the same space in memory.
Example:
void some_function_1(void) { char a; ... } void some_function_2(void) { char b; ... } void some_function_3(void) { some_function_1(); some_function_2(); }
a and b do not exist simultaneously, and hence they can share the same location in memory.
these are the variables am using.
You should check whether you really require those huge arrays, namely:
float out[1000]; char squr[1000]; char k[1066];
That's about 6 kB right there.
i need those three huge arrays all through my code so i cant avoid them, will the size gets reduced if i declare those arrays dynamically instead of static declaration and coming to this memory overlaying, thanks for giving an example.ill modify my code acc to this and will get back to u. thanks for responding all of u
Dynamic or static doesn't matter.
What matter is how much variables you need at the same time. If you need these arrays at the same time, then you need to have enough RAM for storing them.
Of an array stores constant - unchanging - data, then you can move the array into the flash, i.e. among the code. If the array contains values that are seldom changed, then you may use EEPROM or similar for storing the data. But whatever you do, you will need enough memory - of the correct type - for storing the arrays, or you will have to figure out a way to reduce the size of the arrays.
the data of these arrays is not constant but changes frequently so i think i have to go for EEPROM or external RAM.. but i don know how to interface that and use it while burning code into that..please help me out in this regard and it would be very helpful if any circuit diagram or code is given.. thanks in advance
You do _not_ burn code into the RAM. The RAM is for the variables. And as you have noted - the simulator can work with your program. So start by googling for how to connect RAM to your processor.
You do not want to use EEPROM fo frequencly changing data. If it is important that the data survives a power loss, then you should look for other alternatives, such as battery-backed RAM or ferro-electric memories. But every memory cell in EEPROM can only handle a limited number of write cycles before wearing out. This can be mitigated by having a very large EEPROM and do wear-leveling, where you use many memory cells to share the number of writes. But wear-leveling is a complex solution that should be avoided if possible.
thanks u all for responding and giving me suggetions .. ill try to solve my problem by following ur suggestion and will gat back to u if there is any problem.. thanks all of u once again..
That's not strictly true, and thinking that way can get misleading.
The 8052 processor itself knows nothing about Flash, RAM, or any other memory technology.
All the 8052 processor itself knows is that it has a CODE address space, and an XDATA address spaces - and those two address spaces are quite distinct.
The CODE address space is where instructions are fetched from for execution - but it can also be read as data. The key thing to remember is that the 8052 architecture has no way to write to CODE space - it is strictly read-only. Thus most applications will, in practice, use some kind of read-only memory technology (such as flash) in the CODE space.
The XDATA address space has both read & write data access - but instructions for execution cannot be fetched from XDATA space. Thus most applications will, in practice, use some kind of read-write memory technology (such as RAM) in the XDATA space.
Indeed!
It all rather sounds like you're trying to run before properly learning to walk!
I think you should spend some time reviewing the basics of the 8051 architecture, and then some simple, basic programming examples before continuing with this.
Standard advice:
First, you need to read the uVision Getting Started guide, and work through the example projects in it. This will give you a proper introductions to the tools, how they work, and how to use them - rather than just jumping-in blindly at the deep-end! You need to study the following documents - commonly referred to as "the bible" for the 8051:
Chapter 1 - 80C51 Family Architecture: www.nxp.com/.../80C51_FAM_ARCH_1.pdf
Chapter 2 - 80C51 Family Programmer's Guide and Instruction Set: www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
Chapter 3 - 80C51 Family Hardware Description: www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
Are you also a newbie to 'C' programming in general? If so, you'll also need a good 'C' textbook.
Here are some other introductory & reference materials: http://www.keil.com/books/8051books.asp www.8052.com/tutorial.phtml
You will need to read the Data Sheet for your particular processor, and the Manual(s) for any development boards, etc.
You will need to read the Manuals for the C51 Compiler, A51 Assembler, etc, etc,...
thanks alot neil for those documents and information u have given.. may be ur true that am trying to run....thanks alot once again...
can any one please explain me how to select a microcontroller based on XDATA size CODE size and HEX file size.Is it true that the particular UC should have flash memory of size >= HEX file size??
.Is it true that the particular UC should have flash memory of size >= HEX file size??
the size of the HEX file is no indication of the size of the program at hand. if you want to be sure, you must generate a .bin file using 'fromelf'. such a file such can be programmed directly onto flash, hence: if that one is smaller than the storing media, you are in business! you can also have a look at the map file, of course.
If your program requires x bytes of XDATA space and y bytes of CODE space, it should be obvious that your target system must provide at least x bytes of XDATA and at least y bytes of CODE space.
Those could be provided within the microcontroller itself, or as external memory...
So feed those criteria into this parametric search engine: http://www.keil.com/dd/search_parm.asp
That's true.
For further details, including the hex file format, see: http://www.keil.com/support/docs/3250.htm
"if you want to be sure, you must generate a .bin file"
Not at all - the C51 tools tell you the image size directly!
"using 'fromelf'"
The C51 tools don't use ELF - so I doubt that 'fromelf' will help?
" if that one is smaller than the storing media, you are in business!"
Not quite - you need both the Code storage area and the data storage area to be of adequate size before the program will run correctly...
Andy, I have a terrible headache today - something made me see "ARM" toolchain instead of C51! I apologize to the OP.
so as said by per before that The flash memory is for code - the instructions telling the processor what to do.
can i select a UC with flash memory >= code size?? and please tell me what does data size represent.
The text "The flash memory is for code" should be read as "is intended for code". I also wrote that if "an array stores constant - unchanging - data, then you can move the array into the flash, i.e. among the code."
No, I don't think any manufacturer sells any processor with flash memory > code size. But the compiler does support placing read-only data into the code region, so it will be enough to have a processor with a flash size larger than what you need for the program code. The remaining region of the flash may then be used for constant data.
There are some 8051 chips that have a partially overlapping memory structure, where the application can reprogram the flash. This can allow the flash to be used for semi-static data - but the flash memory supports a limited number of write cycles, so the flash region can't be used instead of RAM.
I'm not sure what you mean with "what does data size represent". The processor may have more than one data region, in which case there may be more than one data size.
Oh yes they do!
The 8051 architecture limits the CODE size to 64K - but there are 8051-based chips available with >64K Flash (eg, SiLabs).
I presume you mean:
"can I select a uC with flash memory >= my progran's code size?"
The answer should be obvious!
Think about it: If you buy a PC program that says it requires x MB RAM and y MB disk, can you use it on a PC that has more RAM and disk than that...?
Depends on view. The 8051 chips with > 64kB flash has the flash mapped for CODE space. It's just that you will need banking or similar.
But have you seen any chip manufacturer selling a 8051 with flash for the RAM area - unless it has the overlapped CODE/XDATA regions I mentioned?
"can I select a uC with flash memory >= my progran's code size?" sorry if iam not clear with this statement here i mean to ask if it is sufficient to consider code size in the selection of UC without considering the XDATA size, as it was said befor that the XDATA has nothing to do with flash memory size and it looks for RAM.so i just wanted to confirm that point.
and in the statement "what does data size represent" i wanted to know what exactly it represents as when i compiled my code in keil i got as Program Size: data=9.0 xdata=6320 code=3632.
in the beginning i thought that i can use 89c51 for my code what ever i had, later on with all of ur advice i understood that i have to add an external RAM as my XDATA is large.later i was suggested to go for UC with larger flash memory as my HEX file size is around 12K. This is the reason i raised an issue of "can I select a uC with flash memory >= my progran's code size?"
Please tell me if that is sufficient and also about the data=9.0
The flash memory can not be used instead of RAM. It is intended for code but you can instruct the compiler to place constants there too. But it is a type of read-only memory, so if you need to be able to regularly change the value of a variable then you need to look at something else.
DATA in this situation is one of several memory areas in your processor. The different memory areas in the processor has different capabilities, and requires different ways to access them. The DATA area is a RAM area built into the 8051 chip. The XDATA is another memory area, originally intended for use with extermal memory chips and requiring different processor instructions to access the variables. The 8051 can have internal and/or external XDATA memory. The DATA area is extremely limited in size, but it is possible to have very large XDATA support. The instruction set is intended for accessing up to 64kB of XDATA, but it is possible to get past this limit. People who think that 64kB of XDATA is little should probably look at other processor architectures instead.
You can use the following link and search for 8051 chips with enough space for your program and for your variables. http://www.keil.com/dd/search_parm.asp
Note that the colum for RAM has the heading "DATA +XDATA", giving the built-in amount of RAM for these two memory areas.
For configurations that are seldom changed, but must be remembered after a power loss, you can look at the column "On-chip EEPROM". But you are limited to 100.000 to 1000.000 writes/memory cell for most EEPROM, so it is a complement, but not suitable to use instead of RAM.
Thanks PER for that information..
That means that your program uses 9 bytes of DATA space and 6320 bytes of XDATA space and 3632 bytes of CODE space.
Clearly, this means that your target system must provide at least 9 bytes of DATA space and at least 6320 bytes of XDATA space and at least 3632 bytes of CODE space. Whether these are provided internally on the chip, or with external chips on your board (or a combination of both) is really immaterial.
PS
If you're still not sure of the differences between DATA, CODE, and XDATA spaces, then you still haven't sufficiently studied the basics of the 8051 architecture - including the so-called "bible". See the links provided earlier.
look up those two
View all questions in Keil forum