Well, some things *are* harder to get in certain places. I worked on a project many years ago with a firm in UK. We spent a fair bit of time sorting out export restrictions, pricing differences, etc. E.g., they enjoyed commenting about how much MORE a pound was worth than a dollar (1.8 at the time, IIRC) -- yet, we quickly found that our off-the-shelf prices for components were in almost exactly the inverse proportion: i.e., a 5 dollar part cost them 5 pounds! So much for the value of the pound! :>
(there's a big difference when a product "costs" 80% more!)
This is the appeal for a (assembled) "board supplier". He doesn't add much value OTHER THAN stuffing the parts onto the board. But, this can be a HUGE gain for the tinkerer: he doesn't have to try to purchase the components in "Qty 1" *and* doesn't have to screw around with a BGA, etc.
Exactly. If a bare board supplier has to design the device, he's probably not going to do it (without a higher profit margin). OTOH, if all he has to do is shoot some foils and mark up the "board" to reflect his "warehousing" costs, it might be appealing. The same applies to a guy taking those boards, stuffing them and testing them for resale. Comparatively little "investment". And, teh fact that anyone else can undertake a similar activity (i.e., selling bare or stuffed boards) keeps pressure on their prices.
I think Theo's point is well made in that software is more easily "adopted" -- because the bar is so low for entry! You can buy a complete PC for less money than I can buy a good soldering workstation. And, you can write *horrid* code and still get it to work -- whereas if you've got solder bridges across a dozen pins on a device, there's no way in hell it's going to work!
I have friends who can't solder fine pitch devices because of ET. Others who can't *see* this level of detail, unaided. (and some who can't remember which component they have in their left hand :< )
But, you can accommodate a fair bit of this *in* your design if you consider it from the start. E.g., things that are likely to need replacement should be *easy* to replace (this is contrary to modern manufacturing practices wherein the entire device is
*scrapped* if anything breaks -- even "common wear items")
"Educational value" goes beyond the possibility of "high rate of failure". E.g., simply *studying* a design doesn't carry any "risk of failure" -- you aren't trying to "build" it! Yet, you can learn from observing something *known* to work! Whether that is hardware or software.
[In *theory*, that's what AppNotes are supposed to do -- but, many seem to have glaring errors or even seem to just be hypothetical designs that clearly have never been fabricated. I think most of these problems come from documenting the "app" after-the-fact. If, instead, you published the actual "manufacturing" data, then there is less room for errors to creep in.]
Similarly, you can choose to *lift* portions of a design without undertaking the entire design.
Finally, you may simply learn from the *ideas* presented in the design. E.g., (cassette) Walkman -> (disk) iPod -> (FLASH) PMP
-> (app) smartphone PMP.
See above. *My* goal is entirely different than what *you* might do given the availability of such a finished design (i.e., how you would use it, how MUCH of it you would implement, etc.).
My goal in *publishing* is to encourage people to think in these other directions and explore these other techniques for "doing things". Techniques that might have seemed ludicrous in the 20th century...
Personally, I use the Vulcan Mind Meld. Unfortunately, a lot of people get nervous when I try to lay my hands on their face and forehead (I think the pointy ears gives them the heebie-jeebies!)
Intending no offense, I'm just not wanting to go down that road. I'd already planned on doing all of this, myself (on my own schedule, finances, etc.). My buddy's offer was unexpected and a possible bright spot -- but, primarily because I knew there would be no "overhead" involved (we know each other well enough that he would already know all the "unspoken" issues that are important to me; and I know him well enough to know what I could expect in his finished design).
The FOSS/FOSH aspect is what makes it less feasible. It's too much effort to ask for as a freebie. And, the only reason I would want to *pay* for his services is if I *couldn't* do the design or if I was facing a schedule deadline. Neither is (currently) the case.
I've another friend/colleague that might be more interested in the "build boards" aspect (as a way of compensating him for his effort). But, I don't know what his current commitments look like.
That's a wonderful, altruistic attitude which is guaranteed to bite you in the ass. Legally, you are better off making no effort at all than making an effort that might be deemed "insufficient".
In most places, there are different standards for DIY kits than for preassembled products. However, if you try to make the kit "safer" (for some definition) than is minimally required for the intended audience, that will be used as proof that you knew the kit was unsafe, and the lawyers will argue that you were negligent in distributing it or, at least, negligent in determining the intended audience. The fact that the user grossly overestimated his/her ability may not be enough to save you.
Yes. However, it is impossible to prevent idiots from injuring themselves. If your design is in any way involved, it's better that the idiot is killed rather than injured: in most cases, it's far cheaper to have to compensate the next of kin than to have to compensate the primary injured party.
If this sounds callous, so be it: so too is the law - callous, capricious and generally unappreciative. Regardless of your best efforts, there exists an unreasonable judge or jury that will think you should have anticipated that your gizmo would be shoved into an automobile tail pipe, tossed out of a plane, flushed down the toilet, eaten by a ferret or used as an anal probe.
[In the context of this group, you reasonably should have anticipated that someone might try to plug your 6v, battery operated gizmo directly into a 480v 3-phase line. It's obvious.]
Paraphrasing _War Games_: "The only good move is not to play!"
When I was a kid growing up in New England, I was puzzled by the "rules" regarding shoveling snow! No sidewalks in our neighborhood and the letter carriers *walked* their routes (mail was/is delivered to your door).
If your driveway/walkway was unshoveled, the mailman did not have to deliver your mail. I.e., incentive for you to shovel it!
OTOH, if it *was* shoveled and he slipped and fell ("black ice", etc.) you were *liable*.
OTOOH, if it was NOT shoveled and he injured himself, it was
*his* problem (more or less) -- he could *see* that there was clearly a hazzard and he undertook the effort that he was not
*obligated* to undertake!
I worked in the "front office" at a major tool manufacturer. Many of the stories that sound like "urban legends" are, in fact, true. People are amazingly creative (esp with hand tools!) in how they will misuse things. And, it's never *their* fault.
[Amusing to think of life in the garden of Eden: Adam suing The Creator because he opted to use a *rock* as a hammer and it chipped sending a shard into his eye...]
When I was *really* young, I had a crystal radio in my bedroom. I had built it from a kit (what, 5 components??). Of course, I soon wanted it to be *louder* than it was with that dinky earplug.
"Hmmm.... two wires from the radio (antenna and gnd). Two slots in that electric outlet. Hell, this is a no-brainer!"
(and, it *was*! Lots of magic smoke accompanied by silence from the earplug)
Yep, it's interweb survival. They can come up with a counter-example to any statement you make. People pick up on that to demonstrate your incompetence and drag you off topic into a never-ending downward spiral. If you don't give 'em a handle, it's harder to drag you and more interesting discussion happens before you're drowned out.
Man, I've been spending too much time in linux newsgroups...
Let me say what I meant. People who don't pay attention to user needs f*ck things up... universally.
23 years in industry cleaning up after people who didn't think it thru before they made a big mess and moved up before it hit the fan. Once you have all the tasks identified and the PERT chart in place, you can figger that it won't take more than 2 or 3 times as long as the plan. ;-)
Finding someone who knows how to do something is far easier than finding someone who knows WHAT to do.
Considerably harder to do when your goal is something for your own personal use! (unless you drop dead along the way ;-)
This is *exactly* where FOSS/FOSH can win -- *if* you start with the right "vision"/design AND cast enough stuff in concrete that folks can't drag it off in other ("wrong") directions easily!
If, instead, you just say, "I wanna do X" and aren't competent at "doing X" *and* drag in other folks who are equally incompetent or, who *may* be competent but you refuse to listen to them "because you'd have to throw away too much" (of what you've DONE WRONG), then you end up with a lot of wasted man-hours and little *practical* to show for it!
Having something "finished" represents a shitload of inertia to future directions a project can take. Awful hard to convince others that "this is all wrong, we should start over" when it actually *works*!
Makes one wish the Darwin Awards actually were handed out in a yearly, globally televised award presentation ceremony, doesn't it? Think about it: the only awards show where the "In Memoriam" segment can tactfully be accompanied by a full-throttle rendition of "Here come the clowns!", and where no winner will ever try to make an excessively long thank-you speech. TV stations should love it!
Anyway, your experience only goes to show (yet again) that there really is not, nor will there ever be, any such thing as a "fool-proof design". Nature has at least a one-gigayear head start over all of us in that race. Today's fools are thus effectively perfect. There's still a slim chance one might beat that much evolution by luck, but never by design. Nobody is _that_ intelligent.
What really should worry us all, though, is that in some countries, the law apparently believes the exact opposite of this to be true.
This is probably missing the point. In one of your posts, you said it yourself: "EVERYTHING we do is because we perceive some reward." The same is true for FOSS/FOSH, but a bit more sophisticated.
FOSS culture and community is what sociologists call a "gift culture". Now, calling it that is misleading because what it really is, is a debt- based credit-and-goods economy.
One invests into the market by devoting time, money (lunches are not free) and effort to create a Product which he then lets loose into the world. BUT HE IS NOT GIVING IT AWAY! Instead, the developer now writes into his checkbook that the FOSS community owes him (dev A) that-and-that much value in return for his Product. And then someone (dev B) in the community pays him out when he (dev B) creates another FOSS Product that the dev A wants to use. And then dev A erases the debt from his checkbook since he has been repayed.
People who take FOSS but don't give back are despised because they keep racking on more and more debt to the community and they do nothing to pay that debt back.
The most probable reason Don Y is asking this question is because of the same debt dinamic. If his buddy invests an unproportionate amount of time into the project, Don will be in very big debt to his buddy. Bigger debt than he usually gets himself in. And he wants to avoid that commitment, hence the question and the thread.
It's awfully hard to convince others to start over even when it obviously *doesn't* work. Too many people think a bad design can be fixed by tweaking ... the most well known example of this is called "government".
The common thread seems to be that it's "awfully hard to convince others" regardless of the subject or the amount of evidence.
My first boss told me that the toughest thing for an engineer to do was to hit a brick wall -- and keep *beating* on it instead of taking a step back and heading off in a different direction.
Close, but no cigar. Just keeping on beating on the same piece of wall would of course fulfill the famous definition of craziness: doing the same thing again and again, yet expecting a different result. I don't think we as engineers should plan on being crazy.
The real tough thing for an engineer in that situation is to figure out that there's usually a third choice. Most of those brick walls actually do have doors somewhere, which you will find neither by blindly hitting the same piece of wall again and again, nor by running away from the wall altogether. You have to get a proper look at the wall instead.
So the clever strategy is to step back from the point of impact a bit further on every repeat run at the obstacle --- and be on the lookout for possible doors while you're back there.
But I mean that we go to our favourite distributor, see that an ABC123TQZ-64PL is $1.99, and design that in. We don't tend to think 'what if only the TQJ part is available?' or 'my maximum price point is $2.17, what will I do if prices rise?' or 'from what other manufacturers can I buy an equivalent part in the same footprint' or 'can I switch to a different microcontroller if the family I'm using gets expensive/discontinued'?
Well, we might do if we're manufacturing engineers who know that the factory will buy in a different batch of parts each month depending on what's cheapest. But most of us don't think that way by default, and thinking that way in advance costs extra.
Which means that someone picking up the project has to do all this stuff because their distributor will have a different part. Maybe 90% of the board will use common parts, but the key semiconductor or connector or whatever will be the snagging point.
Yes.
But FOSS have enough infrastructure so that this is easy. Run setup.exe or apt-get install wierdlanguage libstrange
and you're all set. But in hardware land that means paying $x,xxx for the tool and then spending days setting it up, wrestling with the licensing, and so on. I can throw out designs done in my favourite tool, but people with other tools can't read them or edit them. We can't collaborate when I'm using Altium and you're using PADS, in the way that Visual Studio and GCC can both compile C code. Yes we can share gerbers, but that's like sharing the assembly code.
Which means, if I'm aiming to design for an open-hardware project, either I use my familiar high-cost tools, that shuts out lots of the prospective 'market', or I use the OSS tools which just serve to make my life difficult.
Indeed, but one of the reasons FOSS works is it scales. Thousands if not millions of servers run a Linux distro like Ubuntu, exactly the same code that will run on your laptop. No customisations are necessary, despite different hardware and a different environment. Not having to do the boring customisation means you can get on with the interesting thing that you wanted to build on top.
In open-hardware land, we're still at the level of having to recompile your OS before you can run it. Which isn't that helpful if all you wanted to do was turn on the box to send an email.
In essence, open-hardware is terrible at reuse. In FOSS-land libraries like OpenSSL are used by hundreds of other programs. Show me an open-hardware design that's been reused more than a dozen times?
The only example I can think of is Arduino, which is a) quite simple hardware and b) mostly a software project in terms of what people are actually doing with it.
For example, why am I buying DC-DC converter modules when I could mount the components directly? Why can't I go to a library, pick a DC-DC layout and plonk it on my board? Sometimes it happens with reference designs, but those are usually tied into a particular manufacturer. Why can't I pick one based on whatever parts I can buy this week? Can I tailor it based on whatever board stackup I have? And so on.
OTOH many things are possible given enough time. But sometimes the time is better spent doing interesting stuff :)
Oh, but "we" *do* ask these questions! :> (though I see more and more folks NOT worrying about these details anymore... design cycles and product lifetimes for COMMERCIAL products are just too short).
E.g., when I started out, it was a rule of thumb that you had a second source for all of your critical components. This was so common that you had manufacturers actively seeking "partners" to produce their "unique" components lest they not get designed into products (witness the 68000 family's introduction... 8 alternate sources for a *motogorilla* design)
If you are designing commercially, you have a target build cost (DM+DL), a target sell price, a target time-to-market and a target product lifespan. These tightly constrain your choices (esp if you are trying to maximize PROFIT!) You tune the product development to those criteria.
FOSS (and I contend FOSH) tend to emphasize *lifespan* at the expense of all the others. There's no "sell price" for FOSS or FOSH so its not an issue. Likewise, there's no clear time at which you can consider any of these things to be "done" -- in the sense that cars for the 2014 automobile model year need to be on the showroom floors
*now* (when will Linux be "done"?). So, time-to-market isn't a key criteria. Build cost for software is meaningless; for hardware, it's probably less of an issue than commercial products because folks can economize in various ways (e.g., using parts on hand, benevolent suppliers, etc. -- how much can you economize on your next car purchase? Perhaps supply your own *tires*??? :> )
So, with FOS*, you focus on the long haul. You *expect* the parts available to change over time and don't unnecessarily tie yourself to a particular supplier, component or implementation. (I've known manufacturers who purchased "lifetime supplies" of critical components instead of risking a redesign during the product's lifespan. They were acknowledging that their product had a finite lifespan and were comfortable with this)
You don't *have* to do anything! You can "simply" reinvent the wheel! :>
I don't have to run Windows -- I can write my own OS! And, all the apps that I will need, etc. If Windows doesn't provide a service or feature that I want/need, what options do I have?
The PDA's that I've been accumulating as "portable displays" seem to suffer from "backup battery failure" whether this is due to their age or a consequence of some design flaw. But, the replacement "batteries" (cell) are not available in the US. Should I try to mail order them from a supplier in Europe? Should I find a different device to use as a portable display? Or, should I plan on cobbling in some *alternate* "battery" (or, do away with the need for this functionality altogether!)?
Because FOSS isn't dealing with anything *tangible*. To draw a parallel to your FOSH predicaments, imagine x86 architecture went away. What would you do? "Retool" for a new architecture!
But, what if that new architecture was sufficiently different from the existing architectures, today? E.g., Harvard architectures where I+D are strictly separated? How would you react to the market going off in the i432 direction, today? Or adopting entirely different memory management mechanisms (e.g., whereby the size of individual pages were specified along with permissions thereon)?
You either spend resources making your existing FOS* design fit the new "parts available" -- or, you copy portions of the *design* into an entirely different *implementation*. The point at which you opt for one approach over the other depends on the resources you have available to pursue each option.
(e.g., if you have a new EDA package, you might opt to just manually redraw schematics *in* that new package instead of trying to coax the old package to work on YourNewOS version N+1)
How is that any different than a FOSS developer deciding he wants to write the code in some bizarre LISP dialect and create his own build environment (instead of relying on "make"), etc.? Look at the build environments for Jaluna, Mach, the "Chumby", etc. And, tell me *why* they couldn't have been done with make(1)? Try
*converting* any of these to use make(1) and tell me if the time you spend couldn't have better been spent improving the codebase than dicking around with someone's "build du jour" concept.
There has been no incentive for Altium, PADS, et al. to share a common interchange format. What do you standardize on? Pinouts? Packages? Thermal characteristics? Mechanical dimensions? 3D representations? Who creates the libraries of new part characteristics? What incentive does EDA vendor X have to invest in creating libraries that EDA vendor Y can freely exploit? The more functionality vendor X offers (e.g., thermal analysis), the more effort he has to put into building and maintaining these libraries -- all at the whim of the component vendors!
If you can't exchange library components freely, what value is there to exchanging complete *designs* (at any level beyond "pinlist")?
Exactly. I've decided to be as "selfish" as the FOSS folks appear to have been. I don't see any rational evaluation of *why* a particular tool was built in a particular language, with a particular build system, with a particular feature set, etc. Rather, it seems like it was done to be "easiest for the initial developer(s)" -- or, so they could *explore* a technology in which they had an interest in a "real world" scenario.
Note that being *truly* selfish, you wouldn't even publish the design. Or, just offer gerbers of boards without a clue as to what was being represented therein.
A PDF/TIFF of a schematic may not be as useful as having the schematic in a form that you can use directly. But, it sure beats a netlist wherein everything is "signalXX" and "Uyy", etc.
(Remember, no one is forcing these folks to adopt such a project. If I don't like Jaluna's build system and don't want to invest in "fixing it", then I can simply not avail myself of the technologies that Jaluna represents!)
FOSH scales just as well! The problem is, you may have to spend money to buy the tools that I choose to use! If "everyone" had a copy of Altium on their desktop, what would your complaint be?
I write all my formal documentation in FrameMaker. If you can't invest a couple of hundred bucks in a tool to prepare "print ready" documentation, what value do you place *on* your documentation? If gcc created binaries that were 10 times larger or SLOWER than some commercial compiler, would you still use it for a COMMERCIAL product? Are you saving the wrong pennies? Don't you want to "get on with the interesting thing(s)" instead of screwing around trying to save a few dollars on a tool?
Do you use a rock as a hammer? They're FREE! :>
[rhetorical questions, all]
An emitter-coupled pair?
You're comparing apples to oranges. Hardware changes. How much of today's software would run on an ENIAC?
Why are there so many different makes and models of car tires? After all, cars have four tires, why can't they all be the same make/model?
You can't take a piece of hardware and say, "this component will now be a capacitor" in the same way that you can change a configuration file for a piece of software.
OTOH, absolutely NONE of that software will run in the absence of hardware!
*ALL* projects are "mostly software projects"! I can design hardware in a month that will take me *years* to "program". Doubling the time on the hardware design won't halve the time for the software.
Why can't I plonk a search algorithm into my code in whatever *language* I choose? Or, for whatever underlying "memory" structure I want? (what if "memory" is a set of files on a disk)? Will the algorithm magically tailor itself to provide optimal execution time in, e.g., a NUMA environment (without the benefit of cache)?
It depends on what you consider "interesting".
When I got started in this business, we spent a *lot* of time counting
*bits*. And, timing various algorithms to trim whatever we could off their execution to make them "less slow" (e.g., clearing an accumulator took *10* microseconds -- when that number dropped to *1* us it was heavenly! :>).
Now, I consider "user interfaces" to be the most "interesting" aspect of design. Coming up with models that "fit" more naturally into what a person *would* expect of a device -- had the device existed on which to base his expectations!
You bet! Short design cycles don't excuse sloppy work. This part of the design cycle isn't a big part of the total, anyway. We also get the prices for the entire life of the project (typically five years) before we even pick the parts for a prototype. The quotes had better have a negative slope, too. ;-)
That was long ago. Not so much anymore. Nothing would get designed if a second source for everything was a requirement. In fact we don't have a hot second source for resistors.
Our time-to-market is a fixed number. Nothing to be gained here. The profit is more or less fixed, as well. Markets vary quite a lot.
Um, my car *is* a 2014. The '15 model year will be out soon.
Don't follow that. Using parts on hand might be interesting for very low volumes. They still have to be accounted for, though.
If you're building to contract (B2B) rather than for direct sale (B2C) a known, finite, lifetime is the norm. One-time buys are still dangerous for many reasons. Parts don't have an infinite shelf life and the cost is higher (present value, as well as future price decreases).
It's not sloppy work, it is designing to what is important. If your product life cycle is less than a year you ask the parts suppliers if they will be making those parts in a year and they will tell you they have no plans to discontinue the device. If your product life cycle is
10 years you ask the parts suppliers if they will be making those parts in ten years and they will tell you they have no plans to discontinue the device.
I know, I am going through this right now.
You do what you can with the best available information.
You can design pretty much everything using 2n2222 transistors and the
8051 MCU and be very confident of second sources. Otherwise you are right.
The sensitivity of a product time to market depends on the product. Sometimes you need to have it out tomorrow and every day late is big bucks, other times you just have to get it out and the exact timing is not so important.
Don't know where you live, but the '15 model year won't be out for nearly 12 months in the US. Last time I paid attention the new models came out in the fall.
This is why *true* alternate sources are important. You don't want someone else deciding that your product is at EoL just because *they* want to get out of a particular "business".
Note that determining if you have a *genuine* alternate source may be difficult. E.g., the motogorilla example I cited. There have been other cases where company A was really making the "second source parts" sold by company B...
You can "future-proof" a design without having to insist on certain
*specific* components being perpetually available. I'd be more nervous designing a PIC into a product than I would some ARM-based device. Similarly, using some technology that only lends itself to a unique device (e.g., Rabbit C).
E.g., coding in a HLL is infinitely preferable to ASM in this regard. OTOH, coding in Ada might severely limit your portability choices!
Of course, "ideas" are portable and, thus, can be adapted to a different implementation. But, the extent to which you have to cobble a design to *move* it to a different implementation can vary significantly.
And, you can design in ways that make the design less "tuned" to a particular implementation so when, e.g., the performance of the underlying metal changes you don't find your device taking on an entirely different "character".
IME, the biggest issue affecting portability is "package" reliance. I.e., if you expect to have 27 DIO's on a device and that device is suddenly unavailable in that package, cobbling the "missing" DIO's onto a smaller package can QUICKLY increase the amount of real estate required. If you've opted for that more integrated package in the beginning, chances are you did so for the express purpose of *saving* real estate -- and, thus, have no spare real estate to exploit! :-(
Aside from ego, I don't see how this applies to FOS*. Sure, you'd like to have a "result" sooner rather than later. But, what are you risking? Losing "market share" to a commercial product? Or some
*other* FOS* product?
In the former, if you can't compete on features/performance, you would have "lost the 'sale'" regardless. In the latter, chances are any
*good* ideas you have over the existing selection will eventually be "lifted" from your design and incorporated therein. Or, vice versa.
Historically, October. But, I think in recent years the "model year" has been pushed up (just like XMAS supplies find their ways onto store shelves earlier and earlier each year!).
OTOH, I'd be really surprised to see 2015 offerings in auto showrooms before the end of 2013! :>
(sigh) I forgot to clean and oil the drill bits. Best get to that before I forget *permanently*. :-/
I've been trying to think of a good example of a "drool" device that was exceedingly tempting to use -- yet, you knew, would leave you at the mercy of the manufacturer...
The Am9513 has got to be the perfect example! ("bloatware" in digital form! :> ) IIRC, there were no second sources. And, at the time, *nothing* compatible on the market (you could get
*some* of this functionality but nowhere near *all* of it -- even though some of it was just plain silly!).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.