Embedded Systems Conference
Breaking News
Comments
Newest First | Oldest First | Threaded View
Page 1 / 3   >   >>
perl_geek
User Rank
Author
Extended understanding
perl_geek   10/26/2015 3:23:10 PM
NO RATINGS
Most of us work in some sort of chain, (or tower, if you prefer), producing work that depends on others, and is in turn depended on. (E.g. business or functional logic encoded in software that depends on hardware to work. I've always felt it desirable to have at least an outline understanding of the neighbouring fields. Hardware people need to know something about physics and chemistry on one side, and software on the other. Similarly, software types need to know a bit of hardware and some business, and so it goes on.

TFCSD
User Rank
Author
It always worked before, so you broke it: 2015 Update
TFCSD   10/25/2015 4:40:32 AM
NO RATINGS
Sweet. Ten years later after I worked for a certain solution “froward” company that my EEtimes story was based. In a recent 2015 interview one of those special people, who is no longer with said company, told an interviewer something that was strange and likely not true, if what was said was really said and not redacted. I asked for clarification from the interviewer about what was said or if they even had the right person and the interviewers are being tight lipped about who spewed. Just goes to show that if you do the right thing for an employer and they ultimately benefited, the ex-sycophants still years later whine that their obtuse behinds which they roasted in the fire for years was scorched and was my fault because I came by and pointed out they may be happier turning around. Makes me wonder how many other of my interviews/jobs these people have ruined over ten years.

The Gen
User Rank
Author
re: It always worked before, so you broke it
The Gen   6/16/2013 8:28:11 AM
NO RATINGS
I worked for a company for 12 years designing a range of fibre optic switches. (check out the spelling of fibre!) My bit was the opto-mechanics. I can sympathise deeply with the sentiments in these posts. Guys, I feel your pain. One of the posts earlier mentioned that it is obvious when mechanics isn't working, but not so software and electronics. In the fibre switch, the mechanics was small and delicate, and small mechanical disturbances (thermal, vibration, electrical noise) could make a difference but it wasn't obvious by observation. When there was a problem the blame was assigned thus:- 1. it's a mechanical problem, the mirror is in the wrong place (it was once many years previously but not on the five plus subsequent problems) 2. Right, the mechanics is OK, must be an electrical problem 3. Right the electrics is OK, must be a software problem Usually the 'head in charge would decide on what the root cause was and waste time and money trying to fix something that wasn't broken. The three disciplines had enough respect for each other to get on and sort the problem (eventually when the management "help" had evaporated when the solution was looking intractable) Oh, and I relate to the story above about the saw project that was estimated to take 2 months scheduled to be done in one month and quoted to the customer as 2 weeks. I don't work for that company any more :-)

oster
User Rank
Author
re: It always worked before, so you broke it
oster   11/3/2012 12:35:08 AM
NO RATINGS
The solution seems to be that SW guys need to learn more HW skills and vice versa. It's the ones that are at ease straddling disciplines that bridge the divide and I've certainly seen this in action.

DutchUncle
User Rank
Author
re: It always worked before, so you broke it
DutchUncle   6/10/2011 12:29:50 PM
NO RATINGS
Fresh real-life example: A few weeks ago I released code that worked exactly as expected on prototype hardware. When used on the next board-spin of prototypes, it didn't work, which of course meant it was a software fault. Yesterday it was proven that not only was the circuit changed, but a wrong part had been used on the dozen proto builds, so it wasn't even the proper changed circuit. Put in the right part, and the software works again. Gee, what a concept.

jsandjs
User Rank
Author
re: It always worked before, so you broke it
jsandjs   6/9/2011 11:03:27 PM
NO RATINGS
This is the second story about the hardware induced noise I read here. Since noise mixed in a signal is so common and most of the time it is random, problems happen here and there somehow give a hint, even not strong and clear. A specific software in general will hardly produce random troubles here and there.

zeeglen
User Rank
Author
re: It always worked before, so you broke it
zeeglen   5/29/2011 4:53:51 PM
NO RATINGS
Depends on what is being tested and debugged.

t.alex
User Rank
Author
re: It always worked before, so you broke it
t.alex   5/29/2011 1:07:22 PM
NO RATINGS
Isn't it true most of the time the sw guy do the test and debugging instead of the hardware?

t.alex
User Rank
Author
re: It always worked before, so you broke it
t.alex   5/29/2011 1:06:15 PM
NO RATINGS
It is important the sw guy pick up some hardware debugging to prove themselves 'innocent' :)

LiketoBike
User Rank
Author
re: It always worked before, so you broke it
LiketoBike   5/27/2011 6:26:01 PM
NO RATINGS
Software and hardware are often trained by management to blame each other :-) (As in: when the "real" mission to create and ship and SUCCEED [as a team] is derailed into the "fake" mission to grab credit and avoid fault, this blame-game usually results...)

Page 1 / 3   >   >>


Radio
LATEST ARCHIVED BROADCAST
As data rates begin to move beyond 25 Gbps channels, new problems arise. Getting to 50 Gbps channels might not be possible with the traditional NRZ (2-level) signaling. PAM4 lets data rates double with only a small increase in channel bandwidth by sending two bits per symbol. But, it brings new measurement and analysis problems. Signal integrity sage Ransom Stephens will explain how PAM4 differs from NRZ and what to expect in design, measurement, and signal analysis.

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
Special Video Section
The LTC®6363 is a low power, low noise, fully differential ...
Vincent Ching, applications engineer at Avago Technologies, ...
The LT®6375 is a unity-gain difference amplifier which ...
The LTC®4015 is a complete synchronous buck controller/ ...
10:35
The LTC®2983 measures a wide variety of temperature sensors ...
The LTC®3886 is a dual PolyPhase DC/DC synchronous ...
The LTC®2348-18 is an 18-bit, low noise 8-channel ...
The LT®3042 is a high performance low dropout linear ...
Chwan-Jye Foo (C.J Foo), product marketing manager for ...
The LT®3752/LT3752-1 are current mode PWM controllers ...
LED lighting is an important feature in today’s and future ...
Active balancing of series connected battery stacks exists ...
After a four-year absence, Infineon returns to Mobile World ...
A laptop’s 65-watt adapter can be made 6 times smaller and ...
An industry network should have device and data security at ...
The LTC2975 is a four-channel PMBus Power System Manager ...
In this video, a new high speed CMOS output comparator ...
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 ...