-----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----- _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community