<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: What matters most when choosing an embedded processor?</title>
	<atom:link href="http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/</link>
	<description>Shedding Light on the Hidden World of Embedded Systems</description>
	<lastBuildDate>Mon, 28 Jul 2014 16:18:37 -0400</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: L.R. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1950</link>
		<dc:creator>L.R. @ LI</dc:creator>
		<pubDate>Sun, 12 Sep 2010 22:34:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1950</guid>
		<description>R., you are rigjt for medim volume products (100 to 1,000 per year), where the cost of development can easily overtake the cost of a processor if the development tools are of poor quality or unframiliar to the developers. In those cases the processor cost will not be at the top of your considerations.
If however the expecte production volume is in the 100,000 range (or more), the equation changes, and it may make sense to use the cheapest processor even if you have to write your own tools to support it, or write it all in assembly - any extra R&amp;D expenditure will be compensated y the savings in cost of parts.</description>
		<content:encoded><![CDATA[<p>R., you are rigjt for medim volume products (100 to 1,000 per year), where the cost of development can easily overtake the cost of a processor if the development tools are of poor quality or unframiliar to the developers. In those cases the processor cost will not be at the top of your considerations.<br />
If however the expecte production volume is in the 100,000 range (or more), the equation changes, and it may make sense to use the cheapest processor even if you have to write your own tools to support it, or write it all in assembly &#8211; any extra R&amp;D expenditure will be compensated y the savings in cost of parts.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: R.K. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1949</link>
		<dc:creator>R.K. @ LI</dc:creator>
		<pubDate>Sun, 12 Sep 2010 22:33:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1949</guid>
		<description>In desending order of priority

Application to be implemented
Speed required for application
Features available does it support the application
and obviously Price</description>
		<content:encoded><![CDATA[<p>In desending order of priority</p>
<p>Application to be implemented<br />
Speed required for application<br />
Features available does it support the application<br />
and obviously Price</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: L.R. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1818</link>
		<dc:creator>L.R. @ LI</dc:creator>
		<pubDate>Fri, 03 Sep 2010 03:46:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1818</guid>
		<description>J. is right, except that one should not assume that all of their requirements can be met by any one specific product, where a certain cost range is one of these requirements. Hence in order to make a smart decision, one must be prepared to compromise, and to do that, the requirements must be given a weight or priority, and then every specific product being considered can be graded on how well it answers the requirements as a set, with the more important requirements contributting a bigger portion of this grade. I beleive there is in fact a whole theoretical basis on how to make decisions, which can be readily applied to this field too (as well as buying a house if one takes out the emotional component): http://en.wikipedia.org/wiki/Decision_theory</description>
		<content:encoded><![CDATA[<p>J. is right, except that one should not assume that all of their requirements can be met by any one specific product, where a certain cost range is one of these requirements. Hence in order to make a smart decision, one must be prepared to compromise, and to do that, the requirements must be given a weight or priority, and then every specific product being considered can be graded on how well it answers the requirements as a set, with the more important requirements contributting a bigger portion of this grade. I beleive there is in fact a whole theoretical basis on how to make decisions, which can be readily applied to this field too (as well as buying a house if one takes out the emotional component): <a href="http://en.wikipedia.org/wiki/Decision_theory" rel="nofollow">http://en.wikipedia.org/wiki/Decision_theory</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J.G. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1817</link>
		<dc:creator>J.G. @ LI</dc:creator>
		<pubDate>Fri, 03 Sep 2010 03:45:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1817</guid>
		<description>The only simple answer to this question is: How well does it meet the requirements of the project? As you can see, that&#039;s another question. The reason for that is that there isn&#039;t any one factor to be considered.

Like buying a house, you&#039;ll need to list a number of needs and wants. Then you&#039;ll look at the available options then select the one that meets all the needs and as many of the wants as possible.</description>
		<content:encoded><![CDATA[<p>The only simple answer to this question is: How well does it meet the requirements of the project? As you can see, that&#8217;s another question. The reason for that is that there isn&#8217;t any one factor to be considered.</p>
<p>Like buying a house, you&#8217;ll need to list a number of needs and wants. Then you&#8217;ll look at the available options then select the one that meets all the needs and as many of the wants as possible.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: P.V. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1787</link>
		<dc:creator>P.V. @ LI</dc:creator>
		<pubDate>Thu, 02 Sep 2010 15:05:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1787</guid>
		<description>Lots of interesting comments so here is a small consideration. If you are using C in an embedded system with just a single prom space for non-volatile storage and limited RAM you my want to consider a non-Harvard architecture. This facilitates non-volatile data access more readily in C. I have found that architectures for which the code and data spaces are addressed differently engender special handling for access in C which tend to make the code less portable.</description>
		<content:encoded><![CDATA[<p>Lots of interesting comments so here is a small consideration. If you are using C in an embedded system with just a single prom space for non-volatile storage and limited RAM you my want to consider a non-Harvard architecture. This facilitates non-volatile data access more readily in C. I have found that architectures for which the code and data spaces are addressed differently engender special handling for access in C which tend to make the code less portable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: W.S. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1784</link>
		<dc:creator>W.S. @ LI</dc:creator>
		<pubDate>Wed, 01 Sep 2010 03:46:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1784</guid>
		<description>Key things to consider:
#1 Tool support. If you work in C (and are porting existing C code) don&#039;t even think about choosing a part that doesn&#039;t have a fully compliant C compiler. Otherwise, you&#039;ll have a huge engineering job to port the code and re-write. There are certain major vendors that fail miserably in this regard. Also look at tool effeciency. Some tools are good and effecient. Others, well, are not.

#2 Development support. Make sure you have a good, reliable emulator chain available. This makes debugging much simpler. Without this, your software development will be very, very difficult.

#3 Long term support. Is the part going to be here in the future? Is there an upgrade path. Yes, you may be able to get by with a small part now, but if your design exhibits feature creep (which all embedded products do) can you easily expand to a larger part?

#4 Environmental concerns. Clock frequency, temperature ranges, I/O, RAM/ROM. All of those things are important. While it may be possible to run a chip faster, does a faster crystal cause EMC issues? Does the chip have a PLL if you need a faster clock speed but can not have a faster crystal? How about ESD protection? Is your part susceptible to ESD problems? All parts are in theory, but some manage this better.</description>
		<content:encoded><![CDATA[<p>Key things to consider:<br />
#1 Tool support. If you work in C (and are porting existing C code) don&#8217;t even think about choosing a part that doesn&#8217;t have a fully compliant C compiler. Otherwise, you&#8217;ll have a huge engineering job to port the code and re-write. There are certain major vendors that fail miserably in this regard. Also look at tool effeciency. Some tools are good and effecient. Others, well, are not.</p>
<p>#2 Development support. Make sure you have a good, reliable emulator chain available. This makes debugging much simpler. Without this, your software development will be very, very difficult.</p>
<p>#3 Long term support. Is the part going to be here in the future? Is there an upgrade path. Yes, you may be able to get by with a small part now, but if your design exhibits feature creep (which all embedded products do) can you easily expand to a larger part?</p>
<p>#4 Environmental concerns. Clock frequency, temperature ranges, I/O, RAM/ROM. All of those things are important. While it may be possible to run a chip faster, does a faster crystal cause EMC issues? Does the chip have a PLL if you need a faster clock speed but can not have a faster crystal? How about ESD protection? Is your part susceptible to ESD problems? All parts are in theory, but some manage this better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: R.A. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1783</link>
		<dc:creator>R.A. @ LI</dc:creator>
		<pubDate>Tue, 31 Aug 2010 15:01:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1783</guid>
		<description>&quot;A product that I currently work on was designed over 15 years ago. The embedded processor chosen at the time is no longer available and yet the product is still being manufactured and sold. &quot;

It is certainly an important factor. 

Longevity of design can be aided through selection of operating system as well. The O/S can abstract the processor, allowing the hardware to be re-engineered with current components, and minimal changes to the application code (assuming that the code is also well designed and implemented).</description>
		<content:encoded><![CDATA[<p>&#8220;A product that I currently work on was designed over 15 years ago. The embedded processor chosen at the time is no longer available and yet the product is still being manufactured and sold. &#8221;</p>
<p>It is certainly an important factor. </p>
<p>Longevity of design can be aided through selection of operating system as well. The O/S can abstract the processor, allowing the hardware to be re-engineered with current components, and minimal changes to the application code (assuming that the code is also well designed and implemented).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: D.M. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1782</link>
		<dc:creator>D.M. @ LI</dc:creator>
		<pubDate>Tue, 31 Aug 2010 15:01:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1782</guid>
		<description>Availability into the future is something that also needs due consideration.

A product that I currently work on was designed over 15 years ago. The embedded processor chosen at the time is no longer available and yet the product is still being manufactured and sold.</description>
		<content:encoded><![CDATA[<p>Availability into the future is something that also needs due consideration.</p>
<p>A product that I currently work on was designed over 15 years ago. The embedded processor chosen at the time is no longer available and yet the product is still being manufactured and sold.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: R.M. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1640</link>
		<dc:creator>R.M. @ LI</dc:creator>
		<pubDate>Sat, 28 Aug 2010 02:36:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1640</guid>
		<description>EMC performance, current draw, lows, power modes, the selection (or lack) of on board peripherals, what the rest of the family looks like for both upgrades and downgrades, the forecast end of life, ... the list goes on and on.</description>
		<content:encoded><![CDATA[<p>EMC performance, current draw, lows, power modes, the selection (or lack) of on board peripherals, what the rest of the family looks like for both upgrades and downgrades, the forecast end of life, &#8230; the list goes on and on.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: B.P. @ LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/14/what-matters-most-when-choosing-an-embedded-processor/#comment-1639</link>
		<dc:creator>B.P. @ LI</dc:creator>
		<pubDate>Sat, 28 Aug 2010 02:36:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=203#comment-1639</guid>
		<description>&quot; What matters most when choosing an embedded processor?&quot; The most important thing when choosing any component, is that you can get it. If you can&#039;t get it nothing else really maters. Lots of parts are on Allocation these days.</description>
		<content:encoded><![CDATA[<p>&#8221; What matters most when choosing an embedded processor?&#8221; The most important thing when choosing any component, is that you can get it. If you can&#8217;t get it nothing else really maters. Lots of parts are on Allocation these days.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
