auto segment too large

thx for all the comments and specially to harash jameel. going large fixed the error but it will not run. i will use a better processor with external memory. i will not want the messages in code becoz they will change later. i ask you a question you did not think. can i change code in running? no. plz concentrate on the problem only. and the ip address is my network!

Well, we are already _way_ ahead of you in the thinking department. Having the strings in the code segment is the correct answer irrespective of your need to make changes.

So you need to change messages during runtime? The secret is that you can only send one (1) message at a time. So you only need to copy one (1) string at a time from the CODE segment. Or build one (1) at a time from scratch.

So it doesn't matter what you want to do. You will still never need to have more than one (1) string buffer in RAM. Didn't harash jameel remember to tell you that?

If you really find harash jameels tip best, why you even bother to ask the forum? Why didn't you directly switch to an ARM chip with huge amounts of RAM? Because jameels suggestion is the worst answer you can find for your specific processor.

By the way. If the answers have already said that a change to large would not get your program to work - why did you then try it and considers it the best answer?

Didn't harash jameel remember to tell you that?
If you really find harash jameels tip best, why you even bother to ask the forum?
Because jameels suggestion is the worst answer you can find for your specific processor.
If the answers have already said that a change to large would not get your program to work - why did you then try it and considers it the best answer?

If this is a "one off", so what but what if not.

I would (except for a one off") immediately fire anyone that was interested in what was 'easy' instead of what was best.

again except for a one off", using 'large' is probably the worst thing you can do to a '51 project.

Erik

thanks alot

>>>>>>>If you really find harash jameels tip best, why you even bother to ask the forum?

hey mate. what do you mean? i answered the question {{{{{ on this forum }}}}}. i am allowed to post here arent i? just coz you dont like my answer! are you the moderator? do you say who stays or goes?
i program very complex systems with 8051 chips and i know a lot. integer, float, even some assembler and i know all about interrupts asnd vectors too! i am an experienced professional expert and will answer questions if i can.

But the specific thing here is that if the program later needs to modify the strings before sending them, then the fixed-sized variables as declared above will fail - an IP number can be longer if all four groups are 3-digit long.

So why did you not suggest letting the strings stay in the code segment? After all, the compiler/linker just have to have a copy of them in the code segment, to be able to initialize the RAM copies.

And if you are a very experienced professional expert - why do you call it a bug in the tools, that the linker complains about memory overflow? Is it a design error of my car, if I can't fit 10 people, all properly belted?

Think about it: that makes no sense!

The strings are in the code - because they are literally part of your source code!

The only way you can change them is by changing the source, re-building, and downloading - so, again, they are in the code!

@ Harash Jameel
Did you ever bother to read the posted code ?
Did you pointed the problematic code ?
Did you suggested solutions or turnarounds ?
Do you think this is a "complex" 8051 system ?
Is this your way to get out of problems, to hide them in "large model"?
A polled uart_send and a timer_delay is trivial in 8051 systems
and can be accomplished even with less resources than a modest 8051 provides.

>>>>>>So why did you not suggest letting the strings stay in the code segment? After all, the compiler/linker just have to have a copy of them in the code segment, to be able to initialize the RAM copies.

mate. you are starting to annoy me. i know you can do it but it is not the right answer. have you {{{{ seen }}}} the test paper?????????? i have!!!!!!!!!!!!!!!!!

It (putting the constant strings in CODE space; ie, Flash) is certainly a much better answer than just masking the problem by switching to the Large Memory Model!!

Again, the constant strings must appear in CODE space anyhow - the startup code then copies them into XDATA - so why waste all that XDATA & copying? Why not just use the constant strings direct from CODE space??!

>>>>>>It (putting the constant strings in CODE space; ie, Flash) is certainly a much better answer than just masking the problem by switching to the Large Memory Model!!

did you read anything????? i said it is not the right answer. have you seen and done the question paper????? you will fail the exam with your answer!!!!!!!!!!!

i got a grade a++ first time!!!!!!!!!!!

"i said it is not the right answer"

So what, exactly, do you mean by "it" here?

I told you what I meant by "it" - and I stand by that.

"have you seen and done the question paper?"

What question paper?

"you will fail the exam with your answer"

Then it is a very stupid exam!

Constant strings like that most certainly should be placed in CODE space - as explained.

Note that this is the Keil forum; it is for discussing Keil products - not exam tips - and anyone using Keil C51 in practice would certainly be well-advised to put manifest constants like this in CODE space and not in automatic variables, for the reasons stated.

http://www.keil.com/support/man/docs/c51/c51_le_pgmmem.htm

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?????"

unless there was some specific detail in the rubric and/or question of which we are not aware.

But, if that were the case, you should be able to explain it...