|
Embedded Muse 191- March 1, 2010 Copyright 2010 TGG
You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com.
EDITOR: Jack Ganssle, jack@ganssle.com
Contents:
- Editor's Notes
- Quotes and Thoughts
- Industry Outlook
- Book Review
- Tools and Tips
- Jobs!
- Joke for the Week
- About The Embedded Muse
Editor's Notes
Are you happy with your bug rates? If not, what are you doing about it? Are you asked to do more with less? Deliver faster, with more features? What action are you taking to achieve those goals?
In fact it IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm .
The NY Times had a good article about writing resumes:
http://www.nytimes.com/2010/02/28/jobs/28search.html?8dpc . Also see my thoughts here: https://www.ganssle.com/sellurself.htm .
Quotes and Thoughts
David Pinas sent this: Software is getting slower more rapidly than hardware becomes faster. Niklaus Wirth, who attributed it to Martin Reiser.
Industry Outlook
How are we weathering the recession?
The salary survey, which is woefully late but will run in the next issue of the Muse, indicates only a 0.5% unemployment rate. I'm sure that data is skewed, but even if off by an order of magnitude is only half the national rate. Raises are down, but in the US averaged 2% last year, and most developers expect a 2% hike this year.
In the automotive arena we're hearing (ad nauseum) that high-end cars incorporate some 100 million lines of code in their 70 to 100 microprocessors. Frost and Sullivan recently predicted growth to 200-300 million in the next few years. That aligns with other estimates I've seen that suggests the firmware content of most systems doubles every 10 months to two years.
And it sure suggests a desperate need for embedded engineers.
bcc Research predicts healthy growth in the embedded industry. They claim the market should have a compound annual growth rate of 4.1% to 2013. That, of course, is for the end-products we produce. In this economy a 4% CAGR is pretty healthy.
My sense is that hiring is less moribund than in 2009.
Gartner predicts chip sales to increase 19.9% in 2010, reaching $276 billion, with growth to continue at least into 2014.
I'm told that pre-registrations for the April San Jose Embedded Systems Conference are double those for last year.
ARM announced that in the last quarter 1 billion ARM processors were shipped, a new record. iSuppli expects that to grow to 5 billion/year in 2010. Tempering this 2008 prediction, ARM's 2009 sales were off 10% over the previous year. One does wonder how much revenue a part like NXP's Cortex-M0 LPC1100, at $0.65 each in quantity, can yield for ARM.
I remain fairly pessimistic for the economic outlook of the developed world over the long term. But for now it does seem that in our industry, at least, things are looking up.
What do you think?
Book Review - Real-Time Embedded Multithreading Using ThreadX and MIPS
And there is a lot of code in the book - very well written code, with excellent documentation both in the comments and in the accompanying prose.
Early on the author claims that an important characteristic of embedded systems is that they are temporally deterministic. I disagree, though sure wish this were true. Most preemptive multitasking systems are not deterministic, which is a scary but very real failing in our industry. But later he back peddles a bit and suggests one insures that each task is deterministic.
The book is very well organized with initial chapters giving high-level overviews of RTOS concepts, and later ones drilling down deeper. His descriptions of the nature and use of mutexes, messaging and other resources are absolutely clear and quite complete. The one exception is counting semaphores, as he doesn't explain *why* one would use them.
Two chapters introduce the MIPS processor, with the second devoted to exceptions and how those are important to ThreadX users. And that's pretty much all that's MIPS-specific in this volume; the rest applies to any CPU.
Chapter 7 describes threads. As you'd expect there's lots of techie talk about managing threads. He goes further and offers useful advice on how to design a thread and the pitfalls one should watch out for.
The final chapter is an excellent description of the process of designing a complete multithreading application, starting with a clear description of the problem, analysis, design and finally code.
The book packs a lot of info into short, easily-read chapters. The included CD has code for all of the examples, plus a 362 page PDF of the ThreadX User Guide.
Yes, the book is very ThreadX-centric, and no, it's not particularly MIPSy. Most of the concepts are easily generalizable to any RTOS. If you'd like to learn about using an RTOS, this volume is for you. If you're getting into ThreadX, you'll find it invaluable.
Tools and Tips
Without a reasonable backup strategy you might as well junk the computer. I find Centered Systems' $29.95 Second Copy (www.secondcopy.com) keeps the data safe.
As a certified old-timer I have never caved into Microsoft's evil My Documents default directory structure, and save all important files in c:\docs. Second Copy lets you create various backup profiles, and one of those automatically copies that directory to an external hard drive every evening. But first I have it run a DOS script that backs up the other machines here into a subdirectory under c:\docs, so everything important in this office is mirrored to a Western Digital Passport drive. Automatically.
I keep the same directory structure on the laptop, and use Second Copy to keep c:\docs identical on both machines. And another profile copies everything to a Thumb drive.
The program only copies files that have changed, and you can have it keep as many old copies of files as you'd like in an archive directory.
Highly recommended.
Joke for the Week
Another from Vicky Hansen:
Glory, glory, halleluiah, glory, glory, halleluiah,
Glory, glory, halleluiah, we all still have jobs
Our firmware is the best and it makes the hardware run
We are globally dispersed but we can still work as one
Our people are in Texas, Colorado, and Brazil
We're in India, New Jersey, and California still
We plan, design, we code and test and still we have some fun
Our skill keeps marching on
Glory, glory, halleluiah, glory, glory, halleluiah,
Glory, glory, halleluiah, we all still have jobs
The bits and bytes keep piling up into coherency
We add commands, enhance our code on each emergency
Our work may be invisible but it always meets the needs
We make sure that the chips behave and memory is freed
We keep track of the I/O, temperature and CDCs
Our skill keeps marching on
Glory, glory, halleluiah, glory, glory, halleluiah,
Glory, glory, halleluiah, we all still have jobs
Our management may panic but we always make the goal
We even tweaked the system so it will use less coal
They wonder if a feature can be added, yes it could
We make it so the system does exactly what it should
The bugs are squashed so all of our systems can be sold
Our skill keeps marching on
Glory, glory, halleluiah, glory, glory, halleluiah,
Glory, glory, halleluiah, we all still have jobs
About The Embedded Muse
The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. can take now to improve firmware quality and decrease development time.