<?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 tools (if any) help simplify initializing an embedded processor?</title>
	<atom:link href="http://www.embeddedinsights.com/channels/2010/07/07/what-tools-if-any-help-simplify-initializing-an-embedded-processor/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.embeddedinsights.com/channels/2010/07/07/what-tools-if-any-help-simplify-initializing-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: A.P. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/07/what-tools-if-any-help-simplify-initializing-an-embedded-processor/#comment-986</link>
		<dc:creator>A.P. @LI</dc:creator>
		<pubDate>Fri, 09 Jul 2010 20:32:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=195#comment-986</guid>
		<description>I&#039;ve never used one of these tools but then again, I&#039;ve never thought the initialization was a &quot;significant effort&quot;, either.

The only similar tools I&#039;ve ever found useful were the calculators for setting up the bit timing for CAN and even there, they often give you a set of recommendations and you need to choose one based on knowledge and experience and do the initialization yourself.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve never used one of these tools but then again, I&#8217;ve never thought the initialization was a &#8220;significant effort&#8221;, either.</p>
<p>The only similar tools I&#8217;ve ever found useful were the calculators for setting up the bit timing for CAN and even there, they often give you a set of recommendations and you need to choose one based on knowledge and experience and do the initialization yourself.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: S.K. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/07/what-tools-if-any-help-simplify-initializing-an-embedded-processor/#comment-984</link>
		<dc:creator>S.K. @LI</dc:creator>
		<pubDate>Fri, 09 Jul 2010 06:21:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=195#comment-984</guid>
		<description>If you work on small MCUs, the pin limitation only makes the initialization issue more complex, because multiple functions are assigned to a pin, and in many cases the same functions are ALSO available on other pins - but all of them conflict with something else somewhere. The XOR functionality may simply mean that you accidently turn OFF things that you want. You have to RTFM AND the errata notes AND use some experience and common sense to make it all work. The worst part is trying to keep track of all the documentation errors and shortcomings when dealing with electronic documentation. There is nothing quite as useful as a highlighter or post-it note for an electronic document.
The more complex the MCU and the application, the less useful the whiz-bang tools will be!</description>
		<content:encoded><![CDATA[<p>If you work on small MCUs, the pin limitation only makes the initialization issue more complex, because multiple functions are assigned to a pin, and in many cases the same functions are ALSO available on other pins &#8211; but all of them conflict with something else somewhere. The XOR functionality may simply mean that you accidently turn OFF things that you want. You have to RTFM AND the errata notes AND use some experience and common sense to make it all work. The worst part is trying to keep track of all the documentation errors and shortcomings when dealing with electronic documentation. There is nothing quite as useful as a highlighter or post-it note for an electronic document.<br />
The more complex the MCU and the application, the less useful the whiz-bang tools will be!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: D.T. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/07/what-tools-if-any-help-simplify-initializing-an-embedded-processor/#comment-983</link>
		<dc:creator>D.T. @LI</dc:creator>
		<pubDate>Fri, 09 Jul 2010 06:20:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=195#comment-983</guid>
		<description>It seems funny to me that the &quot;wizard kits&quot; are trying to patch a problem which has historical roots (limited available transistors), but which I am tempted to think manufacturers could design away from today.

Now-a-days, the limiting factor is usually pins. I propose we throw out the old model of figuring out just how many different features can/could/are/default-to impacting the pin of interest. Instead, let me simply turn a feature on or off. All the needed pins get enabled or disabled at the same time. An XOR gate will ensure that conflicting features don&#039;t both get turned on.

Since the embedded developers have to think in terms of features being supplied to their customers, the manufacturers could help by designing the uC setup to work in terms of features. They do this to a degree by grouping related registers by address, but they could do more by tying in pin functionality too.

-D.</description>
		<content:encoded><![CDATA[<p>It seems funny to me that the &#8220;wizard kits&#8221; are trying to patch a problem which has historical roots (limited available transistors), but which I am tempted to think manufacturers could design away from today.</p>
<p>Now-a-days, the limiting factor is usually pins. I propose we throw out the old model of figuring out just how many different features can/could/are/default-to impacting the pin of interest. Instead, let me simply turn a feature on or off. All the needed pins get enabled or disabled at the same time. An XOR gate will ensure that conflicting features don&#8217;t both get turned on.</p>
<p>Since the embedded developers have to think in terms of features being supplied to their customers, the manufacturers could help by designing the uC setup to work in terms of features. They do this to a degree by grouping related registers by address, but they could do more by tying in pin functionality too.</p>
<p>-D.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J.L. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/07/what-tools-if-any-help-simplify-initializing-an-embedded-processor/#comment-982</link>
		<dc:creator>J.L. @LI</dc:creator>
		<pubDate>Fri, 09 Jul 2010 06:20:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=195#comment-982</guid>
		<description>Nothing trumps a hardware knowledeable engineer who builds a good set of descriptor header files from the manufacturer&#039;s user manual imho.</description>
		<content:encoded><![CDATA[<p>Nothing trumps a hardware knowledeable engineer who builds a good set of descriptor header files from the manufacturer&#8217;s user manual imho.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J.C. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/07/what-tools-if-any-help-simplify-initializing-an-embedded-processor/#comment-981</link>
		<dc:creator>J.C. @LI</dc:creator>
		<pubDate>Fri, 09 Jul 2010 06:20:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=195#comment-981</guid>
		<description>In my experience the tools are worse than useless. They make it look like initializing the system is as simple as a few mouse clicks. In reality they get something like 90% of the configuration correct. You are then left to figure out the remaining 10% that it did not get right or did not initialize. You spend just as much time pouring over the documentation and checking every bit as if you wrote all the initialization code yourself. I suppose the tool saves a bit of typing but other than that I have not found them to be worth the trouble. I have also only found tools like this for older MCU&#039;s. If you&#039;re using one of the latest and greatest tools like these either do not exist or have so many bugs that you do not want to use them.</description>
		<content:encoded><![CDATA[<p>In my experience the tools are worse than useless. They make it look like initializing the system is as simple as a few mouse clicks. In reality they get something like 90% of the configuration correct. You are then left to figure out the remaining 10% that it did not get right or did not initialize. You spend just as much time pouring over the documentation and checking every bit as if you wrote all the initialization code yourself. I suppose the tool saves a bit of typing but other than that I have not found them to be worth the trouble. I have also only found tools like this for older MCU&#8217;s. If you&#8217;re using one of the latest and greatest tools like these either do not exist or have so many bugs that you do not want to use them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: S.K. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/07/07/what-tools-if-any-help-simplify-initializing-an-embedded-processor/#comment-980</link>
		<dc:creator>S.K. @LI</dc:creator>
		<pubDate>Fri, 09 Jul 2010 06:19:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=195#comment-980</guid>
		<description>Many of the MCU vendors distribute tools similar to what you have described. Some offer I/O interface libraries, too. My experience is that these things are designed to &#039;give great demo&#039;, to allay the fears of managers who have heard of all the sort problems you were trying to avoid - and want to delude themselves into believing that these software tools will simply make the problems vanish in a click.
Yeah, right. Maybe if you have completely trival appliation that uses only a tiny percentage of the MCU capability. If you have anything complex, you need to understand the MCU and its peripherals - and you are better off handing all hardware initialization on your own, and documenting what you are doing. Yes, it is difficult. That is why embedded engineers are so different from &#039;programmers&#039;.
My experience with vendor supplied I/O libraries is that they MAY be a source of usable demonstration code.. but that is all.</description>
		<content:encoded><![CDATA[<p>Many of the MCU vendors distribute tools similar to what you have described. Some offer I/O interface libraries, too. My experience is that these things are designed to &#8216;give great demo&#8217;, to allay the fears of managers who have heard of all the sort problems you were trying to avoid &#8211; and want to delude themselves into believing that these software tools will simply make the problems vanish in a click.<br />
Yeah, right. Maybe if you have completely trival appliation that uses only a tiny percentage of the MCU capability. If you have anything complex, you need to understand the MCU and its peripherals &#8211; and you are better off handing all hardware initialization on your own, and documenting what you are doing. Yes, it is difficult. That is why embedded engineers are so different from &#8216;programmers&#8217;.<br />
My experience with vendor supplied I/O libraries is that they MAY be a source of usable demonstration code.. but that is all.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
