This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

auto segment too large

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;
} }

Parents
  • Well, lucky you if you managed an a++ on your exam, since your answers here indicates that you must have been more than a little bit lucky.

    Programming don't have "right answers". Programming have better and worse solutions to problems. If you had a teacher that thought "large" was the "right answer", then that teacher did not manage a grade a++ first time, second time or any time.

    Your "right answer" is to use wires to get the exhaust pipe to hang on to the car.

    Your "right answer" is to fit additional lights to your car with duct tape.

    Any teacher with a slight bit of skill would think it a better answer to have the strings only in the code segment, than to have the strings first copied into individual RAM variables before being used. Especially since RAM is often a very tight resource in embedded processors.

    Any student with a slight bit of skill should see the same. And - if needed - point out to that teacher that there are better ways to do things.

    And a skilled developer would also recognize that in case the strings needs to be modified before being sent, it would be enough with one (1) single RAM buffer for formatting the next command to send. After that command has been sent, that single buffer will be available for reuse, for formatting the next command, if needed.

    Skill, in programming, isn't to learn 10 "absolute truths". Skill, in programming, is to be able to understand problems and analyze the consequences of different alternative solutions. Such analysis would quickly show the advantage of keeping just a single copy of the strings - the copy that the compiler/linker is forced to store in the code, since any data in RAM is lost when the power is removed and have to be recreated somehow. Either by making a copy from code, or by having the code build the strings, character by character by sprintf(), strcpy(), individual character assignments or similar.

    Your case will not be stronger because you press and hold your !!!!!!!!!!!!!!!!! button. "large" is still not a good solution to this specific problem, even if it can be used as a rough work-around in case the specific processor used happens to have XDATA space available.

    Some day, when you have made your income for a number of years writing software - especially embedded software - you might have a different view on things.

    The above code is a trivial piece of code. So trivial that it (if it was correct) could be seen as a little code example created between two phone calls just to display a concept. Real-life code is seldom so trivial. Even small embedded projects may have 10k+ lines of code. And since the complexity grows with the amount of code, it is important that every part of the code is written with care. And using good practices. But good practices needs to be used already from the start. Good practices is to know the disadvantages with "large". And to know the disadvantages with making useless copies of data. And the need to value RAM. And to recognize the difference in access costs between DATA and XDATA and hence manually decide what information to place in cheap or expensive RAM.

    So back to you - are you a professional, as you claim? Then your main goal should be a strong want to improve. And a good way to improve is to ask "why" if you see something you don't recognize or understand. Instead of responding back with a rather childish "did you read anything?????"

Reply
  • Well, lucky you if you managed an a++ on your exam, since your answers here indicates that you must have been more than a little bit lucky.

    Programming don't have "right answers". Programming have better and worse solutions to problems. If you had a teacher that thought "large" was the "right answer", then that teacher did not manage a grade a++ first time, second time or any time.

    Your "right answer" is to use wires to get the exhaust pipe to hang on to the car.

    Your "right answer" is to fit additional lights to your car with duct tape.

    Any teacher with a slight bit of skill would think it a better answer to have the strings only in the code segment, than to have the strings first copied into individual RAM variables before being used. Especially since RAM is often a very tight resource in embedded processors.

    Any student with a slight bit of skill should see the same. And - if needed - point out to that teacher that there are better ways to do things.

    And a skilled developer would also recognize that in case the strings needs to be modified before being sent, it would be enough with one (1) single RAM buffer for formatting the next command to send. After that command has been sent, that single buffer will be available for reuse, for formatting the next command, if needed.

    Skill, in programming, isn't to learn 10 "absolute truths". Skill, in programming, is to be able to understand problems and analyze the consequences of different alternative solutions. Such analysis would quickly show the advantage of keeping just a single copy of the strings - the copy that the compiler/linker is forced to store in the code, since any data in RAM is lost when the power is removed and have to be recreated somehow. Either by making a copy from code, or by having the code build the strings, character by character by sprintf(), strcpy(), individual character assignments or similar.

    Your case will not be stronger because you press and hold your !!!!!!!!!!!!!!!!! button. "large" is still not a good solution to this specific problem, even if it can be used as a rough work-around in case the specific processor used happens to have XDATA space available.

    Some day, when you have made your income for a number of years writing software - especially embedded software - you might have a different view on things.

    The above code is a trivial piece of code. So trivial that it (if it was correct) could be seen as a little code example created between two phone calls just to display a concept. Real-life code is seldom so trivial. Even small embedded projects may have 10k+ lines of code. And since the complexity grows with the amount of code, it is important that every part of the code is written with care. And using good practices. But good practices needs to be used already from the start. Good practices is to know the disadvantages with "large". And to know the disadvantages with making useless copies of data. And the need to value RAM. And to recognize the difference in access costs between DATA and XDATA and hence manually decide what information to place in cheap or expensive RAM.

    So back to you - are you a professional, as you claim? Then your main goal should be a strong want to improve. And a good way to improve is to ask "why" if you see something you don't recognize or understand. Instead of responding back with a rather childish "did you read anything?????"

Children
No data