1. Home
  2. Embedded Programming
  3. New book coming out

New book coming out

"Expert Guide to Program Management for Developing Embedded Systems", edited by Kim Fowler. Comes out the end of September.

I wrote chapter 8, "The Discipline of System Design".

The way the chapter took shape was interesting: Kim had wanted me to write a chapter that was mostly about applying control theory to systems with feedback control; instead, that subject kept shrinking until it was just an example and a pointer to a book.

What happened was that I kept circling back to "jeeze, there's going to be wet-behind-the-ears college kids reading this, and I'm writing it like the world is an ideal place!"

So the chapter ended up having a lot of material on solving the real- world problems of extracting comprehensive specifications from non- engineers, how to prototype things for business managers so they know where you're going without thinking you're further than you are, how to design and partition complex systems from the ground up, when to buy stuff vs. when to build it, ways to organize your project team so that systems design doesn't get neglected until integration time, and stuff like that.

I really liked working with Kim. He probably wrote about 10% of the material in the chapter, and we kind of pushed each other into writing something that was much better than I would have done had someone just given me the chapter title and said "go!"

formatting link 

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com
Reply to
Tim Wescott
Loading thread data ...

I might buy that.

I wonder if the stuff that you are talking about can be learned from a book, or is it more like skateboarding, where you just have to do it.

People don't pay enough attention to the human factors of electronic design. They think design is scientific or something.

--

John Larkin         Highland Technology, Inc 

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com
Reply to
John Larkin

I don't think all of it can be learned from a book -- some of it sounds like pure BS until you've lived through it.

But there's other material in my chapter that is more concrete and easy to assimilate, like how production volume affects build vs. buy decisions, and some of the commonly used terms at the intersection of finance and engineering like COGS, BOM cost, opportunity cost, NRE, etc.

Someone may read the chapter and realize that yes, you really do want to split your system design into bite-sized chunks, and furthermore that splitting it into chunks that are connected by a pair of power wires and a pair of communications wires is better than splitting it into chunks that are connected by three dozen low-level analog signals lying next to some 500W motor drive leads.

I do think that while a total newbie may not learn it all from the book, they will be prepared to learn it faster once they get on the job and reality slaps them in the face like a week-old cod.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com
Reply to
Tim Wescott

That sounds great, Tim, and what you said above is totally applicable to software-only projects too, and very necessary.

You can't learn to do it perhaps, but you can learn which things you should be doing. If you don't know those, you'll never even attempt them, and can never learn how.

Design is to find the best compromise, including human factors as well as technical ones.

Reply to
Clifford Heath

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.