Embedded Systems Conference
Breaking News
Comments
Newest First | Oldest First | Threaded View
<<   <   Page 3 / 3
jimfordbroadcom
User Rank
Author
re: It always worked before, so you broke it
jimfordbroadcom   5/20/2011 7:02:34 PM
NO RATINGS
Well, I've worked with enough boneheaded software types who didn't know anything about hardware to say that you are the exception, Tim. Embedded engineers who know both are worth their weight in gold, even if boneheaded managers don't realize it. I totally agree with zeeglen; forget the finger-pointing and just figure out what's not working. Sometimes it's both H/W and S/W!

zeeglen
User Rank
Author
re: It always worked before, so you broke it
zeeglen   5/20/2011 6:41:20 PM
NO RATINGS
This reminds me of a time when a watchdog timer would sporadically time out when a processor took too long to execute a command/response sequence on a control bus. This was a new product in both HW and SW, and the late night sessions in the labs were not burdened by "it's a HW fault / no it's a SW fault". We just admitted that nobody knew yet where the fault was and we had to work together to find it. Finally, using an analog scope (digital scopes had not been invented yet) the SW guy and myself saw an event whiz by that the timeout occurred within the 1 second allocated time of the hardware. I took another look at the hardware, a long-chain ripple counter and realized that the guy who designed this had done the stage count based on a complete cycle at the final stage. He forgot that the timeout actually occurred on the rising edge HALFWAY through the cycle. Solution: knife and green wire. Lesson learned: Never assume HW or SW. Test, test, test....

Tombo0
User Rank
Author
re: It always worked before, so you broke it
Tombo0   5/19/2011 1:27:39 PM
NO RATINGS
I deal with this everyday

old account Frank Eory
User Rank
Author
re: It always worked before, so you broke it
old account Frank Eory   5/18/2011 10:35:10 PM
NO RATINGS
Interesting that in a new system -- new hardware and new software -- what ultimately turned out to be a signal integrity problem was blamed on software. "Mechanical and hardware assemblers said it was obviously software." And management simply took their word for it, without any data to back up that claim?

jnissen
User Rank
Author
re: It always worked before, so you broke it
jnissen   5/18/2011 10:20:04 PM
NO RATINGS
Been there done that! Don't care to repeat it!

Dave33
User Rank
Author
re: It always worked before, so you broke it
Dave33   5/18/2011 8:30:24 PM
NO RATINGS
I've written and debugged firmware for many years and I can really relate to this story. Solving problems like those described in the story take time and a very good engineer. Unfortunately there's no way to measure the difficulty of a problem so there's no way to measure the value of the solution. Managers usually just look at how long you took and draw their own conclusions.

<<   <   Page 3 / 3


Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Awesome 3D Electronic Sculptures
Max Maxfield
10 comments
I recently received an email from someone we'll call Martin (because that's his name). Martin's message was short and sweet. In its entirety it read: "You need to see this!"

Jack Ganssle, Embedded.com

Processor Pinups
Jack Ganssle, Embedded.com
4 comments
My wife and I joke about our “adult” magazines. For her, those are the publications about beading. For me, they’re tool catalogs and Fine Woodworking magazine. The latter ...

Rajaram Regupathy, Cypress Semiconductor

Add USB Battery Charging Protocols to an Android-Based Design
Rajaram Regupathy, Cypress Semiconductor
Post a comment
Editorial Note: Excerpted from Unboxing Android: A hands on approach with real world examples, by Rajaram Regupathy, the author takes you through the process incorporating effective power ...

Rich Quinnell

Making the Grade in Industrial Design
Rich Quinnell
16 comments
As every developer knows, there are the paper specifications for a product design, and then there are the real requirements. The paper specs are dry, bland, and rigidly numeric, making ...

Special Video Section
The LT8640 is a 42V, 5A synchronous step-down regulator ...
The LTC2000 high-speed DAC has low noise and excellent ...
How do you protect the load and ensure output continues to ...
General-purpose DACs have applications in instrumentation, ...
Linear Technology demonstrates its latest measurement ...
10:29
Demos from Maxim Integrated at Electronica 2014 show ...
Bosch CEO Stefan Finkbeiner shows off latest combo and ...
STMicroelectronics demoed this simple gesture control ...
Keysight shows you what signals lurk in real-time at 510MHz ...
TE Connectivity's clear-plastic, full-size model car shows ...
Why culture makes Linear Tech a winner.
Recently formed Architects of Modern Power consortium ...
Specially modified Corvette C7 Stingray responds to ex Indy ...
Avago’s ACPL-K30T is the first solid-state driver qualified ...
NXP launches its line of multi-gate, multifunction, ...
Doug Bailey, VP of marketing at Power Integrations, gives a ...
See how to ease software bring-up with DesignWare IP ...
DesignWare IP Prototyping Kits enable fast software ...
This video explores the LT3086, a new member of our LDO+ ...
In today’s modern electronic systems, the need for power ...
Radio
LATEST ARCHIVED BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Flash Poll