| ??? 12/11/08 20:45 Read: times |
#160871 - Does this approach fit 805x and other small MCU? Responding to: ???'s previous message |
Per Westermark said:
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. The last time I used an ARM CPU, the combined hardware cost, budgetary, at Q10K/year, for all the hardware, including the PCB on the circuit board, plus the "wall-wart" to power it, and the injection molded metal-impregnated case, was about $40. That included a 4 MByte flash ROM and a 32 MByte SDRAM, an Ethernet Phy and RJ45 with magnetics, and a simple (3 terminal) supervisor, "glue logic" CPLD, and a MAX3232. There was a 100 MHz oscillator, too, BTW, and it did run LINUX, full LINUX though it had no local hard disk. The LINUX was compressed in FLASH and, on RESET, decompressed to enable it to boot, since it doesn't like running from ROM. 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. I have to admit, I can't quite imagine such a thing involving an 805x. 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 have generally found ASM to be quite adequate for object code not exceeding 64KB. I've used a "small-C" from time to time with small MCU's though I freely admit I've avoided using 805x hardware unless specifically directed to use it, since I have very low confidence in that positive-going reset. I feel the same way with other CPU's, so I've used others with RESET referenced to GND most of the last 30+ years. I do admit I've used 8048 quite a bit ... <sigh> ... but it has a negative-going reset, and that was LONG ago. 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. I really don't see how one can "get by" with that approach, but I'm still learning. 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. That "small-C" compiler I've dabbled with has no such problem. Of course it has no source-debugging capability either. Thank goodness for debug monitors that don't require such things. RE |
