Improper fixup

"the problem I have with using the large model is that it is far easier to correctly assign xdata to variables where "slow is allowed" that to use the large model and 'catch' all cases where DATA should be used."

I see; but I was specifically talking about large applications where most data is going to have to be in XDATA anyhow - in which case littering 98% of all definitions with an 'xdata' qualifier is pointless and just adds unhelpful "noise" to the source.

In such cases, "slow is allowed" is the rule and "fast required" is the exception - so only those should be specially qualified as DATA (or IDATA or whatever)

"the problem I have with using the large model is that it is far easier to correctly assign xdata to variables where "slow is allowed" that to use the large model and 'catch' all cases where DATA should be used."

I see; but I was specifically talking about large applications where most data is going to have to be in XDATA anyhow - in which case littering 98% of all definitions with an 'xdata' qualifier is pointless and just adds unhelpful "noise" to the source.

In such cases, "slow is allowed" is the rule and "fast required" is the exception - so only those should be specially qualified as DATA (or IDATA or whatever)

"Please do not make that I am not using the optimizer, into that I am not interested in optimal code."

Never intended to do that: just pointing out that getting the utmost smallest code size is not "optimum" in all cases - other requirements may take precedence...

I was specifically talking about large applications where most data is going to have to be in XDATA anyhow - in which case littering 98% of all definitions with an 'xdata' qualifier is pointless and just adds unhelpful "noise" to the source.
Ok, first "there is no rule without exceptions"
second: I can not think of any application that is reasonably well designed where (I)DATA can not handle all/most 'single' variables so the number of declarations of xdata will be realtively few. It takes ONE 'xdata' to declare a buffer of 5000 bytes.

If, however, you go with the LARGE model almost every 'single' variable should have (i)data attached to it i.e. more 'noise'.

Again, if someone does not give a hoot, then all discussion of this is moot, I have seen "I use large so I do not have to worry about space" which I read as "I use large because I am a lazy dog"

Erik

I have seen "I use large so I do not have to worry about space" which I read as "I use large because I am a lazy dog"

Please explain how taking advantage of the available resources makes one a 'lazy dog'.

you would ask that would you not? feel hit?

Erik

"Please explain how taking advantage of the available resources makes one a 'lazy dog'"

Lazy is: "I can't be bothered to think about which Memory Model to use, so I'll just go for 'Large' and not bother about it"

As opposed to considering the pros & cons of each model, and choosing the most appropriate one.

I have seen "I use large so I do not have to worry about space" which I read as "I use large because I am a lazy dog"

1 - Take a project.
2 - Analyse all of the available information relating to the CPU, memory, speed, compiler, resources etc
3 - Determine the model most appropriate for the situation
4 - Use it

Now, after going through this procedure, the team might decode that the large model is the most suitable.

Assuming that there is sufficient memory and processing power then, as a consequence of using the large model it allows data to be allocated more freely.

As far as I am concerned, this situation does not exhibit laziness but rather a careful, balanced design decision.

Please explain how taking advantage of the available resources makes one a 'lazy dog'.

you would ask that would you not? feel hit?

As usual you are unable to justify your mindless opinions.

Please, when you feel the need to post rubbish could you qualify it with "in my opinion" or something similar to ensure that you don't mislead the inexperienced?

Lazy is: "I can't be bothered to think about which Memory Model to use, so I'll just go for 'Large' and not bother about it"

thanks Andy, a much more eloquent version of "I use large so I do not have to worry about space"

Erik

Guys,
It was not my intention to start this hughe debate. Finally i rolledback, and started again from my last working version and this time i took more care about what was being deleted. This time it worked.

Thanks for the posts and all the help (because I learned about the memory management, honestly).

Best
Dario

I agree with Jack Sprat on this one.

It appears to me that, by implication, Erik is just saying "you use large so you're a lazy dog".

At least he should consider adding the "in my opinion" or some such to some of his postings.

I have used large in a number of projects. There has been very good justification for the decision and the projects have worked.

More than that, I have yet to do the major post release debugging that Erik appears to find so necessary.

Maybe he should spend more time designing a system that is reliable in the first place and less time posting bigoted comments!

you would have read (parapharsing) "a thing that works perfectly till someone provides input that does not follow the standard (to which extent and how, is unknown) and insist that the system accept it"

Maybe he should spend more time designing a system that is reliable in the first place

Rob, please advise: how to design s aystem that will accept 'erroneous' input that you do not know about at the time of design. Do remember "this input is not acceptable" is not an accepatble answer to the customer, you MUST work with the input given.

Looking forward to your reply your solution to the above (you eveidently has one) will be implemented immediately.

Erik

Erik,

The point I am making is that I consider your statement concerning laziness as one that can give less experienced coders the wrong impression. Just because so called experts deem something to be unfashionable, does not mean that it must be avoided. You seem to be putting the the term large into the category that also tries to obliterate the use of goto.

As I stated before, I have written projects using the large model. I have also written projects where that has not been possible so have gone to the small model. More normally I have a hybrid.

When I use the large model, I have the freedom to allocate variables more freely - And I do. Does that make me lazy? The projects I've done to date have proven to be pretty reliable; i.e., they have to work 24/7 for years on end. Some are now approaching the end of their 10 year lifetime. At least one of those is still only its second release.

Now you tell me - Is my lazy approach wrong?

As for designing systems that have erroneous input; yes, we deal with that too. Now, the case may not be as critical as yours, but we do from the outset attempt to detect and record all anomalies. We then attempt to interpret it using all information that was available during the design phase. The phrase we use for this is a common one 'fault tolerance'.

It is, of course, up to you to decide how much time you spend on reading and posting messages on forums. Please just remember that when you post a response, you might get better feedback if you are seen to give advice rather than dictate methods.

Now you tell me - Is my lazy approach wrong?
yes, you, yourself qualify it: "I have the freedom". The purpose of SMALL embedded programming is not that you have 'freedom' but that the code is efficient. I have no reason to doubt that what you refer to 'works' but does it work efficiently or does it just 'work'. The most I have ever saved by efficient design was $1.87 which, obviously would not interest you, Oh, BTW there was 680.000 units made.

As for designing systems that have erroneous input; yes, we deal with that too. Now, the case may not be as critical as yours, but we do from the outset attempt to detect and record all anomalies.
Where do you get the idea that I do not do so, resulting in your statemrnt "Maybe he should spend more time designing a system that is reliable in the first place" which I consider VERY offensive

We then attempt to interpret it using all information that was available during the design phase. The phrase we use for this is a common one 'fault tolerance'.
You NEVER answered my question "how to design a system that can handle things you do not know at the time of design" which your first post indicate that you know how to (an error message (which I do produce) is not satisfactory).

Erik

Ok - I can live with being accused of being lazy by you.

BTW - If you have to update 680.000 sets of firmware out in the field then I guess your support team love you!

I refer to the time you spend offending other people on this (and other) forums.

I could send you a link concerning fault tolerance; but I bet you'd pooh-pooh it!

I have better things to do than cross swords with you!

BTW - If you have to update 680.000 sets of firmware out in the field then I guess your support team love you!
here you make another stupid assumption, who on earth stated that the 'someone, some day after releases attach a unit the do not follow the standards related to THAT project? ALso, if customer x attach unit y that show itself to require handling of the non-standard output, why would you update customer z. Of course, all new units will handle unit y, but existing installations not needing to handle y need no update.

I refer to the time you spend offending other people on this (and other) forums
I spend NO time 'offending people' if someone can not handle that I do not wrap my statements in pink cotton, that is not my problem.

I could send you a link concerning fault tolerance; but I bet you'd pooh-pooh it! I have not discussed 'fault tolerance' MY QUESTION TO YOU has been since my first responce "please tell me hoe to design a system that can handle (no reject BUT CORRECTLY HANDLE) erroneous input that you do not know about at design time. Your first post CLEARLY indicate that you know such a process and I am sure that I am not the onbly one interested.

I have better things to do than cross swords with you!
then why did you start doing so?

Erik