On Thu, 2011-03-24 at 00:56 +0800, duck donal wrote:
> #include <AT89X51.H>
> #include<8051.h>
You only have to use the header which is appropriate for
the processor you are using, 2 mostly the same header
files is overkill :-)
> __sfr __at (0xfb) f_work;
> f_work=0x01;
> while(F1==0)
> f_work=0x00;
> }
> Line 18,f_wren at 0xf1 should have been assiged the value
> 0x06.However the result of simulation is wrong,the f_wren's value did
> not changed.
Did you ever think about the fact that there might not be
any RAM/SFR at the location you set to hold the values you
are writing to that location ?
If you just need a variable to hold a value, use for example :
unsigned char f_work;
You can put _data, _xdata or _idata in front of that for the
various RAM available in the uC.
> I check the newpp.asm which is generated according to the newpp.c.
> The newpp.asm is correct.
> In newpp.asm's corresponding position generated the statment:
> mov _f_wren,#0x06.
> Thus I guess the compile is fine, the assembler or the linker may make
> some mistakes.
The compile is good, I think the writer is making a
mistake.
> So,that is question:
> 1.what is the mistake exactly?
Why are you defining variables as SFR's ?
> How can I use the assembler to generate the .hex file?
asx8051 -o newpp.asm
sdcc newpp.rel -o newpp.ihx
roelof
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
