HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
REGISTER   |   LOGIN   |   HELP
Blogs
Electronic News & Comment

9 Things Engineers Need to Know About Embedded Development

NO RATINGS
1 saves
< Previous Page 2 / 5 Next >
View Comments: Oldest First|Newest First|Threaded View
<<  <  Page 2/2
JimT@Future-Product-Innovations
User Rank
Blogger
One more bullet, #10: Agency Approvals take longer.
JimT@Future-Product-Innovations   7/25/2012 1:33:19 PM
NO RATINGS
One additional thought:  when a project takes any COTS module and places it onto a product host PCB, any Agency Approvals (FCC, UL, CE, etc.) are streamlined because the COTS module already "grand-fathers" the host product's approval process.  On the contrary, embedding the solution eliminates that short-cut and you must face the full scrutiny of any Agency.  Plan on adding at least another 8-12 weeks before approvals are granted.

ttemple
User Rank
Platinum
Re: Development time
ttemple   7/25/2012 2:36:04 PM
NO RATINGS
RogerD,

I couldn't have said it better.  I completely agree that the smallest possible software team will usually minimize development time.

I have seen a one man "team" design, debug, and program a very high performance FPGA/DSP/Microcontroller based motion control and data acquisition system in about a year (hardware and software).  I doubt if a whole team could have done it in five years.  A government funded team would probably never have finished it.  I'm not saying that anybody could have done what he did, but he was the right man for the job, and adding more people to the mix would have only slowed him down.

Unless a software project can be very distinctly divided and conquered, the fewer programmers the better.

Charles Murray
User Rank
Blogger
Re: Why?
Charles Murray   7/25/2012 7:20:10 PM
NO RATINGS
ChasChas: It can't really be boiled down any further than to say that writing and de-bugging code is a very slow, tedious, complex process and many products have hundreds of thousands, or even over a million, lines of code. As RogerD accurately points out here, the numbers cited here refer more to larger projects. Still, the stories I've heard seem to indicate that many, many teams don't have a full appreciation for the scale of the software portion, and that misunderstanding (or lack of understanding) gets them into trouble. As for your reference to eccentric behavior by programmers, we'll need some deeper insight from some of our readers on that one.   

ChasChas
User Rank
Gold
Re: Why?
ChasChas   7/25/2012 8:59:33 PM
NO RATINGS
 

Thanks, Charles. I thought I could get you to use the word "convoluted".

bobjengr
User Rank
Platinum
Embedded development reality check
bobjengr   7/26/2012 6:22:13 PM
NO RATINGS
Great article Charles.  I am one of those mechanical types and have very limited experience with software, embedded or otherwise.  This field fascinates me and I am certainly appreciative of your article highlighting the difficulties with the technology.  Your comments about the time-consuming efforts and costs to produce the code were revelations.  Revelations.   My experience in programming is with C++, Pascal and Visual Basic, which are basically "learning-types" of software.  If I may, I write an educational blog published through WordPress; i.e. www.cielotech/wordpress.com.  Would you mind giving me permission to reference your article in an upcoming blog discussing embedded systems?  I think my readers would also be fascinated by the subject.  Many thanks, Bob J.

ErrantMule
User Rank
Iron
Masses of asses
ErrantMule   7/30/2012 6:08:55 PM
NO RATINGS
"The average programmer writes about 200 lines of code per month. At that rate, a staff of 50 would need 100 months -- more than eight years -- to write a million lines of code."

Knowing the author is simplifying for the sake of brevity, it may not be obvious to some that total lines of 'good' project code per time unit is never linear in the number of people devoted to the task.  There is definitely a point of diminishing returns, and a point at which adding more people does the project a disservice by making the overall task unwieldy, if not outright unmanageable.  Microsoft used to blame IBM for ruining OS2 because non-technical managers relied on the 'masses of asses' principle as a means of (erroneously) getting it done faster, then ran roughshod over the coders when the simple arithmetic did not prove axiomatic.  The people who were a party to the overall 'vision' at the outset can become disconnected from what is actually emerging, as new people are added at the back end to expedite certain tasks or address new requirements.  Moreover, the newcomers may have a completely different view of what the goal posts look like.  If you start out with a few people who all know 'C' well then, for example, marketing decides the thing needs Android, bringing in Java experts who've never seen a pointer in their life may cause the team to split into two camps, and they may end up competing more often than working together.

Regarding operating systems, I agree they should be avoided wherever prudent and possible.  For some projects however, there's no getting away from it.  For example, if you're targeting a high end MPU like a Cortex A8 or above, you NEED an OS else you'll get bogged down in the minutiae of writing drivers etc.  The first rule of thumb is you should abandon all rules of thumb.  The second might be if you're using a MCU like a MSP430 or a Cortex-M0 to M3, you can probably get away without an OS.  As stated in the article, concurrency beyond all but the simplest of requirements dictates you need an OS to manage access to inter-process, shared objects.

Thanks to the author for making a software guy feel important for an afternoon.  It's time to go home so my teenager can ruthlessly burst that delicate bubble.

 

Charles Murray
User Rank
Blogger
Re: Embedded development reality check
Charles Murray   8/17/2012 6:31:54 PM
NO RATINGS
Sorry I didn't see your comment earlier, bobjengr. Please feel free to reference the article. I appreciate your comments.  

bobjengr
User Rank
Platinum
Re: Embedded development reality check
bobjengr   8/18/2012 1:38:40 PM
NO RATINGS
Many thanks Charles.  I will send you the write-up as soon as I finish.  Again, great article.  Bob

<<  <  Page 2/2
Partner Zone
More Blogs from Electronic News & Comment
There's good news and bad news regarding the sub-systems of today's late-model vehicles. The good news is that new engines and transmissions are more trouble-free than in the past. The bad news is that the infotainment and DVD players are still prone to be "buggy."
Government fines and recalls are heightening the need for automakers to adopt more safety standards and software verification techniques, experts at EE Live said this week.
The coming era of self-driving cars will call for a major change in engineering culture, an embedded design expert said this week.
For decades, the corporate path to the chief executive's office has often passed through engineering. Automotive, computer, electronics, and oil companies have frequently drawn their leaders from the engineering ranks.
The Texas Motor Speedway has flipped the switch on a high-definition video board that uses 14 million LEDs, weighs more than 200,000 pounds, and is 80% larger than the Dallas Cowboys' world-renowned scoreboard.
Design News Webinar Series
3/27/2014 11:00 a.m. California / 2:00 p.m. New York / 7:00 p.m. London
2/27/2014 11:00 a.m. California / 2:00 p.m. New York / 7:00 p.m. London
12/18/2013 Available On Demand
11/20/2013 Available On Demand
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Apr 21 - 25, Creating & Testing Your First RTOS Application Using MQX
SEMESTERS: 1  |  2  |  3  |  4  |  5


Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.
Next Class: April 29 - Day 1
Sponsored by maxon precision motors
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service