<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments for Clever Thoughts</title>
	<link>http://cleverthoughts.com/blog</link>
	<description>I hope to have one soon</description>
	<pubDate>Sun, 05 Sep 2010 02:14:34 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>Comment on What industry do I work in? by Jakob Engblom</title>
		<link>http://cleverthoughts.com/blog/?p=44#comment-582</link>
		<dc:creator>Jakob Engblom</dc:creator>
		<pubDate>Mon, 13 Apr 2009 17:15:34 +0000</pubDate>
		<guid>http://cleverthoughts.com/blog/?p=44#comment-582</guid>
		<description>Interesting point... I also consider myself embedded.  Or maybe today more of a "virtual platform tools industry" guy: defining myself by what I sell rather than to whom I sell it... 

When I used to do a lot of core embedded teaching, my definition was two-fold:

1. "A computer that does not look like a computer"

2. "A computing system that interfaces to some environment as a primary function"

Both vague, certainly, but capturing that essence of not just being about computing in the classic CS sense.  Smartphones are a tough call, I would maybe put their UI segment into being non-embedded... but their backends certainly are.</description>
		<content:encoded><![CDATA[<p>Interesting point&#8230; I also consider myself embedded.  Or maybe today more of a &#8220;virtual platform tools industry&#8221; guy: defining myself by what I sell rather than to whom I sell it&#8230; </p>
<p>When I used to do a lot of core embedded teaching, my definition was two-fold:</p>
<p>1. &#8220;A computer that does not look like a computer&#8221;</p>
<p>2. &#8220;A computing system that interfaces to some environment as a primary function&#8221;</p>
<p>Both vague, certainly, but capturing that essence of not just being about computing in the classic CS sense.  Smartphones are a tough call, I would maybe put their UI segment into being non-embedded&#8230; but their backends certainly are.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What industry do I work in? by Grant Martin</title>
		<link>http://cleverthoughts.com/blog/?p=44#comment-230</link>
		<dc:creator>Grant Martin</dc:creator>
		<pubDate>Mon, 30 Mar 2009 18:43:48 +0000</pubDate>
		<guid>http://cleverthoughts.com/blog/?p=44#comment-230</guid>
		<description>Ross, I think while 'embedded' may be a useful technical category it is not really a useful market segmentation category.   (I would also disagree that smart phones of any kind are not embedded systems - since for their base functionality of being a phone, they can rely pretty well on a non-computer classical interface.  I would also suggest that big servers are computers because they can be accessed and are primarily accessed via the traditional interface of keyboard/mouse/screen - just not one they are physically attached to).   All the categories you mention are embedded.  So is a power station considered as a computing device, and many other infrastructure elements too.   However, embedded is way to broad to draw useful conclusions from.   Your taxonomy is good - and then look at how little these categories or market segments have to do with each other in many cases in terms of scale, plugged-in-ed-ness (AKA battery-ness), choice of IP, architectures, etc.   That's why I think we need to focus on the segments rather than on the overall category of 'embedded'.   Ultimately (and I did comment there) Paul was really talking about MIDS and the ARM vs. Intel debates going on there.</description>
		<content:encoded><![CDATA[<p>Ross, I think while &#8216;embedded&#8217; may be a useful technical category it is not really a useful market segmentation category.   (I would also disagree that smart phones of any kind are not embedded systems - since for their base functionality of being a phone, they can rely pretty well on a non-computer classical interface.  I would also suggest that big servers are computers because they can be accessed and are primarily accessed via the traditional interface of keyboard/mouse/screen - just not one they are physically attached to).   All the categories you mention are embedded.  So is a power station considered as a computing device, and many other infrastructure elements too.   However, embedded is way to broad to draw useful conclusions from.   Your taxonomy is good - and then look at how little these categories or market segments have to do with each other in many cases in terms of scale, plugged-in-ed-ness (AKA battery-ness), choice of IP, architectures, etc.   That&#8217;s why I think we need to focus on the segments rather than on the overall category of &#8216;embedded&#8217;.   Ultimately (and I did comment there) Paul was really talking about MIDS and the ARM vs. Intel debates going on there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Functionality without an interface doesn&#8217;t exist. by Gary Stringham</title>
		<link>http://cleverthoughts.com/blog/?p=7#comment-8</link>
		<dc:creator>Gary Stringham</dc:creator>
		<pubDate>Wed, 11 Feb 2009 21:32:44 +0000</pubDate>
		<guid>http://cleverthoughts.com/blog/?p=7#comment-8</guid>
		<description>My newsletters are brief and bounce around from topic to topic so it is difficult to convey where what my overall message is. But even before designing the interface, collaboration must happen between the hardware and firmware teams so that the hardware engineers know the high-level agreement of what that interface should look like.

I (as a firmware engineer) was invited to a meeting where the hardware engineers were going to review and were expecting approval for their high-level plan of what an ASIC should look like. They were surprised at the negative reaction from several firmware engineers because the design did not address several issues. Fortunately, it was very early in the program and course corrections were easily made.

Gary</description>
		<content:encoded><![CDATA[<p>My newsletters are brief and bounce around from topic to topic so it is difficult to convey where what my overall message is. But even before designing the interface, collaboration must happen between the hardware and firmware teams so that the hardware engineers know the high-level agreement of what that interface should look like.</p>
<p>I (as a firmware engineer) was invited to a meeting where the hardware engineers were going to review and were expecting approval for their high-level plan of what an ASIC should look like. They were surprised at the negative reaction from several firmware engineers because the design did not address several issues. Fortunately, it was very early in the program and course corrections were easily made.</p>
<p>Gary</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why do people specify a protocol without publishing the state machines? by Jakob Engblom</title>
		<link>http://cleverthoughts.com/blog/?p=19#comment-2</link>
		<dc:creator>Jakob Engblom</dc:creator>
		<pubDate>Sun, 14 Dec 2008 14:59:42 +0000</pubDate>
		<guid>http://cleverthoughts.com/blog/?p=19#comment-2</guid>
		<description>&lt;blockquote&gt;
Why do people specify a protocol without publishing the state machines?
&lt;/blockquote&gt;

Or you might ask even more pointedly: why do people design a protocol without using a state machine?</description>
		<content:encoded><![CDATA[<blockquote><p>
Why do people specify a protocol without publishing the state machines?
</p></blockquote>
<p>Or you might ask even more pointedly: why do people design a protocol without using a state machine?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
