Slashdotted

[Neng-Yu Tu (Tony Tu)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Mosher wrote:

> > Good comments All.
> >
> > Let me inline some answers/explanations.
> >
> > Lothar Behrens wrote:
>> >> Hi,
> >
> > I use this analogy. You write your code in a series of units.
> > you unit test them. Then you do your first integration.
> > You set up your make files and I charge you 50K to hit return. would
you
> > hit the compile button?

Yes, this pretty much true, and you have to hit the button in time, or
so some the package in that make might phase out (like GTA01 PMU
PCF50606), and then you have spent another run of money to enable the
make button hit-able till mass production again.

> > So what's the result if you don't use a waterfall model in
> > hardware development. Whats the cost if you find a requirements defect
> > or a design defect ( glamo? )when you do that prototype run? 50K
> > minimum, plus a redesign. Take the appendix out--perform a glamoectomy?
> > ask Werner about the design implications of that on WIFI. And
> > see my comments below about design and diving into peanut butter.
> >

Werner just replied, maybe he could share more about his painful direct
contact experience with chip vendor  ;)

In hardware, specification/datasheet is not always correct (or always
not correct). People may found a lot interesting component datasheet
with powerful function (the "dream chip") could solve specific design
problem, but when OM direct contact local distributor, following
scenario always happens:

* the chip never put mass production before, or we are the only user
interested that chip, need bare with long lead-time and bad payment deal

* the chip specific model we want not manufactured yet

* the chip specific function not work, or could not work stability, even
the datasheet

* Our quantities (market size) too small, ignore us (this is better
case, we sometimes got already married with some solution then after a
while, vendor ask for divorce  ;)  )

OM might have other internal issues, but external hardware game rules
tough as well. I don't think other company could really open hardware
not only legal issue (design specification with customer/contract with
telcom) but they got Open mind set to solve open hardware related
process issue like OM done before.

> > or capacitive, keyboard or touch.-- ALL signs to me of a lack of
> > appreciation for the complexity and cost involved in doing hardware. I
> > got a hammer your problem must be a nail. I'll give you

And each component we have to verify it's hardware functionality and
compatibility with Open source, and most of time we have to spent extra
resource to build a full GPL'ed driver if vendor only have proprietary
Windows or some binary vendor version.

This also cause the difficulty when verification hardware in time,
because we need build our own driver to test vendor's hardware. Usually
only hardware vendor could have 1 or 2 FAE port driver for us, and with
our latest kernel and open policy (release driver early even before
product manufactured).

> > and energy is spent on this "solution" In the end, marketing looks at
> > that and says "who took the fucking camera out!" that's not an actual
> > example, but you get the idea.

Yes, freeze idea and snapshot it in time is art of products  ;)

>> >> Isn't it possible to also develop hardware collaboratively?
> > In one sense this is trivally true. hardware development is
> > inherently collaborative. But I suppose you mean is it possible
> > to do it in an open fashion. It maybe. But if the requirements process
> > and design process is not rigorous and well defined you end up
> > with expensive implementation problems. And if you don't have team
> > consensus, then it's very problematic. Forking software is easy.
> > Forking hardware is forking hard. The best example I can use is
> > forking ASIC design. You can do a big chip with lots of functionality
> > and then fork off 'defeatured' versions, but that forking needs to
> > be designed in.and it may come with a cost. the same holds true
> > for modular hardware designs. what's easy with lego blocks aint so
> > trivial when it comes to EE design.
> >

As describe above, some of the chip/module may not look pretty real
world as pdf does. And component have supply issue, you never knows you
are the only one buying the really crap or not until you put into mass
production.

Using S3C6410 as example, you never sure which version will put into
mass production for sure or which version will phase out in next 6
months, unless you direct contact with the vendor/distributor, and got
the update in time. It's hard to explain: sorry, your last 6 months
software plan won't work because vendor's business plan suddenly
canceled due to another their BIG customer want go another direction.

seems my reply via other mail account fail, so I use this one instead my
personal as I should ;)

Neng-Yu Tu (Tony Tu)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknZm+QACgkQmV6sZhhBn29qMgCggWnLEVM3PDpbHBeiFlTyEYZU
4aIAniNzMQYhriMBVA7C4HdfNK1cwRkY
=mZwc
-----END PGP SIGNATURE-----