Searching \ for '[EE] Does it take a baseball bat to apply a clue t' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=does+take+baseball
Search entire site for: 'Does it take a baseball bat to apply a clue t'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Does it take a baseball bat to apply a clue t'
2007\02\05@153144 by William Couture

face picon face
Why can't an EE see that a $0.25 design trade off that needs $5000 in
software development for a small run of boards is not a win?

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2007\02\05@155110 by David VanHorn

picon face
On 2/5/07, William Couture <spam_OUTbcoutureTakeThisOuTspamgmail.com> wrote:
>
> Why can't an EE see that a $0.25 design trade off that needs $5000 in
> software development for a small run of boards is not a win?


Some can, some can't  :)

2007\02\05@155341 by Bob Blick

face picon face
> Why can't an EE see that a $0.25 design trade off that needs $5000 in
> software development for a small run of boards is not a win?

That would be know as "penny wise, pound foolish". But did you have a
specific example so that we can all gasp in horror?

Cheerful regards,

Bob


2007\02\05@160129 by James Newton, Host

face picon face
> Why can't an EE see that a $0.25 design trade off that needs
> $5000 in software development for a small run of boards is not a win?
>

Well... There's your problem right there! Basic hardware vs software
conflict. Hatfield's vs. Macoys. Coming from the programming side, I have
seen the other side of that:

How many programmers does it take to screw in a light bulb? None. That's a
hardware problem.

---
James Newton: PICList webmaster/Admin
.....jamesnewtonKILLspamspam@spam@piclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2007\02\05@162141 by David VanHorn

picon face
>
>
> Well... There's your problem right there! Basic hardware vs software
> conflict. Hatfield's vs. Macoys. Coming from the programming side, I have
> seen the other side of that:
>
> How many programmers does it take to screw in a light bulb? None. That's a
> hardware problem.


That's why it's so much fun being the crossover guy.

2007\02\05@162200 by William Couture

face picon face
On 2/5/07, Bob Blick <bblickspamKILLspamsonic.net> wrote:

> > Why can't an EE see that a $0.25 design trade off that needs $5000 in
> > software development for a small run of boards is not a win?
>
> That would be know as "penny wise, pound foolish". But did you have a
> specific example so that we can all gasp in horror?

How about little things?

For example, since he hasn't looked at extern EEPROM availability in
several years, he thinks that he can only get the density he needs as
an I2C part.  Of course, this isn't true.  But he's already designed it.
And built prototypes...

However, he's using an SPI ADC.

Of course, any external bus is fairly slow.  And the system needs to
be doing other things than waiting for communications to finish.  This
means that things have to be interrupt driven.

And, since there are multiple tasks running, each of which wants
access to the ADC and the EEPROM, I need a command / reply
queue for each device.

Of course, the processor can support either SPI or I2C in hardware,
but not both.

So, rather than look around and see "Gee... I can use this chip over
here and run everything from SPI", I now have to bit-bang I2C, with
interrupt drivers and both input and output queues.

As well as implement SPI with hardware support, but also with
interrupt drivers and both input and output queues.

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2007\02\05@162812 by olin piclist

face picon face
William Couture wrote:
> Why can't an EE see that a $0.25 design trade off that needs $5000 in
> software development for a small run of boards is not a win?

Maybe because it's his $.25 and your $5000?  Or that you're greatly
exaggerating whatever it is this content free and pointless knee jerk rant
is about?

I don't know anything about this particular case, but judging from your
emotional fact-free outburst, I'm inclined to believe that you're at fault
more than whatever other party you are complaining about in the absence of
any real facts.  And no, I don't want to hear the facts of this little tiff
since you've already undermined whatever credibility you might have had for
presenting both sides of the case fairly.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\02\05@162941 by William Couture

face picon face
On 2/5/07, James Newton, Host <.....jamesnewtonKILLspamspam.....piclist.com> wrote:
> > Why can't an EE see that a $0.25 design trade off that needs
> > $5000 in software development for a small run of boards is not a win?
> >
>
> Well... There's your problem right there! Basic hardware vs software
> conflict. Hatfield's vs. Macoys. Coming from the programming side, I have
> seen the other side of that:
>
> How many programmers does it take to screw in a light bulb? None. That's a
> hardware problem.

How many Microsoft programmers does it take to change a light bulb?

None:  They just define DARK as the new standard.

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2007\02\05@175121 by Nate Duehr

face
flavicon
face
On 2/5/07, William Couture <EraseMEbcouturespam_OUTspamTakeThisOuTgmail.com> wrote:
> Why can't an EE see that a $0.25 design trade off that needs $5000 in
> software development for a small run of boards is not a win?

Who's budget does each change come from?

Follow the money.  It'll lead you to why the EE doesn't want to do it.  :-)

People with improper incentives will come to illogical budgetary
conclusions, always.  Having a "hardware" budget and a "software"
budget leads to -- improper incentives.

Nate

2007\02\05@190053 by Lucas Korytkowski

flavicon
face
My experience is that unless the EE has software experience, he/she assumes
that it's easy because it's only software.  The design trade-off is physical
cost whereas the software change is never really budgetted properly.

Worse off, take for example, a previous employer believed that the software
was "free" because the programmers were already being paid salary by the
company and the cost was factored into the product (The software department
was labeled the necessary evil by one manager).  The delay in releasing the
product due to software problems was simply the incompetence of the
developer. (Yes, sometimes it is, but other times it's equivalent to trying
to reach for the moon with a step ladder).

Then there's the issue where you have to buy additional software/hardware to
debug the "simple" feature added.  After bloating the code with features and
then adding that last routine either starts to smash the stack or causes
timing issues, or just plain bugs due to major changes last-minute in the
processing chain.

Too many times, at the old company, the team would have a product that
started with ample space and processing horespower until the sales/marketing
department ran around and made a feature list that was approved by upper
management without consulting the software guys.  The EE's received the list
approved it because there were minimal/no hardware changes. Sales then
promised the product to be on-time, and finally dropped the bomb on the
software team.  Management would call the software team whiners that
couldn't do their job properly.  When asked to move to a higher micro they'd
ask why this wasn't brought up before spinning 10K PCB's for the first run!
<-m

I remember an EE/ME contacting me to write firmware for a PIC based product
(low cost low qty) that could generate pure sine waves from 1Hz to 10Mhz
with 0.01Hz resolution, with 1% accuracy.  He was shocked when I mentioned
that a PIC alone couldn't do it.  He told me that I need to look at the
40MHz PIC's, they're 4x faster than the 10MHz sine wave!  I kid you not, I
was called incompetant, etc., because I couldn't do this simple project.  He
even went so far as sending me a excel spreadsheet with the recommended
calculations that the PIC should perform to generate the waveform.



{Original Message removed}

2007\02\05@191642 by William Chops Westfield

face picon face

On Feb 5, 2007, at 12:31 PM, William Couture wrote:

> Why can't an EE see that a $0.25 design trade off that needs $5000 in
> software development for a small run of boards is not a win?

Cause the $0.25 is REAL MONEY, while the $5000 is just the salary
for some programmer who is getting paid for sitting there playing
Quake anyway.

 :-)
BillW

2007\02\05@195259 by Xiaofan Chen

face picon face
On 2/6/07, William Chops Westfield <westfwspamspam_OUTmac.com> wrote:
>
> On Feb 5, 2007, at 12:31 PM, William Couture wrote:
>
> > Why can't an EE see that a $0.25 design trade off that needs $5000 in
> > software development for a small run of boards is not a win?
>
> Cause the $0.25 is REAL MONEY, while the $5000 is just the salary
> for some programmer who is getting paid for sitting there playing
> Quake anyway.

Actually this depends on the quantity of the design, $5000 is a one time
cost but $0.25 is per piece cost. So if the quantity is more than 20k (depending
on the industry, it could still be considered as small run), it makes
sense to invest this $5000.

And some times you need to redo the board, redo the test (eg: CE test)
if you change the hardware, that can be summed up quickly as well.

In this paticular case though, it seems the development in this company
is not good at all. The hardware error should have been found when
reviewing the design. Maybe there is no review process and the
cooperation between hardware and firmware engineer is not good.

2007\02\05@202038 by Lucas Korytkowski

flavicon
face
... And what's wrong with running a benchmark program to make sure the
workstation is running properly?

{Original Message removed}

2007\02\06@035219 by Michael Rigby-Jones

picon face


{Quote hidden}

Well, I'm inclined to belive you are a seriously grumpy old man.  And no...I don't want to hear any excuses or evidence that you are not since you clearly are in my mind.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\02\06@092316 by John Ferrell

face picon face
It sounds a lot like the day I concluded that if a few people did their jobs
right I would not have mine!

John Ferrell    W8CCW
"My Competition is not my enemy"
http://DixieNC.US

{Original Message removed}

2007\02\06@101613 by alan smith

picon face
>From my perspective, anyone that doesn't look at different methods of implementing a design, either in software or hardware, isnt a very good engineer or lacks in experiance. Sounds like your guy is just stuck doing things the same way over and over.  I've inherited designs like that.  If you can get a team that sees the big picture, then things work out alot better.  For the present time, I am in a team of about 10 guys...two management, 1 manufacturing, 1 mechanical, 5 software and me the hardware guy.  On a present proto board we have a myriad of things....uart, SPI, and some other wierd home grown serial.  Mix of memory, FPGA, CPLD, DSP, LCD displays.  I work close with the software guys making sure the hardware works the way they need it...because in the long run, the hardware is going to be a fixed thing, where the software is going to be changing, or be able to change.  But if the hardware isn't going to support the software needs.....what good is it?  I do alot of
firmware as well, so I do see both sides.  As a part time consultant, I see the big picture as well.  I've worked with hardware guys that are so pigion holed in how to do things, that they never see the easier, or cheaper way of doing things but typically those are the guys that never keep up on new technology either.  Makes a big difference in the outcome of a project.

Nate Duehr <RemoveMEnateTakeThisOuTspamnatetech.com> wrote:  On 2/5/07, William Couture wrote:
> Why can't an EE see that a $0.25 design trade off that needs $5000 in
> software development for a small run of boards is not a win?

Who's budget does each change come from?

Follow the money. It'll lead you to why the EE doesn't want to do it. :-)

People with improper incentives will come to illogical budgetary
conclusions, always. Having a "hardware" budget and a "software"
budget leads to -- improper incentives.

Nate

2007\02\06@101614 by alan smith

picon face
>From my perspective, anyone that doesn't look at different methods of implementing a design, either in software or hardware, isnt a very good engineer or lacks in experiance. Sounds like your guy is just stuck doing things the same way over and over.  I've inherited designs like that.  If you can get a team that sees the big picture, then things work out alot better.  For the present time, I am in a team of about 10 guys...two management, 1 manufacturing, 1 mechanical, 5 software and me the hardware guy.  On a present proto board we have a myriad of things....uart, SPI, and some other wierd home grown serial.  Mix of memory, FPGA, CPLD, DSP, LCD displays.  I work close with the software guys making sure the hardware works the way they need it...because in the long run, the hardware is going to be a fixed thing, where the software is going to be changing, or be able to change.  But if the hardware isn't going to support the software needs.....what good is it?  I do alot of
firmware as well, so I do see both sides.  As a part time consultant, I see the big picture as well.  I've worked with hardware guys that are so pigion holed in how to do things, that they never see the easier, or cheaper way of doing things but typically those are the guys that never keep up on new technology either.  Makes a big difference in the outcome of a project.

Nate Duehr <spamBeGonenatespamBeGonespamnatetech.com> wrote:  On 2/5/07, William Couture wrote:
> Why can't an EE see that a $0.25 design trade off that needs $5000 in
> software development for a small run of boards is not a win?

Who's budget does each change come from?

Follow the money. It'll lead you to why the EE doesn't want to do it. :-)

People with improper incentives will come to illogical budgetary
conclusions, always. Having a "hardware" budget and a "software"
budget leads to -- improper incentives.

Nate

2007\02\06@112747 by Herbert Graf

flavicon
face
On Tue, 2007-02-06 at 07:16 -0800, alan smith wrote:
> From my perspective, anyone that doesn't look at different methods
> of implementing a design, either in software or hardware, isnt a very
> good engineer or lacks in experiance.

I'll agree with you that they may not be a good engineer. However, I'm
going to have to disagree with you on the experience point.

Often, people with ALOT of experience will try to solve every problem
the same way. It's the sort of people who aren't interested anymore in
learning anything "new", and simply use the tools and products they are
used to.

It's an easy hole to fall in to. Alot of my hobby projects have used a
PIC. In each case a PIC was one of the better choices. However, limiting
my work to PICs limits me, and may one day result in me making choices
that aren't best for the project at hand. It's for that reason that I
force myself to sometimes use other parts. Aside from seeing how things
are done on the other side of the fence, it keeps my knowledge fresh.

TTYL

2007\02\06@131230 by alan smith

picon face
Yes...I agree with you 100% on that.  Thats whats good about this forum, and others like this, you throw an idea of how YOU might solve the problem, and you get responses back from others....I'd do it this way....this is cheaper....this is more robust...etc..
 
 Part of being an experianced engineer is never overlook the fact others have been there and don't be afraid of asking questions here or of other peers.  I can say I usually learn something new each week by reading this list.

Herbert Graf <TakeThisOuTmailinglist3EraseMEspamspam_OUTfarcite.net> wrote:
 

Often, people with ALOT of experience will try to solve every problem
the same way. It's the sort of people who aren't interested anymore in
learning anything "new", and simply use the tools and products they are
used to.


2007\02\06@132225 by John Chung

picon face
{Quote hidden}

 Experience counts BUT the problem is that most ppl
don't understand why they do so. Using a hammer to
open a can is not a great tool to use. Being ignorant
is also a problem. I can imagine some ppl always using
the latest software or framework out there in the
market BUT the big issue is that DOES it really help?
I must admit that humans are habitual creatures BUT we
must always adapt to the surrounding environment.

John



____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

2007\02\06@141009 by Nate Duehr

face
flavicon
face
On 2/6/07, John Chung <RemoveMEkravnusspamTakeThisOuTyahoo.com> wrote:

>   Experience counts BUT the problem is that most ppl
> don't understand why they do so. Using a hammer to
> open a can is not a great tool to use. Being ignorant
> is also a problem. I can imagine some ppl always using
> the latest software or framework out there in the
> market BUT the big issue is that DOES it really help?
> I must admit that humans are habitual creatures BUT we
> must always adapt to the surrounding environment.

All the more reason NOT to buy Windows Vista?  (Ducking....)

Nate

2007\02\06@145346 by David VanHorn

picon face
>
> All the more reason NOT to buy Windows Vista?  (Ducking....)
>
> Nate



Well, I can tell you that the production version is a lot more stable than
the beta.
However it's still a resource pig, and not as responsive as XP pro on the
same machine.
But it is prettier.

2007\02\06@153344 by Vitaliy

flavicon
face
Nate Duehr wrote:
>>   Experience counts BUT the problem is that most ppl
>> don't understand why they do so. Using a hammer to
>> open a can is not a great tool to use. Being ignorant
>> is also a problem. I can imagine some ppl always using
>> the latest software or framework out there in the
>> market BUT the big issue is that DOES it really help?
>> I must admit that humans are habitual creatures BUT we
>> must always adapt to the surrounding environment.
>
> All the more reason NOT to buy Windows Vista?  (Ducking....)

I know I won't, anytime soon. :) I think it's a good idea in general to
stick to the tools that work, and to switch only if there is a compelling
reason to do so. Windows XP is pretty stable, and gets the work done -- so
why bother with a new OS that Microsoft will spend a good couple of years
removing the bugs out of?

IMHO. ;)

Vitaliy

2007\02\06@170307 by Aaron

picon face


William Couture wrote:

>How about little things?
>
>For example, since he hasn't looked at extern EEPROM availability in
>several years, he thinks that he can only get the density he needs as
>an I2C part.  Of course, this isn't true.  But he's already designed it.
>And built prototypes...
>  
>


Why don't you do a design review before building prototypes?

Aaron

2007\02\07@102451 by William Couture

face picon face
On 2/6/07, Aaron <aaron.groupsEraseMEspam.....gmail.com> wrote:

> >How about little things?
> >
> >For example, since he hasn't looked at extern EEPROM availability in
> >several years, he thinks that he can only get the density he needs as
> >an I2C part.  Of course, this isn't true.  But he's already designed it.
> >And built prototypes...
>
> Why don't you do a design review before building prototypes?

Because this is a small company.  The designed was "reviewed"
by another EE-type (we have one "real" EE, and one "sort-of"
EE/Technician), but not by either software engineer.

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2007\02\07@112501 by Michael Rigby-Jones

picon face


{Quote hidden}

Does your company have a defined product development process?  

Although you should try to attend final design reviews, they are not the correct stage in the process to be looking for dumb design decisions.  All this kind of thing should have been sorted much earlier on, and your input should be required at any stage that potentialy affects the software developement.

Regards

Mike


=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\02\07@170613 by Gerhard Fiedler

picon face
William Couture wrote:

>> Why don't you do a design review before building prototypes?
>
> Because this is a small company.  The designed was "reviewed" by another
> EE-type (we have one "real" EE, and one "sort-of" EE/Technician), but
> not by either software engineer.

Because it is a small company, it should be easy (easier than in a big
company) to make sure the software engineer who's to lead the
firmware/software development gets involved, at least in a review of the
electronics design, no? Beats a baseball bat as solution, I'd say...

Communication is not everything, but everything is nothing without it, or
so the saying goes :)

Gerhard

2007\02\07@171319 by Herbert Graf

flavicon
face
On Wed, 2007-02-07 at 20:05 -0200, Gerhard Fiedler wrote:
> William Couture wrote:
>
> >> Why don't you do a design review before building prototypes?
> >
> > Because this is a small company.  The designed was "reviewed" by another
> > EE-type (we have one "real" EE, and one "sort-of" EE/Technician), but
> > not by either software engineer.
>
> Because it is a small company, it should be easy (easier than in a big
> company) to make sure the software engineer who's to lead the
> firmware/software development gets involved, at least in a review of the
> electronics design, no? Beats a baseball bat as solution, I'd say...
>
> Communication is not everything, but everything is nothing without it, or
> so the saying goes :)

I'd have to agree. While it "sucks" that the hardware designer designed
the way they did, you can't really blame them. They obviously weren't
aware that the choices they were making would have such a huge negative
impact on the software side.

IMHO, based on what has been presented, I believe whoever is in charge
of the engineering effort (the boss who the software and hardware
engineer are under, not necessarily their direct boss) should have made
more of an effort to consult both sides as to the best way to go.

Hindsight is 20/20, but blaming the hardware designer seems a little
off.

TTYL

2007\02\07@225046 by William Chops Westfield

face picon face

On Feb 7, 2007, at 2:05 PM, Gerhard Fiedler wrote:

> Because it is a small company, it should be easy (easier than in
> a big company) to make sure the software engineer who's to lead
> the firmware/software development gets involved, at least in a
> review of the electronics design, no?

That's for sure.  When cisco was small, there was (for several
years) a policy that hardware and software engineers would be
seated "mixed" in their cubicals, with every HW engineer sitting
next to a SW engineer (and vis versa.)  It seemed to work pretty
well as long as most of the projects were essentially one-person
efforts (Myu designs the IGS and Chris does the firmware bringup),
and fell apart when a given piece of HW started to require its
own TEAM just for the HW.  Now (that we're huge) we have lovely
snafus like the built-in modem without the ability to be hung up,
completely due to some HW designer not bothering to talk to the
SW engineers that understood the other half of the problem. :-(
Sounds very similar to problem "the other Bill" is having.

BillW

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...