<?xml version='1.0' encoding='UTF-8'?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/'><id>tag:blogger.com,1999:blog-34628062</id><updated>2008-09-23T04:50:14.508-04:00</updated><title type='text'>Stack Overflow</title><subtitle type='html'>I'll be primarily posting on topics related to embedded systems. Being both a hardware and firmware engineer, I'll probably mix it up a bit. As I'm a full time consultant, I'll also take the opportunity to talk about the trials, tribulations and benefits of not knowing where the next pay check comes from.</subtitle><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/'/><link rel='next' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default?start-index=26&amp;max-results=25'/><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://EmbeddedGurus.net/stack-overflow/atom.xml'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>36</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-34628062.post-1118249633268280725</id><published>2008-09-08T19:24:00.001-04:00</published><updated>2008-09-08T19:29:42.998-04:00</updated><title type='text'>Efficient C Tips #4 - Use Speed Optimization</title><summary type='text'>Back in July 2008 I promised that the next blog post would be on why you should use speed optimization instead of size optimization. Well four other posts somehow got in the way - for which I apologize. Anyway, onto the post!

In "Efficient C Tips #2" I made the case for always using full optimization on your released code. Back when I was a lad, the conventional wisdom when it came to </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/1118249633268280725/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=1118249633268280725' title='3 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/1118249633268280725'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/1118249633268280725'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/09/efficient-c-tips-4-use-speed.html' title='Efficient C Tips #4 - Use Speed Optimization'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-6389756337697031865</id><published>2008-09-04T11:59:00.002-04:00</published><updated>2008-09-04T12:19:58.408-04:00</updated><title type='text'>Low cost tools</title><summary type='text'>Like many of you, I subscribe to Jack Ganssle's newsletter (If you don't then you should - go to http://ganssle.com/). In his latest newsletter #164 (alas not yet posted to the web) there is a thread on tools for monitoring serial protocols such as I2C. I was quite interested in this because it so happens I use some of the tools mentioned. What really struck me though was the fact that someone </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/6389756337697031865/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=6389756337697031865' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/6389756337697031865'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/6389756337697031865'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/09/low-cost-tools.html' title='Low cost tools'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-612533200570094509</id><published>2008-08-12T17:41:00.002-04:00</published><updated>2008-08-12T18:10:56.958-04:00</updated><title type='text'>Have you looked at your linker output file recently?</title><summary type='text'>Of all the myriad of files involved in a typical embedded firmware project, probably the two most feared (and yes I do mean feared) are the linker control file (which tells the linker how to link your application) and the linker output file. Today it's the latter which I'll be talking about.

The linker output file tells you a myriad of information about the way your application has been put </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/612533200570094509/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=612533200570094509' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/612533200570094509'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/612533200570094509'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/08/have-you-looked-at-your-linker-output.html' title='Have you looked at your linker output file recently?'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-3108105731604768301</id><published>2008-08-07T20:01:00.002-04:00</published><updated>2008-08-07T20:16:35.177-04:00</updated><title type='text'>Improvements versus Features</title><summary type='text'>I'm taking a slight detour from my usual topics to blather about what I see as an unfortunate trend that is making its way from the PC world to the embedded world. My perception is that as more embedded systems get sophisticated user interfaces, the desire to add features seems inescapable. While I don't see adding features as bad, per se, doing so instead of improving the product is a bad thing.</summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/3108105731604768301/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=3108105731604768301' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/3108105731604768301'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/3108105731604768301'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/08/improvements-versus-features.html' title='Improvements versus Features'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-237993115069370038</id><published>2008-08-01T15:38:00.002-04:00</published><updated>2008-08-01T16:06:32.636-04:00</updated><title type='text'>Efficient C Tips #3 - Avoiding post increment / decrement</title><summary type='text'>It always seems counter intuitive to me, but post increment / decrement operations in C / C++ often result in inefficient code, particularly when de-referencing pointers. For example


for (i = 0, ptr = buffer; i &lt; 8; i++)
{
     *ptr++ = i;
}


This code snippet contains two post increment operations. With most compilers, you'll get better code quality by re-writing it like this:


for (i = 0, </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/237993115069370038/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=237993115069370038' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/237993115069370038'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/237993115069370038'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post.html' title='Efficient C Tips #3 - Avoiding post increment / decrement'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-4417000410449809339</id><published>2008-07-05T09:52:00.002-04:00</published><updated>2008-07-05T11:12:15.165-04:00</updated><title type='text'>Efficient C Tips #2 - Using the optimizer</title><summary type='text'>In my first post on "Efficient C" I talked about how to use the optimal integer data type to achieve the best possible performance. In this post, I'll talk about using the code optimization settings in your compiler to achieve further performance gains.

I assume that if you are reading this, then you are aware that compilers have optimization settings or switches. Invoking these settings usually</summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/4417000410449809339/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=4417000410449809339' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/4417000410449809339'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/4417000410449809339'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/07/efficient-c-tips-2-using-optimizer.html' title='Efficient C Tips #2 - Using the optimizer'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-8027764658677476567</id><published>2008-06-20T21:23:00.002-04:00</published><updated>2008-06-20T21:52:00.566-04:00</updated><title type='text'>Embedded Systems and the Environment</title><summary type='text'>With the recent run up in the price of oil, it seems as if everyone is talking about energy and how to conserve it. For most people, the only impact they can have on the environment is through their own individual actions and choices. Engineers however, are in a different position because at a professional level, the design choices we make can have a profound effect on the environment. If we </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/8027764658677476567/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=8027764658677476567' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/8027764658677476567'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/8027764658677476567'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/06/embedded-systems-and-environment.html' title='Embedded Systems and the Environment'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-8741366162153616979</id><published>2008-06-15T08:10:00.006-04:00</published><updated>2008-06-15T09:15:16.436-04:00</updated><title type='text'>Efficient C Tips #1 - Choosing the correct integer size</title><summary type='text'>From time to time I write articles for Embedded Systems Design magazine. A number of these articles have concentrated on how to write efficient C for an embedded target. Whenever I write these articles I always get emails from people asking me two questions:

1. How did you learn this stuff?
2. Is there somewhere I can go to learn more?

The answer to the first question is a bit long winded and </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/8741366162153616979/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=8741366162153616979' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/8741366162153616979'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/8741366162153616979'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/06/efficient-c-tips-1-choosing-correct.html' title='Efficient C Tips #1 - Choosing the correct integer size'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-8549647352177231509</id><published>2008-06-06T16:06:00.002-04:00</published><updated>2008-06-06T16:40:01.055-04:00</updated><title type='text'>Thoughts on the optimal time to test code</title><summary type='text'>Today I'd like to take on one of the sacred cows of the embedded industry, namely the temporal relationship between coding and testing of the aforementioned code. The conventional wisdom seems to be as follows.

"Write a small piece of code. As soon as possible test the code. Repeat until the task is complete"

I know for many of you, me merely having the temerity to suggest this might be </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/8549647352177231509/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=8549647352177231509' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/8549647352177231509'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/8549647352177231509'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/06/thoughts-on-optimal-time-to-test-code.html' title='Thoughts on the optimal time to test code'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-4736747779809733078</id><published>2008-05-20T15:56:00.002-04:00</published><updated>2008-05-20T16:40:06.569-04:00</updated><title type='text'>visualSTATE</title><summary type='text'>I have been writing this blog now for about 18 months and in reviewing my posts I've noticed that my posts are often critical of technologies, manufacturers and or products. Well today is a first for me, because I'd like to offer my first product endorsement. The endorsement goes to visualSTATE from IAR . I've been using this product for about the same length of time I've had this blog and have </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/4736747779809733078/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=4736747779809733078' title='4 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/4736747779809733078'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/4736747779809733078'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/05/visualstate.html' title='visualSTATE'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-4556668190115943368</id><published>2008-05-11T18:44:00.003-04:00</published><updated>2008-05-11T18:59:20.282-04:00</updated><title type='text'>Integer Log functions</title><summary type='text'>A few months ago I wrote about a very nifty square root function in Jack Crenshaw's book "Math Toolkit for Real-time Programming". As elegant as the square root function is, it pails in comparison to what Crenshaw calls his 'bitlog' function. This is some code that computes the log (to base 2 of course) of an integer - and does it in amazingly few cycles and with amazing accuracy. The code in the</summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/4556668190115943368/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=4556668190115943368' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/4556668190115943368'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/4556668190115943368'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/05/integer-log-functions.html' title='Integer Log functions'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-1565947955488170798</id><published>2008-04-12T17:39:00.003-04:00</published><updated>2008-04-12T18:28:12.268-04:00</updated><title type='text'>IEC60730</title><summary type='text'>Atmel has a very interesting application note on IEC60730 Class B compliance. If you aren't aware of IEC60730, there is a nice introduction here. In a nutshell IEC60730 Class B compliance is a safety standard related to household appliances. Part of IEC60730 requires that one actively monitor that a microcontroller (if one is used) is functioning correctly. This seems to be a reasonable thing to </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/1565947955488170798/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=1565947955488170798' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/1565947955488170798'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/1565947955488170798'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/04/iec60730.html' title='IEC60730'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-3894829517511635741</id><published>2008-02-04T15:38:00.000-05:00</published><updated>2008-02-04T16:17:12.085-05:00</updated><title type='text'>The perils of overloading</title><summary type='text'>This post is coming to you from Sweden - a very fine country that I heartily recommend visiting if you get the chance. (If you're wondering why I'm in Sweden - I'm here on business as one of my clients is located in Gothenburg). Anyway, the fact that I'm in Sweden is relevant to this post, as to get here I had to put myself at the mercies of United Airlines. Now the fact that the flight over here</summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/3894829517511635741/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=3894829517511635741' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/3894829517511635741'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/3894829517511635741'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/02/perils-of-overloading.html' title='The perils of overloading'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-5396689279296869235</id><published>2008-01-27T09:39:00.000-05:00</published><updated>2008-01-27T09:50:59.816-05:00</updated><title type='text'>A new way to tell if something is an embedded system</title><summary type='text'>Periodically someone tries to come up with a definition of an embedded system. For example there is an excellent and oft cited definition here. What got me thinking about this topic is the latest gadget I love to hate - my Verizon Treo phone running Windows mobile. A few years ago, there would have been no doubt that a cell phone was an embedded system. Today, the Treo, the i-Phone etc are all </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/5396689279296869235/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=5396689279296869235' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/5396689279296869235'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/5396689279296869235'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/01/new-way-to-tell-if-something-is.html' title='A new way to tell if something is an embedded system'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-7807421594317876942</id><published>2008-01-18T05:44:00.000-05:00</published><updated>2008-01-18T06:20:18.160-05:00</updated><title type='text'>Electronic Component Footprints</title><summary type='text'>As well as writing code and designing hardware, I also do PCB layout. I started doing this after I discovered it was often faster for me to layout a board myself than to try and convey all my requirements to a board layout person. If you've ever done PCB layout, you'll know that getting information about a device's footprint is a real pain. What you may not know is that this is a major source of </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/7807421594317876942/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=7807421594317876942' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/7807421594317876942'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/7807421594317876942'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/01/electronic-component-footprints.html' title='Electronic Component Footprints'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-7333651425344032029</id><published>2008-01-13T08:48:00.000-05:00</published><updated>2008-01-27T21:26:01.218-05:00</updated><title type='text'>Omniscient Code Generation</title><summary type='text'>Hi Tech Software has recently been making a lot of noise about its "Omniscient Code Generation". In a nutshell, the technology appears to defer code generation until the entire program has been compiled, and then look at everything before generating the final object code. The end result is a dramatically more compact (and presumably faster running) program image. I haven't had a chance to play </summary><link rel='related' href='http://www.htsoft.com/products/OCG.php' title='Omniscient Code Generation'/><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/7333651425344032029/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=7333651425344032029' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/7333651425344032029'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/7333651425344032029'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2008/01/omniscient-code-generation.html' title='Omniscient Code Generation'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-2513660516502687916</id><published>2007-08-29T20:58:00.000-04:00</published><updated>2007-08-29T21:28:25.462-04:00</updated><title type='text'>An unfortunate consequence of a 32-bit world</title><summary type='text'>Back in the bad old days when I was a lad, one learned about microprocessors by programming 8 bit devices in assembly language. In fact I can still remember my first lab assignment - namely to multiply two 8 bit unsigned quantities together to get a 16 bit result (without the use of a hardware multiplier of course). One of the indelible lessons that comes from doing an exercise such as this, is </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/2513660516502687916/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=2513660516502687916' title='6 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/2513660516502687916'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/2513660516502687916'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2007/08/unfortunate-consequence-of-32-bit-world.html' title='An unfortunate consequence of a 32-bit world'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-2745133029857861737</id><published>2007-08-02T19:36:00.000-04:00</published><updated>2007-08-12T22:00:07.202-04:00</updated><title type='text'>Application notes code quality</title><summary type='text'>All manufacturers of microcontrollers publish application notes. Some of these application notes are of course nothing more than gussied up advertising drivel. However, many of these application notes contain useful information that can cut days, and sometimes weeks off a project.
Having read hundreds of these application notes  over the  25 years I've been doing this, I've come to the conclusion</summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/2745133029857861737/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=2745133029857861737' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/2745133029857861737'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/2745133029857861737'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2007/08/application-notes-code-quality.html' title='Application notes code quality'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-8393396047841865818</id><published>2007-06-13T21:22:00.000-04:00</published><updated>2007-06-13T21:37:17.070-04:00</updated><title type='text'>Size matters</title><summary type='text'>Periodically I get printed propaganda from the semiconductor manufacturers touting their latest and greatest ICs. Evidently the marketing folks are convinced that size matters because the size of the IC is almost the first thing they tell you now. A recent example from Maxim has the headline: "Smallest, Most Efficient and Flexible Notebook Fuel-Gauging Solution".

Well size does matter. However, </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/8393396047841865818/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=8393396047841865818' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/8393396047841865818'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/8393396047841865818'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2007/06/size-matters.html' title='Size matters'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-5525445163395768730</id><published>2007-06-04T11:19:00.000-04:00</published><updated>2007-06-09T12:38:30.493-04:00</updated><title type='text'>Understanding Stack Overflow</title><summary type='text'>I suspect that many, if not all bloggers are somewhat narcissistic. In my case it shows through in that I use one of the free services that keeps track of how many visitors I get and what brought them to this blog. Well, it turns out that many of the visitors to this blog get here not because of the brilliance of my writing, but because they did a Google search on "stack overflow" often qualified</summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/5525445163395768730/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=5525445163395768730' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/5525445163395768730'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/5525445163395768730'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2007/06/understanding-stack-overflow.html' title='Understanding Stack Overflow'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-309228071519842695</id><published>2007-05-19T19:50:00.000-04:00</published><updated>2007-05-20T08:23:07.787-04:00</updated><title type='text'>Continued Fractions</title><summary type='text'>Once in a while something happens that makes me realize that techniques that I routinely use are simply not widely known in the embedded world. I had such an epiphany recently concerning continued fractions. If you don't know what these are, then check out this link.

As entertaining as the link is, let me cut to the chase as to why you need to know this technique. In a nutshell, in the embedded </summary><link rel='related' href='http://www.mcs.surrey.ac.uk/Personal/R.Knott/Fibonacci/cfINTRO.html' title='Continued Fractions'/><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/309228071519842695/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=309228071519842695' title='5 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/309228071519842695'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/309228071519842695'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2007/05/continued-fractions.html' title='Continued Fractions'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-1662315989702581807</id><published>2007-05-01T11:45:00.000-04:00</published><updated>2007-05-01T12:28:16.766-04:00</updated><title type='text'>H1-b visas and Economics 101</title><summary type='text'>USA Today has a story today about how 123,000 applications were received within 48 hours of this years H1-b visa lottery being opened on April 1. Given that there are 65,000 visas granted a year, there seems to be a large mismatch between supply and demand. Although the USA Today story talks about some of the sexy positions (Supermodels! Complete with alluring photograph!), the reality is that </summary><link rel='related' href='http://www.usatoday.com/news/washington/2007-04-30-visa-lottery_N.htm' title='H1-b visas and Economics 101'/><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/1662315989702581807/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=1662315989702581807' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/1662315989702581807'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/1662315989702581807'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2007/05/h1-b-visas-and-economics-101.html' title='H1-b visas and Economics 101'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-2372415059017325224</id><published>2007-04-21T20:01:00.000-04:00</published><updated>2007-05-20T08:34:25.752-04:00</updated><title type='text'>Crest factor, Square roots &amp; neat algorithms</title><summary type='text'>I've been programming microcontrollers for about 25 years now - and can count on one hand the number of times I've needed to compute the square root of an integer. This curious drought came to an end recently when I needed to compute the Crest Factor of the line voltage being used to power a product I was designing. (For the uninitiated / rusty out there, Crest Factor is the ratio of the Peak : </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/2372415059017325224/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=2372415059017325224' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/2372415059017325224'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/2372415059017325224'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2007/04/crest-factor-square-roots-neat.html' title='Crest factor, Square roots &amp; neat algorithms'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-117534788709179686</id><published>2007-03-31T09:51:00.000-04:00</published><updated>2007-03-31T10:31:27.103-04:00</updated><title type='text'>Tool Upgrades</title><summary type='text'>As a consultant that does hardware , firmware &amp; software work for my clients, I use a large array of software tools - half a dozen compilers, schematic capture and PCB layout tools, analysis tools as well as the usual gaggle of productivity tools that non-engineers also use. Throw in the tools for running a business and my PC is a regular treasure trove of applications.

With all these tools, the</summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/117534788709179686/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=117534788709179686' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/117534788709179686'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/117534788709179686'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2007/03/tool-upgrades.html' title='Tool Upgrades'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry><entry><id>tag:blogger.com,1999:blog-34628062.post-116614157085575581</id><published>2006-12-14T18:29:00.000-05:00</published><updated>2006-12-23T21:20:05.603-05:00</updated><title type='text'>Wanted - a new performance metric</title><summary type='text'>In the bad old days, the two major performance concerns in CPU selection were whether a CPU had enough processing power and memory to get the job done. Although these are still issues, it's a rare problem that requires more bandwidth and memory than can be provided by the CPU vendors.

By contrast, today, well over half of the systems I work on are battery powered, and so I find the major </summary><link rel='replies' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/116614157085575581/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=34628062&amp;postID=116614157085575581' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/116614157085575581'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/34628062/posts/default/116614157085575581'/><link rel='alternate' type='text/html' href='http://EmbeddedGurus.net/stack-overflow/2006/12/wanted-new-performance-metric.html' title='Wanted - a new performance metric'/><author><name>Nigel Jones</name><uri>http://www.blogger.com/profile/16365149363759317116</uri><email>noreply@blogger.com</email></author></entry></feed>