RTX Code Banking

I think the point is that more powerful processors may still be an order of magnitude more expensive if you're not talking about some ultra-high-volume consumer electronics producth

Digi-key sell Philips ARM processors at qty 1 priced $6 and up

Erik

I think the point is that more powerful processors may still be an order of magnitude more expensive if you're not talking about some ultra-high-volume consumer electronics producth

Digi-key sell Philips ARM processors at qty 1 priced $6 and up

Erik

Digi-key sell Philips ARM processors at qty 1 priced $6 and up

You've missed my point. Even if the more powerful processors sell for HALF the price of the 8051, you can't amortize out the extra development time for learning the architecture unless you sell ALOT of products. For instance, take the following math:

Digi-Key 87C51FB33 @ qty. 1 = $7.76
Digi-Key ARM @ qty. 1 = $6.00 (I don't know ARM stuff, so I'll use your number)

Now assume (since the OP wants to use an RTOS) that this is at least a moderately complex project. Assume that it will take 1000Hrs of programming time for the 8051 architecture with which the OP is familiar. Also assume that the RTOS price for both ARM and 8051 is the same (which might not be true).

Also, we'll assume that the OP is a dynamite embedded systems guy and will suffer only a 10% degradation in efficiency switching to a new processor which means that it will take him 1100 Hrs. to complete the project with ARM.

Let's just pick some reasonable billing rate for an embedded system engineer (I guess $50/Hr is likely low, but I'll be generous for my purposes here). Then, if we assume that the entire system is the same except for the processor selected and compare only incremental costs, we have this:

8051 Cost = (1000 * $50) + ($7.76 / unit)
ARM Cost = (1100 * $50) + ($6 / unit)

So, a break even analysis is as follows:

(1000*50)+(7.76*units) = (1100*50)+(6*units)

which yields units=2840

SO if all of these assumptions are correct (and I think they're reasonable), and even if we assume that the ARM cost is $1.76 less than the cost of the 8051, the 8051 makes the most money for the developers company unless he plans to sell more than 2,840 units over the product life-cycle.

You've missed my point. Even if the more powerful processors sell for HALF the price of the 8051, you can't amortize out the extra development time for learning the architecture unless you sell ALOT of products. ... Now assume ... that this is at least a moderately complex project.

I do not think I have "missed the point".

You are right that there will be "extra development time for learning" but that will be balanced with "less time for implementing and debugging"

In your above example you did not include time for making things behave in time if a '51 was used, which arguably is one of the most difficult debugging tasks. With a combined complexity of RTOS, banking and floating point on a '51, I consider it highly unlikely that timing problems will not pop up.

Erik

I do not think I have "missed the point".

Perhaps not now, but you certainly did when I made this inital suggestion and you kindly quoted me a Digi-Key price for an ARM processor.

You are right that there will be "extra development time for learning" but that will be balanced with "less time for implementing and debugging"

The notion that implementation and debugging on a completely new architecture will be faster than a more concerted effort on a known processor is dubious as best. I'll run with it for you though.

In your above example you did not include time for making things behave in time if a '51 was used, which arguably is one of the most difficult debugging tasks.

A bit more math:

Assume that debugging will be a horrendous chore on the 8051 and he'll have to use a whopping 100Hrs after the project's been "finished" to debug it and get things working. We'll also assume that by some miracle due to the ease-of-use in the new processor, he'll be TWICE as efficient at debugging and it will take only another 50Hrs.

8051 Cost = ((1000 + 100)*50) + (7.76 / unit)
ARM Cost = ((1100 + 50)*50) + (6 / unit)

This yields a break-even point in unit sales of 1420. Also, keep in mind that this continues to run on the assumption that the ARM processors are actually cheaper than the 8051's for a given quantity. I'm not sure if that's true.

The upshot is this: We can keep pulling rather ethereal "efficiency" notions up when it comes to new processors, but eventually someone has to make some hard estimates about times, costs, etc. to make an informed decision. Just basing a choice on a percieved improvement in style is the reason engineers are rarely allowed to make business decisions.

"Even if the more powerful processors sell for HALF the price of the 8051, you can't amortize out the extra development time for learning the architecture unless you sell ALOT of products"

This is a good point.

However, you also have to consider the savings with the more powerful processor from not having to mess about with code banking. And we know that the code banking is causing extra issues - otherwise the original question would never have arisen!!

You're also assuming that the entire cost of learning ARM (or whatever) would have to be amortised over a single project.

Considering ARM specifically, I'd consider that an investment rather than a pure cost: I think knowing both ARM and 8051 would be a definite advantage!
The 8051 must be the most widely available multi-sourced 8-bit architecture; and I think ARM must have a similar position for 32-bits. Definitely a powerful combination.

"However, you also have to consider the savings with the more powerful processor from not having to mess about with code banking. And we know that the code banking is causing extra issues - otherwise the original question would never have arisen!!"

I'll bet I'd be fully au fait with code banking in a fraction of the time it would take me to be up to speed on ARM or similar.

"You're also assuming that the entire cost of learning ARM (or whatever) would have to be amortised over a single project."

If it isn't I wouldn't be too happy to be the customer.

'Here's your product - with a bit of luck I'll know more about the architecture next time I have a go with one of those ARM things. Good luck.'

Considering ARM specifically, I'd consider that an investment rather than a pure cost: I think knowing both ARM and 8051 would be a definite advantage!
The 8051 must be the most widely available multi-sourced 8-bit architecture; and I think ARM must have a similar position for 32-bits. Definitely a powerful combination.

I certainly won't disagree with you there, but I just hate the way this forum ALWAYS turns into a pedantic rant about "The Right Way" to do things. I've seen too many threads to count that go (by your analogy) something like this:

OP: How do I do X with the 8051?

Someone else: Why not make an investment in your company and learn something new?

I highly doubt anyone has come to this forum looking for business advice. Can't we just run on the assumption that unless someone's question puts them across as a complete novice that they know what they're talking about in general and that good decisions have led them to the point where they simply need to overcome some hurdle or another?

"but I just hate the way this forum ALWAYS turns into a pedantic rant about "The Right Way" to do things"

I'm relieved that I'm not alone.

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 experience, his/her location, his/her customer, his/her budget and even his/her personal taste etc.

"Can't we just run on the assumption that unless someone's question puts them across as a complete novice that they know what they're talking about in general and that good decisions have led them to the point where they simply need to overcome some hurdle or another?"

The problem with this is that anybody who asks a question about something that some of the more opinionated contributors think is a complete no-no, such as an RTOS, is then automatically treated as a complete novice. 'Well, they must be, mustn't they? Stands to reason as only a newbie would consider such a thing'.

I wonder if it is obligatory to use an OS and floating point on a 32 bit processor?

"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.
2) OK, it can be an availaibility issue
3) if the customer insist on the "wrong" processor it is the engineers duty to correct him
4) N/A today 32 bits and 8 bits cost abt the same
5) if that influences, fire him

"Can't we just run on the assumption that unless someone's question puts them across as a complete novice that they know what they're talking about in general and that good decisions have led them to the point where they simply need to overcome some hurdle or another?"
re assumption: The OP WAS asked Why? and answered "because I want to" which is typical novice behaviour.

The problem with this is that anybody who asks a question about something that some of the more opinionated contributors think is a complete no-no, such as an RTOS, is then automatically treated as a complete novice. 'Well, they must be, mustn't they? Stands to reason as only a newbie would consider such a thing'.
nobody is treated as a "novice" when they qualify their statements. If you have any experience with todays "novices" you will find that unqualified statements in 98% of the cased means novice. re "more opinionated contributors", is it not "opinionated" to state that the '51 is the right choice for everything like some do?

I doubt Andy or i would have anything to say but "I feel for you" if an OP from Farawayistan stated I can not purchase any other processor than a '51 in my country for less than $100 and I need this which will be better with a RTOS. However "becuase I want to from a novice will not result in "great idea, go ahead".

Again advisingt novices is not just a matter of how to drive, it is also a matter of where to drive and what gas to buy.

I wonder if it is obligatory to use an OS and floating point on a 32 bit processor
if I can get around it, I'll not use floating point unless the processor has HW FP. I would think that for most jobs of the size where 32 bits were required an OS would be a good idea.

Erik

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

YES... IT... IS...

That's been my whole point in the past few math posts. Optimum from an engineering perspective is NOT always optimum from a business perspective. For instance, if a technology is new and disruptive, companies that get the first product out the door that supports it often capture and maintain the highest market share even if the next product is technically superior in every way.

nobody is treated as a "novice" when they qualify their statements.

That's just not true. It wasn't more than a few weeks ago that someone posted a question about how to get the compiler to generate a CALL rather than optimizing it into a JMP. He qualified it by saying basically "I know it's bad, but it has to be that way." No one (except perhaps Stefan) jumped into answer mode. Instead, the messages were along the lines of:

"Why?"
"It doesn't have to be done."
"You must write in assembly."
"You shouldn't have written it that way."
etc.

I can understand if people don't want to answer a question that they think will lead someone into bad territory, but why not just refrain from answering? Instead, there's some motivation that make everyone feel they need to shepherd the flock of 8051 developers into greener pastures. This sort of thing HAS to hurt Keil if new users of their products leave here feeling dejected, unhelped, and insulted. I know that everyone here that answers these posts appreciates the quality of their products and it's a shame to diminish something that should really be improving people's opinions of their tools and the community of developers that use them.

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

"3) if the customer insist on the "wrong" processor it is the engineers duty to correct him"

Oh, wake up to the real world. My duty is to do what the customer wants because he believes he is always right. Sound familiar?

"4) N/A today 32 bits and 8 bits cost abt the same"

There are a lot of considerations other than the cost of the chip that affect budget.

"5) if that influences, fire him"

What planet are you on? 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?

"re assumption: The OP WAS asked Why? and answered "because I want to" which is typical novice behaviour."

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

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

"I would think that for most jobs of the size where 32 bits were required an OS would be a good idea."

It's the type of application that's important, not the size.

"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

"3) if the customer insist on the "wrong" processor it is the engineers duty to correct him"

Oh, wake up to the real world. My duty is to do what the customer wants because he believes he is always right. Sound familiar?
OK rephrase: "if the customer insist on the "wrong" processor it is the engineers duty to try to correct him'

"4) N/A today 32 bits and 8 bits cost abt the same"

There are a lot of considerations other than the cost of the chip that affect budget.
Agreed; however the cost of sticking to a processor "becuase we have the tools" can be very costly

"5) if that influences, fire him"

What planet are you on? 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?</ipersonal 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.

"re assumption: The OP WAS asked Why? and answered "because I want to" which is typical novice behaviour."

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

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

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

"I would think that for most jobs of the size where 32 bits were required an OS would be a good idea."

It's the type of application that's important, not the size.
Agreed maybe "size" is the wrong word; however most applications that require 32 bits are of an "OS type".

"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