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.
i get the error "main() auto segment too large" for the given program which should be run on atmet 89c51 how to fix it thanks.........
#include <reg51.h> void Delay(); char serialsend(char []);
void main () { char z; char command1[]={"AT+CGATT=1\r"}; char command2[]={"AT+CSTT= \"ufone.pinternet\"\r" }; char command3[]={"AT+CIICR\r"}; char command4[]={"AT+CIFSR\r"}; char command5[]={"AT+CIPSTART=\"TCP\"\"121.52.147.94\"800\r"}; char command6[]={"AT+CIPSEND\r"}; char command7[]={"GPRS is Activated"}; char command8[]={"26"}; TMOD = 0x20; TH1 = 0xFD; SCON = 0x50; TR1 = 1; serialsend(command1); Delay(); serialsend(command2); Delay(); serialsend(command3); for(z=0; z<3; z++) { Delay(); } serialsend(command4); Delay(); serialsend(command5); for(z=0; z<10; z++) { Delay(); } serialsend(command6); for(z=0; z<5; z++) { Delay(); } serialsend(command7); serialsend(command8);
} char serialsend(char array[]) { int i=0; while(array[i] != '\0') { SBUF = array[i]; while(TI == 0); TI = 0; i++; } }
void Delay() { unsigned char x; for(x=0; x<40; x++) { TMOD=0x10; TL1=0xFE; TH1=0xA5; TR1=1; while (TF1==0); TR1=0; TF1=0; } }
hey mate. you have found a bug. search the forum and you see lots of programmers find the same bug. simple fix. use the large model.
No, you have not found a bug.
What you have found is a well-documented artifact of the 8051 hardware architecture.
www.catb.org/.../smart-questions.html
"simple fix. use the large model"
At the cost of increased code size & reduced speed - which may well be a non-issue in this particular case...
hey mate. i had the same bug before and changed the large model. the bug was fixed!!!!! you try. if it works then you fixed the bug too!!!!!!
No.
despite the compilation/linker error this code will not work because Timer1 is setup first for serial(uart)
TMOD = 0x20;
but at delay routine its operation is altered
TMOD=0x10;
and not restored. The delay function should use a different Timer, maybe T0 if is free.
The polling method for uart is simple but the best option is to use the Interrupt system to do the the serial send operation in the backgroud.
"hey mate. i had the same bug before and changed the large model. the bug was fixed!!!!! you try. if it works then you fixed the bug too!!!!!!"
We can see that you, Jameel, have a different definition of the word "bug". But you have to learn the correct meaning of the word if you want to get anywhere.
char command1[]={"AT+CGATT=1\r"};
Why make all your commands into auto variables inside main()?
Don't you believe in having them as constant strings in CODE memory?
>>>>>>>>Don't you believe in having them as constant strings in CODE memory?
rubbish. we tried to do it before and it didnt work in vs!!!!!!!!!!!!
fix the bug. go large!!!!!!!!
go on. try it.
Also besides the Timer1 mis-re-initialization in the above code the strings (array of chars) must be declared as code segment
code char command1[]={"AT+CGATT=1\r"};
so that these bytes be stored in code memory that is at leat 4K even for 89C51. by the current use compiler is trying to store them in DATA segment that is not enough.
If the system has 256bytes of IRAM then instead of code they could be stored to idata if this is convenient.
There is no need to change to "large model" for this particular reason.
fantastic idea, "going large" without any XDATA, THAT will 'fix it'
Erik
>>>>>>>fantastic idea, "going large" without any XDATA, THAT will 'fix it'
check the data sheet!!!!!!! its got 4k of perom!!!!!!!!!!!!!!!!!!!!
and when he goes large the linker error bug will go away!!!!!!!!!!!!!!!!
"we tried to do it before and it didnt work in vs!!!!!!!!!!!!"
VS? Visual Studio? Or what?
And no - sentences don't end with a gazillion exclamation marks unless the writer is confused.
No bug can be fixed by "large". A bug can possibly be hidden by switching memory model. But it is still stupid to require the program to have one copy of the commands in CODE, and then make a new copy in RAM. And it is even more stupid to ignore tips that points out such things.
and when he goes large the linker error bug will go away!!!!!!!!!!!!!!!! sure but his code will not run unless he has invented "air memory" are you one of those that when the tool run and say "no error" you believe all is OK?
btw it is NOT "linker error bug" it is a "valid linker error"
Note that the strings - and any other initialisation data - have to be stored in Flash anyhow, whence they are copied to the runtime locations in RAM.
So, if the strings are not going to be modified, it is a complete waste of RAM to copy them there!
http://www.keil.com/support/man/docs/c51/c51_ap_init.htm
The above posted code at thread: http://www.keil.com/forum/21274/
contains a "valid" public IP address pointing to PERN, Dara, Pakistan and the rest info is showed here: www.iplocationfinder.com/121.52.147.94
When you presenet parts of code for discussion, it is wise to show demo data and not to present real data like the mentioned IP.
If the issues about code segment for strings is fixed and the T1 mis-re-initialization is fixed also, then this piece of code can start working.