I am using Keil uvision4.I created a new project,saved it in a new folder in the desktop.here i chose the device Infenion's C051.opening the project,I created a new file and saved it with .c extension in the same folder.the startup.obj file is in the same folder.the c prog.follows:
void main(void){ while(1){} }
on building this I get the following warnings: *** WARNING L1: UNRESOLVED EXTERNAL SYMBOL SYMBOL: ?C_START MODULE: STARTUP.obj (?C_STARTUP) *** WARNING L2: REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL: ?C_START MODULE: STARTUP.obj (?C_STARTUP) ADDRESS: 080AH this prob. is addressed many times in this forum, but here there is no assembly prog in the C prog.the only assembly prog is startup.asm.i am unsure as to how to resolve it.
Have you set your project to generate assembler source from 'C' source?
http://www.keil.com/support/man/docs/c51/c51_src.htm
Thank you very much! now it works well.
Note that every C51 message is documented in the online documentation.
The documentation for L1 is here: http://www.keil.com/support/man/docs/bl51/bl51_l1.htm
It includes a link to this Knowledgebase article, which describes precisely your case: http://www.keil.com/support/docs/1646.htm There are also cross-references to other relevant articles and forum posts.
The documentation for L2 is here: http://www.keil.com/support/man/docs/bl51/bl51_l2.htm this also includes a link to the same supporting information
All this stuff is there to help you - make the most of it!
Hi ! I am using the uvision4 software by Kiel for 80517 coding. below is the code I need help with: It simply switches P0 on and off at each compare timer overflow alternately.
#include<REG517.H> void main(void) { int x=0; CTCON=0x00; //set the clock to have a frequency fosc/2; EAL=1; //enable global interrupts IEN2=0x08; //set the compare timer overflow bit in IEN2 to 1 to allow for the same request CTRELL=0x00; //loading the timer CTRELH=0xFF; while(1) { if(CTCON==0x08){ //check if the CTF flag is on which is set by hardware on compare timer overflow if(!x){ //a random flag,helping us to switch P1 on and off P0=1; //switch on P1.0 CTRELL=0x00; CTRELH=0xFF; //load again IEN2=0x00; //disable the overflow request flag as we have taken care of the interrupt } else{ P0=0; //next time overflow occurs the same pin is switched off CTRELL=0x00; //load again CTRELH=0xFF; IEN2=0x00; //same as above } CTCON=0x00;} switch off CFT bit so that loop is not entered till overflow. } }
the problem is while i simulate it. some statements, which are assembled, but not touched by the simulator, like the stat. P0=0. While the rest of the statements are assembled, only the statements CTRELL=0x00 and CTRELH=0xFF,IEN2=0x00;in the segment if(!x) is not assembled.
Initially there was an error which said no execute/read permission for certain memory locations, thus i set the memory locations from beginning till the end to execute,read and write in the memory map function under debug. Now there is no such error, but there are certain glitches as mentioned above. Also, both the if and else statments are executed in each while loop!
I am using the uvision4 software by Kiel
No, you're not. The company's name is Keil. Kiel would be a city in the north of Germany.
the problem is while i simulate it
No. The problem is that the compiler has managed to out-smart you long before the simulator was even started.
some statements, which are assembled, but not touched by the simulator,
First, C statements are not assembled. They're translated, or compiled. Second, your assumption that each C statement should be touched as you step through the program is incorrect. The compiler knows a whole lot better than that.
CTRELL=0x00 and CTRELH=0xFF,IEN2=0x00;in the segment if(!x) is not assembled.
Well, since they're the same in both the if and else paths of execution, the compiler rightly decided that it would be silly to emit them twice, so you don't see what you expect. And that's before we consider that 'x' is a constant zero in this code, so the compiler doesn't have to actually emit any code for it at all.
The only problem here is that your expectations are wrong. You're dealing with an optimizing C compiler here, not a simple assembler.
Thanks a lot.Great help!I am appreciating the compiler a lot better, now that I know why it did, what it did.