Improper fixup

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!

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

Erik,

Be warned - I am not wrapping up my statements in pink cotton.

Two very important points before continuing:

1 - You started the crossing of swords by giving the glib statement concerning the large model
2 - You initially offended me by implying that I am lazy because I, on occasions, use the large model

As far as I am aware, we have never met and you have probably never heard of me; however you decide to give these blanket statements, purporting to be authoritative, that effectively slight my work and people who might work like me.

These are the actions of a bigot.

I'm going to give you a few further things to consider.

You question whether my projects are efficient. My answer is - Yes they are. They work to the required specifications and within the boundaries dictated by the original hardware design.
I suspect that you have a different meaning for the word efficiency - And reading through some of your other posts it would appear that the only person you believe can write efficient code is Eric Malund.

Maybe a paper entitled "Efficiency as defined by Eric Malund" would be worth writing.

I've noticed that you like to give the quantities for a project you have done. Do not confuse quantity of product with quality of product. I have known many products that have sold in bulk, but have been riddled with problems.

In the environment where I work, a fix to firmware after release is considered to be a bug. Our designs attempt to take all conceivable scenarios into account. As I stated previously, we have produced products that work 24/7 for around 10 years of continuous operation. For one of those, one fix (aka bug) we had to identify and cure was considered to be a barely acceptable situation.

You, by your own admission, have to take steps to allow you the opportunity to fix problems after the initial release. In our environment, that would be serious indication of poor quality - And there would be serious questions that would have to be answered.

I hope you now see that you should view developments not just from within your own (narrow) bounds, but also realise that there are other developers who work within different criteria that may have equally valid but diametrically opposed views to your own.

I think that you should re-visit my previous posts, read and understand what is actually being said - Don't be so quick to condemn.

This is the last post from me on the subject. Further discussion with you on the issue would, I think, be like trying to explain to my two year old daughter why she can't have more ice cream before bedtime; i.e., there would be tears and a tantrum.

ps If you want me to provide advice on system design, please consider paying for my consultation services.

You, by your own admission, have to take steps to allow you the opportunity to fix problems after the initial release. In our environment, that would be serious indication of poor quality - And there would be serious questions that would have to be answered.

which can only be based on you NOT reading my posts.

I paraphrase a previous statement "we release a product and there are no problems until some customer buy product x (not ours) and attach it. Analyzing the problem with attaching product x it is found that product x (again not ours) deviate from the standatd in some area. The customer insist that we accept his attaching of product x and, in order to handle that we have to make some changes to the code".

You stated that the above problem was a fault of my design and to that I replied "please advuse how to predict which deviations from the standat=rd an unknown (maybe not even made yet) product x will have"

That you have never answered Instead you keep inmsulting me by stating that such a problem is a fault of my design ("that would be serious indication of poor quality").

If you want me to provide advice on system design, please consider paying for my consultation services.
No, I do not "want you to provide advice on system design" I just want you to either
a) retract the statement that not handling deviations from the standard that were not even existing at design time is a design fault
OR
b) tell me where you bought your crystal ball.
OR
c) qualify your statement.

Erik

PS re 'lazy"
my exact statement was 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"
While I can not see any case whre using 'large' will be justified, there may, iondeed, be one; however, I specifically referred to "so I do not have to worry about space" and, if that is the qualifier, then the user of large is, indeed, a lazy dog.

Erik,

Since you insist, I'll give you one final comment on the subject ...

You appear to be so blinded by your own 'I do efficient' self-belief that you simply ignore the real point which I've been making.

I will not just keep repeating the same statements in different ways just to give you something to whinge about.

Please read my previous postings - You might actually learn something.

ps For some reason, when seeing your posts, the words old dogs and new tricks keep springing to mind! I wonder why?

The end.

During my MS-DOS programming days, I now and then made use of the compact, medium or even large memory models. I understand that this makes me unworthy of continued posting on this site.

The only thing I can say to my defense is that I never used the huge memory model. Just a huge-declared array now and then, when I really needed it.

 * 5A3266E3-82B2-4DCB-8A0C-23BE1236021C walks shamefully home with tail between legs.

You appear to be so blinded by your own 'I do efficient' self-belief
whether I do efficient (which I do) or not is totally irrelevant. The point is that '51 code should be efficient. Of course if the choice of the '51 for a given app is wrong in the first place, then any point about '51 code is moot.

Since you insist, I'll give you one final comment on the subject ...

You keep giving me comments how about an answer!!!

from last post: You stated that the above problem was a fault of my design and to that I replied "please advuse how to predict which deviations from the standat=rd an unknown (maybe not even made yet) product x will have"

That you have never answered Instead you keep inmsulting me by stating that such a problem is a fault of my design ("that would be serious indication of poor quality").

Erik

During my MS-DOS programming days, I now and then made use of the compact, medium or even large memory models. I understand that this makes me unworthy of continued posting on this site.

Not at all, my comments re memory model are strictly related to the '51 where the architecture makes the penalty for choosing the large model many times more severe than for e.g. an x86.

Also an x86 app is typically a "processor" rather than a "controller" app and who gives a hoot if a "process" is complete im 10uS or 10mS. for a "controller' app that, however can be the difference between success and failure.

Erik

During my MS-DOS programming days, I now and then made use of the compact, medium or even large memory models.

Whoops - Now you mention it, so did I.

Oh dear, that must make me a habitual un-optimized coder ;)

The point is that '51 code should be efficient.

Why?

If I have a 9600 baud serial port, it doesn't matter if the code is capable of handling 20k characters/second.

If I need to read a voltage every second, it doesn't matter if the ISR is able to process 8k samples/second or not.

If the application fits in available memory, it doesn't matter if there is 1kB or 10kB code space free.

Only if the application hits (or may hit) a limit is it meaningful to make a decision if it is better to try to squeeze/speed up the code, or switch to faster/larger iron.

The main thing is to write correct code that is also easy to maintain. The need for optimization is more a project-to-project decision, depending on the requirements.

In some cases, the customer may want a new "applet" or feature within a couple of days in a unit with remote update capability. They may want to show off a "cool feature" on a fair.

In some cases, the code may be expected to run unchanged for many years in multi-k products which would require transport to factory if they contain a major error.

In some cases it is ok to switch to a $100 more expensive processor since the end product may cost $10k will all external hardware, making the processor price insignificant.

Oh dear, that must make me a habitual un-optimized coder
not at all, as I replied to Per, what you did with DOS (hopefully) has no bearing on what you do with the '51.
I, for one, do not apply the same practices to an ARM as I do to a '51, e.g. while I consider using a RTOS for the '51 totally ridiculous, I see nothing wrong with using one on an ARM.
I do not recall what I did in my DOS days, but may, very well, be as 'guilty' as you.

Erik

I, for one, do not apply the same practices to an ARM as I do to a '51, e.g. while I consider using a RTOS for the '51 totally ridiculous, I see nothing wrong with using one on an ARM.

On that point, I would certainly agree.