Because when compiling. The following information appears... MAIN.C(1351): error C249: 'DATA': SEGMENT TOO LARGE Change the small:variables in DATA into the Large:variables in XDATA. While compiling again. The following information will appear.... Could you tell me what kind of situation it is. How to solve?? Help to answer it. THX! *** ERROR L102: EXTERNAL ATTRIBUTE MISMATCH SYMBOL: DDS_DATA_TEMP MODULE: tranCode.obj (TRANCODE) *** ERROR L102: EXTERNAL ATTRIBUTE MISMATCH SYMBOL: DDS_DATA MODULE: DDS_value.obj (DDS_value) *** ERROR L102: EXTERNAL ATTRIBUTE MISMATCH SYMBOL: LATCH_COUNTERvalue MODULE: Counter.obj (COUNTER) *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?ONUSBSUSPEND?MAIN *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?MAIN1?MAIN *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?_TRANSMITDATAEPX?UPSD_USB *** WARNING L1: UNRESOLVED EXTERNAL SYMBOL SYMBOL: TIMEINT2 MODULE: initial.obj (INITIAL) *** WARNING L1: UNRESOLVED EXTERNAL SYMBOL SYMBOL: SAVEANDRECALL MODULE: initial.obj (INITIAL) *** WARNING L2: REFERENCE MADE TO UNRESOLVED EXTERNAL BL51 BANKED LINKER/LOCATER V5.12 09/07/2005 11:41:29 PAGE 161 SYMBOL: TIMEINT2 MODULE: initial.obj (INITIAL) ADDRESS: 848AH . . . . . *** ERROR L118: REFERENCE MADE TO ERRONEOUS EXTERNAL SYMBOL: LATCH_COUNTERvalue MODULE: Counter.obj (COUNTER) ADDRESS: B612H *** WARNING L1: UNRESOLVED EXTERNAL SYMBOL SYMBOL: CUSCL_value MODULE: upsd_usb.obj (UPSD_USB) *** WARNING L2: REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL: CUSCL_value MODULE: upsd_usb.obj (UPSD_USB) ADDRESS: B8E3H Program Size: data=174.0 xdata=613 code=47389 LINK/LOCATE RUN COMPLETE. 11 WARNING(S), 131 ERROR(S)
anyone know of more than 5 seconds to compile and link Not that it changes the point, but since you asked: one of my projects takes about 17 seconds to compile all files and about 60 seconds to link. (119 files, a bit under 70K lines of source, roughly 90K of image and 32K of data.) The linker in particular seems noticeably non-linear in its run time with respect to project size. When the project was just a wee nubbin of its current self (say around 8-10 KLOC), compile and link was indeed very quick. And of course when it decides to do its global register re-optimization, it takes four passes and more than four times as long.
OK, I missed that one. Superoptimization may, indeed extend the processing time dramatically. Believing in the NASA philiosophy "we fly what we test" I do not optimize beyond two. You may ask "what does that have to do with testing?". Simply, if a bug is found at optimization 47 there is no way to debug it since the source and object will have very little resemblance and if I can not debug, what is the purpose of writing code. Also, so called "testing" is, in my opinion, worthless as to finding functional problems, it only serves as a means of finding clerical problems. You may have a differnt opinion, I shall not argue beyond what I stated above. Erik
"Of course, my timing estimate above does not include uVision overhead" FYI: Provided uVision is already open, it adds no more overhead to a build than starting a batch file. "Superoptimization may, indeed extend the processing time dramatically." It most certainly does - no question at all! Particularly the "Linker Code Packing" "Simply, if a bug is found at optimization 47 there is no way to debug it since the source and object will have very little resemblance" It is possible - just very much more difficult. The LX51 Linker produces a disassembly listing of what it's actually done to aid in debugging. This is a very big issue that people should really think about very seriously before just jumping blindly into the higher optimisation levels... It's the same old story: there's no such thing as a free lunch; you can't have your cake and eat it; the tools can't magically double the 8051's address space out of thin air - the price you pay is loss of debuggability!
Where Could you tell me how I should check the question? Need to check whether the Address is covered again? Need to reduce the use of the variables? My variables is under the situation that can't be reduced . I deserve and do?
"Where Could you tell me how I should check the question? Need to check whether the Address is covered again? Need to reduce the use of the variables? My variables is under the situation that can't be reduced . I deserve and do?" Fix the errors and warnings one at a time starting from the first, as others have told you.
Jia, Drew explained the cause of your problem: "Something has been declared with an explicit memory type that doesn't match its real memory space. Given your description, this is probably one of the items you moved from data to xdata. Some other piece of code still refers to it in the data space." So you need to ensure that all your uses of the memory-type specifiers (data, xdata, etc) are consistent. Another possible cause could be that you didn't rebuild everything when you changed the memory model. You need to rebuild everything!