??? 12/11/08 17:56 Read: times |
#160867 - more on big/small series Responding to: ???'s previous message |
Yes, I would not use a 8051 chip for such a product, but a 32-bit processor to allow future hardware growth in case of changed/extended requirements (as oposed to code bloath) - and C or C++ to allow the code to run on a different processor with just remapping of hw. A $4 ARM7 has enough processing power and memory, but the "dynamic cost" for 128kB of extra flash or 32kB extra RAM is quite marginal to the end-user cost.
A minimum of cost to fit to an ARM7 (instead of running on a full Linux setup) and most cost for algorithm development and certifications of the algorithm (besides any hardware certifications). Maybe the product can support the cost of a full Linux, but on the other hand the ARM7 can boot and be productive "instantly" or scale down into a power-efficient supervisor when running on almost empty batteries. Yes, I know this isn't really a representative example. But the important thing here is that the sw costs can vary by several magnitudes which also moves the break even limit for big or small series by magnitudes. When sending out 10k/month wristwatch-sized radio buttons, assembler was a requirement since the production cast was "the" cost. In some situations, almost all of the investment is instead in the software. In some situations, you may even give the hw out for free since all the money is in the licensing costs to use the sw. In the end, some projects requires most of the know-how into finding the cheapest hardware. Some have almost all know-how in the software. Most are somewhere in between. That is why ASM isn't the general winner. It peaks out at one end of the scale while C/C++ wins at the other end of the scale. Each project have to figure out where on the scale the project is. What is the hw production costs? Where are the investments? What are the (guestimated) needs to move the software to new hardware? I seldom work at the range where 100% assembler is a good investment. Almost always, the goal is for 100% C with an (preferably not taken) option to rewrite any critical ISR or evaluation loops into assembler. And quite often with blackbox-testing of modules on a Linux machine besides any regression testing run on the target hardware. Prioritizing ASM first kills options. One thing I would very much have liked is a PC compiler with support to turn off integer-promotion, to allow 8-bit code to be run on a Linux workstation without the need for explicit 8-bit typecasts in the code. |