Simon wrote:
-------------------------------
Suppose my code is just below 2k binary using some mathematical formula to calculate the speed or rpm. By using lookup tables the code just goes beyond 2k that forces me to now use 4051. Will it not escalate the real estate in my application and ultimately the production cost?

- - - - - - - - - - - - - - - -
I'll first condense your question:

"aka J, does a 4051 cost more than a 2051?"

ANSWER: Yes.

- - - - - - - - - - - - - - - -
Guidelines to making the decision deal with Relativity (Einstein was after all an assembly language programmer [had to give Bannister something new to whine about]).

What is the cost differential of the 2051 versus the 4051 compared to the total material cost of one unit?

What is the additional develop time cost seeking the non tables approach amortized against the expected number of units produced; ie if you build a bunch, the development cost dwarf in contrast to the expected profits and thus its more worth spending the extra development time. To the contrary, if you are only building a few, the more time you spend developing it (assuming it still sells as well) the smaller your real profits will be. Sometimes its better to finish a design (something engineers are seldom comfortable doing) and move on to the next project.

Customer Perceptions... (someone blindfold Bannister for a second since he doesn't believe). Does the customer really perceive the difference? If not, and you expect to make many units, its better to drive DOWN the single unit cost. The advantages are two-fold. You make more per unit (well DUH) and you have the prime market position incase of a competitive price war.

If your competition looks at your design and realizes you can manufacture it for less money, and they can't figure out how to copy it, then they realize they'd lose if they ever get into a price war with you. There is no better nonverbal message to send a competitor.

That means you have the power for the near term. You can squeeze them out of the market by reducing their profit incentive (not as good an idea as you might first think) or you can happily make the better profits and use that to increase you market share by various marketing means. (Its better to pocket more profit, keep some, invest the rest to increase your market share).

Your customer must do one of several things. Buy you out... Accept a dwindling market share... Convince the customer their product is special in someway... Invest in a new inexpensive design... Invest in a higher feature design... Go out of business... Go into another business.

Other factors should modify your 2051 versus 4051 decision. Prime example, "If I choose to buy the more expensive 4051 for my product, what new possibilities and features could I now include for which customers would be willing to pay more?" That's one of my favorite $$$ design questions. :)

You also have to consider whether the 8051 family is still the right microprocessor for the design. As I've said before, I don't take the microcontroller selection as a given in any design. The 4051 versus 2051 decision is an appropriate time to survey other microcontrollers. Many programmers think its dangerous to switch microcontrollers due to support electronics costs, expertise of personell, and "re-use" of code. This is a BOGUS argument to management to justify simplifying his job by sticking with the familiar. This bogus argument is very successful due to technical ignorance of most management. But that doesn't make it valid. :) [There a topic for Bannister]

In my company, I make that ultimate decision and the only reason I came to 8052.com is that a new design had characteristics that made switching to the 8051 as the best business solution (I hadn't used the 8051 before since 1982). That may not be the case for the next major design.

- - - - - - - - - - - - - - - -
Well Latif, those are some of the things to consider. I've never worked with the 2051 nor the 4051 myself. I have many times over the years had system I was designing that triggered decisions to move up to another micro with more memory.

STORY TIME: In 1985 I was designing a new line of cordless phones at Tandy Electronics that were the first to use an internal microprocessor (for a digital packet command protocol and circuit and radio control). All designs at that time in the marketplace used garage door opener tone chips for communicating between the headset and the base phone and basic teleco circuitry.

I was hired for my experience in digital packet radio. I selected a Texas Instuments microprocessor (odd choice, not well known but perfect for the application).

The product was feature-rich and had to manage many software based features. I coded for a 2K micro and told my idiot boss at the time that we'd need a 4K chip for production due to all the features ideas of mine that he approved.
However, he was convinced that after I wrote the code, he'd give it to Texas Instruments ("the experts") and that they would cut the code down in half. Apparently this was true on many of their Motorola projects. I assured him that it was my expert opinion that he was wrong and he should take my advice since he was paying so much for it.

He didn't listen.

I started every department meeting with the same comment, "I know he thinks we'll be using a 2K chip but we won't. I want everyone to know that my expert opinion is there is no way it can be condensed into 2K." That didn't seem to change his cost analysis so I started hanging a printed hex dump on my door of the 4K block of code with a line denoting the exceeded 2K boundary. My boss didn't think it mattered.

The day finally comes when the Texas Instruments expert shows up to look at the code. After much analysis he removes four bytes near an unused interrupt vector entry point that I chose not to obliterate. Nothing else could he do to compress my code. My boss believed him. :)

We went with the 4K version and since I had mentioned it in meetings to the point of annoyance, I was in the clear. Our Director of Engineering needled my boss for not listening to his own expert.

My boss didn't realize how I had started programming. My first language was APL which those in the know remember as being the most cryptically condensed language. It was known as the only language that could write a program solving the placement of eight queens on a chessboard problem in a single line of code.

After that, I bought and assembled my own home computer (pre Apple days). It was an S100 system with no nonvolatile storage. That meant when I powered it up, I had to enter my programs in hex. To keep this hassle to a minimum, I early on developed all sorts of code compression tricks. :)

If he only understood. heheheeheh
[STORY TIME OVER]

aka j