How do you select the right processor?

I think that asking an experienced professional engineer how they choose the right processor is about the same as asking a cancer specialist how to choose the right treatment !!

It's like pretty much any professional skill - you need some aptitude and at least 10,000 hours of practice - a wiki page is no substitute.

Having said that there are some very general comments:

You should consider the total project cost (for low to medium volumes this often means that the cost of the processor is unimportant). This will enable you to set a budget for choosing the processor. (This step is frequently informal and that's fine for many projects but if you have to think about long term availability, safety critical, large volumes then perhaps you should set a formal budget.)

You need to make a list of "must haves" - and in real life these range from very technical (eg on chip 16 bit ADC) to the near political (eg must complete the job in 2 weeks and the only available engineer knows processor X really well .......).

If your "must have" requirements give you a short list it may be quite easy to pick the part - more likely there will be thousands of parts or none at all that meet your initial requirements (this will depend on the skill with which the requirements were defined).

So I think I have shown that choosing a processor is not a simple matter of ticking some boxes.

To address your specific points:

In low volumes familiarity with processor and/or tools may be a very significant cost factor but my personal opinion is that it is often overplayed.

It is usually (but there will be exceptions) a bad idea to change parts between prototyping and manufacture.

The value of future proofing is totally project dependent - if you are building a one off piece of test gear there is no value at all - if there is a planned 'family' of products it may be the key to commercial viability.

Hi all,

I'm new to the group, but not new to processors or processor selection.  My experience has been as the hardware guy that has to "implement" the processor that gets chosen...usually by committee, and then support it in production!  I think I like Ghamble's idea of a "wiki" document, and so I'd like to try and summarize Michaels (obviously very knowledgeable) comments above:

1) Make a list of "must haves"...this list should be complete enough to tell you if any particular processor is suitable.

2) Consider the cost...of the project and of prospective processors with respect to it.

3) Look at the intended life span of the product...will the selected processor be available that long?

4) Try not to plan to change parts between development and manufacture...It's just asking for surprises.

Personally my preference is to place significant emphasis on the life span issues, as I've had several designs "bitten" by discontinued processors.  It is quite common in electronics that a particular part gets discontinued, but in the case of a processor it can be a product killer...and very disappointing.

I have converted this "summary" and expanded the commentary some in the "documents" section, here:

http://www.element-14.com/community/docs/DOC-21182

I think that is what someone suggested...:-)

-Dave

Hi all,

I'm new to the group, but not new to processors or processor selection.  My experience has been as the hardware guy that has to "implement" the processor that gets chosen...usually by committee, and then support it in production!  I think I like Ghamble's idea of a "wiki" document, and so I'd like to try and summarize Michaels (obviously very knowledgeable) comments above:

1) Make a list of "must haves"...this list should be complete enough to tell you if any particular processor is suitable.

2) Consider the cost...of the project and of prospective processors with respect to it.

3) Look at the intended life span of the product...will the selected processor be available that long?

4) Try not to plan to change parts between development and manufacture...It's just asking for surprises.

Personally my preference is to place significant emphasis on the life span issues, as I've had several designs "bitten" by discontinued processors.  It is quite common in electronics that a particular part gets discontinued, but in the case of a processor it can be a product killer...and very disappointing.

I have converted this "summary" and expanded the commentary some in the "documents" section, here:

http://www.element-14.com/community/docs/DOC-21182

I think that is what someone suggested...:-)

-Dave

Hi Dave,

This is just the sort of thing I was hoping to get, those criteria that are based on real experience, the "Rule of thumb" that people use, whether generic or even application and processor specific, everyone has their way and that's what I'm interested in discussing, to see what if any commonality there is, and if this can then generate some sound advice in a doc, great!

I have been thinking about the wording of my original question a lot, and I accept it probably wasn't the best piece of writing I have ever done, so perhaps I can clarify some points.

When I said "Do you start with a more powerful processor for prototyping and then downsize later?"

I was really thinking more in terms of a family of processors that may have for example different memory sizes, or if IP core in an FPGA, going for a high gate / pin count variant, and then coming down to a more cost effective version, not switching between completely different families or suppliers.

The questions were supposed to be examples, rather than specific questions to answer, and the emphasis was really intended to be really strongly on the YOU, part of the question, what are your criteria, what works for you, what's your experience, because there is now quite a lot experience floating round in the ether, with knowledge of all kinds of applications.

Despite my rather poor initial question, Dave seemed to pick up what I was trying to get at, so my thanks go to him for that.

I agree with what has been said.

I would add is that the culture and history has a major

influence regarding what is "right".

If a lab uses a uC from a given vendor they will tend to stay

with that vendor and toolchain if posssible.  You can burn

a lot of engineering time learning new toolchains.

Hi Dave,

I truly liked your answer, and i believe your contribution is totally engaging. I believe that many people have the same concerns and the summary document will definitly help.

I am sure somehow that some experts like yourself could possibly bring more content to the document, will you be gathering more input and guidance from others expert within this community and update your document?

I was wondering also if there is a way to make this document more visible to user that haven't join the group.

This was just a thought...

Hi Everyone,

Thanks, but please remember: I only summarized Michael's response. This is not "my" document...I've gone ahead and tried to incorporate Dan's suggestion because I think he's right, tools are pretty important.  But I'd like to suggest that rather than me paraphrase what they say, a better way is if Dan and Michael add to the document themselves...

Maybe it's more like a bunch of chefs "cooking up" a recipe than a doctor curing cancer.  I can help write down "Michael's recipe", but there's some other "ingredients" Dan might use a little more or less of, or he might even mix things up differently...there's really not one right way, and Michael and Dan can each communicate their own way of doing it much better than I can tell you how they do it...

In fact, perhaps what's needed here is just to encourage Everyone to go ahead and feel free to pitch in and edit too.  If you see some "ingredients" of selecting a processor we maybe haven't sprinkled in yet, just toss 'em on in the "pot"!  That's the "wiki" part.  I'll trust Ghamble to correct me if I'm mistaken here, but everyone at E-14 gets  an edit button for this document when they're logged in...right?

So please, don't worry in the least about "my" document or "his" recipe, just keep throwing stuff in to suit your own taste (perhaps being careful we don't make it too "salty" )  If it doesn't "taste right" afterward, things can easily be taken back out of the "mix" again...I guess maybe the analogy actually falls apart there.  But, when a bunch of cooks all agree on "add a pinch of this" or "it's done when it looks like thus-and-so" it's usually a pretty safe bet folks will like what ends up on their plate...

Hi Dave,

Yep the doc should be open to everyone.

Hey Dave,

Yeah, I like your document. But sometimes also engineers' experience is also included in the checklist, and also whether we have already say a programmer or debugger from a certain manufacturer.

-Erya-