RTX Code Banking

this thread has grown wings, so let me try to get it back to earth.
I assume anyone can agree on the following
1) the '51 can be the right choice for an app requiring a RTOS.
2) the '51 can be the wrong choice for an app requiring a RTOS.
3) the '51 can be the right choice for an app requiring floating point.
4) the '51 can be the wrong choice for an app requiring floating point.
5) the '51 can be the right choice for an app requiring >64k code space.
6) the '51 can be the wrong choice for an app requiring >64k code space.

I hope all agree so far, on that basis:
Some of us see problems from the perspective of 1), 3) and 5), let us call those group a.
Some of us see problems from the perspective of 2), 4) and 6), let us call those group b.

So, since we agree on the 6 points, no group b member can disagree with a group a member as to what is possible
So, since we agree on the 6 points, no group a member can disagree with a group b member as to what is possible

I think group a is willing to accept someone using RTOS, FP and code banking, just because (s)he "wants to" whereas group b tend to question it.

I have no beef with someone using RTOS, FP and code banking in a desperate attempt to save some already designed hardware, but I can not accept that "becuse i want to" is a reasonable design parameter.

Erik

"Some contributors seem unable to understand that there are pros and cons to different solutions to a problem. Those pros and cons vary depending on the person, his/her 1) experience, his/her 2) location, his/her 3) customer, his/her 4) budget and even his/her 5) personal taste etc.

1) Never. (lack of) experience is not an excuse for making something less than optimum.

I meant experience of specific hardware and software rather than lack of general experience.

I DID refer to experience with a given processor."


I've put the context back so that you can see that I was trying to describe the things that need to be taken into account when assessing the best path to take to achieve the optimum result.

What is the optimum result? In a commercial situation this is the result that leaves the vendor happy (best profit/time ratio) and the customer happy (best satisfaction/price ratio). To achieve these two things the developer's familiarity with specific hardware and software *is* one of the things which must be condisered.

"however the cost of sticking to a processor "becuase we have the tools" can be very costly"

Yes, if that processor *really is unsuitable for the job* rather than just being not the obvious choice. If the processor will do the job without making the job difficult to achieve then the cost of buying new tools, learning new tools and learning a new processor will almost certainly outweigh any reasonably minor inconvenience of sticking with the tools you already have and the processor you are already familiar with.

"Can you not just try to understand that someone who, for instance, is familiar and comfortable using an RTOS, may produce a better, more reliable product using one than not using one?

If personal taste was the issue and THAT is not a valid decision factor. Also, (not) using a RTOS for reasons of "comfort" is definitely not engineering applied."

It is not a question of personal taste, it is a question of familiarity. People are comfortable using familiar things, and will tend to produce more reliable product in a shorter timescale using those things. Back in the commercial world for a second: The customer is not interested in some hidden 'engineering beauty'. He wants a product that meets his expectations in terms of functionality, reliability and price. It is our job to develop that product efficiently and economically.

"The point is that you assumed he was a novice before that. It was your initial assumption that he was a novice that prompted you to ask 'why'.

Re this, read the first post"

I'm not with you.

"re "more opinionated contributors", is it not "opinionated" to state that the '51 is the right choice for everything like some do?"

Of course it is. I'm not aware of any opinionated contributors who make that statement.

Then why do you immediately fly to the keyboard every time I state "wrong processor""

Because you say 'wrong processor' when you should say 'maybe the wrong processor'. I never suggest that the 8051 is the right choice for everything, I just point out that you cannot automatically decide that it is the wrong choice every time the infamous three thing are mentioned. As I keep repeating, there are many things that must be taken into account when choosing the hardware and tools for a project. The processor is only one of them.

"if I can get around it, I'll not use floating point unless the processor has HW FP.

That sounds very much as though you'll use the wrong tool for the job until someone starts pulling your toenails out with pliers.

WRONG That sounds very much as though I go for efficient code."

Code only needs to be efficient enough to meet whatever constraints exist in a system. Optimising it beyond that point is a waste of time, refusal to use tools at your disposal which would speed development and most likely reduce the incidence of bugs is futile. A general rule for software development is to write code with maintainability and correctness as the top priorities then optimise any parts which aren't fast enough at the end. This very simplistic process may not always be directly applicable in the small embedded world, but something similar is appropriate: for instance, one might establish whether floating point will be fast enough for the task before coding.

1) see last post in this thread.

Code only needs to be efficient enough.
RTOS: time only need be real enough.

Of course enough is enough, but how do we know what is enough for the OP?

Thus I state "It is NOT enough, unless you can tell me why it is so" and you state "it is enough even without you telling me what you are doing".

Erik

"So, since we agree on the 6 points, no group b member can disagree with a group a member as to what is possible
So, since we agree on the 6 points, no group a member can disagree with a group b member as to what is possible"

If you change the phrase 'is possible' to the phrase 'may be reasonable' then I'll agree with you.