Just another Perl shrine | |
PerlMonks |
(jcwren) RE: (4): why i may have to leave perl...by jcwren (Prior) |
on Nov 09, 2000 at 21:56 UTC ( [id://40756]=note: print w/replies, xml ) | Need Help?? |
I was just going back through a few old nodes, re-reading the good stuff, and came across something here. (This is from the node that this node is a reply to, by tilly.)
I do disagree on some things though. Linux is not actually a bad fit for a lot of the embedded market. Sure, at the very bottom end it doesn't make sense. But betting against it is IMO betting against Moore, and Moore has a few years yet to run. Plus as soon as you want an embedded device that is able to network using standard protocols, you won't wind up with requirements much below Linux' and guess which is less work?While Moore does say we get faster systems on a fairly regular basis, there is more to an embedded system than just the CPU speed and architecture. One of the issues is an embedded systems is the number of connections. PCBs (Printed Circuit Boards) are costed by several factors, some of them being the material used (typically FR-4), the number of square inches per board (board area), the number of vias and pads (the pads are for integrated circuit pins, and vias are used when a trace has to make a transition from one side of the board to the other), and the number of components. While Moore may double the horsepower, if the number of connections and interconnects aren't reduced, the product price can't go down past a certain point. A typical rule of thumb for board costing is about $0.06USD per pad/via in medium quantity runs (5K to 50K). After you've added up all the pad and via costs, board space, packaging requirements, and cost all the required ICs, you may find that no matter how much you want to run Linux on a board, you can't get the underlying fixed cost down low enough to make a product viable. I am, in fact, in the middle of such a quandary. I'm looking at doing the software side of a project involving vehicle location and performance dynamics, and my hardware friend (and I) want to wind up with (as a result of our development for the customer) a platform that we can use on other projects. We can go buy an off-the-shelf PC/104 system, but they're way over priced (I'll address that at the end). If we develop our own hardware, we own all the technology (schematics, layout, etc) for it, and can produce additional boards at a pure manufacturing cost (as opposed to an aggregated design/mfg/support cost). Sadly, embedded Linux is not looking viable. The two major players, BlueCat and etLinux still have memory footprint requirements that make them impractical for a system with 2MB of DRAM, and 1MB of FLASH (actually, it'll fit in the FLASH fine, but the uncompressed image kills us). Whereas, I can buy (for a lot more money) lynxOS, OS/9, vxWorks, etc that will easily run in the memory requirements. These companies have different licensing requirements (vxWorks is $50K, and isn't in the market, OS/9 is lot more reasonable) that affect the total project pricing. Now some of you will say "But 2MB or 6MB more RAM is cheaper than the per license requirement!". How true. It would be far cheaper to put 8MB on the board, and run embedded Linux, than it would be to use vxWorks. But this means we're now raising the fixed cost point of the hardware to support 8MB on each and every board, to run a free O/S. Yes, it's open source, but if I buy OS/9, I get technical support (and very good technical support, I might add. Most of these OS vendors have good support departments). I may be able to fix problems I find in any OS components, but then I reduce my time to market by chasing down demons that I may or may not be able to fix. Whereas, I pay them, it gets fixed. If I have a wide time to market window, then this may become acceptable. Also, the documentation for embedded Linux is still far behind the commerical embedded OS products. This is not a rant against Linux, embedded Linux or open software. It's a matter of market economics, where sometimes, it's better to pay someone else to take care of certain problems. There are plenty of projects that need heavier duty CPU power than a lot of projects I work on, and embedded Linux is a natural fit (Tivo being an excellent example). But for the price window we need to hit, and the fact that we don't have a large development time window means we're probably going to wind up going with a embedded OS vendor, and probably OS/9. Maybe next time... On the topic of why somethings cost more than you think they should: Consider a company that makes amateur radios. A typical mobile (one for the car) amateur radio transceiver runs about $500USD, average. That's a lot of bucks. However, Yaesu, Icom, Kenwood, et al have to pay for the cost of development, manufacturing, distribution, advertising, etc, amortized across a comparatively small number of units (say, compared to selling a particular model of a VCR). Whereas the technology in a PlayStation 2 is more sophisticated, you're selling a helluva lot more units. Same applies to software. Company X sells package Y for $Z, and $Z has to pay for the janitor that cleans their bathrooms, the marketing exec, the development cost, shrinkwrap, lawyers, etc. There's a lot of "hidden" cost in that package you pay for, and if they don't sell the software, they still have to feed the people that work for them. Open Source and all that aside, keep that in mind next time you wonder why something costs so much for something that seems so "simple". Consider all those hidden costs behind it, and what the volume of product they have to ship to be an economically viable company is. --Chris
In Section
Meditations
|
|