??? 11/30/10 23:22 Read: times |
#179770 - Often easier to shrink after you have a product Responding to: ???'s previous message |
Andy said:
We see frequent posts here where people have designed themselves into a corner by choosing a chip barely sufficient for the initial requirement - they are then stuck when extra features are requested. Quite often, it may be worth it to do the reverse. Design with more powerful tools. Start selling. Wait until a customer walks in and asks for the cost to buy 100k units with some slight modifications. Then use the experience from the first 10k units already shipped, and shoehorn the firmware into new hardware specifically adapted for that customer. Having already gained a lot of market experience with the relevant product, it will be way easier to recognize the cricitcal design decisions for building a cost-reduced version of the hardware. And already having code means that a lot of that code can be compiled for a new target processor just to give a hint at the required amounts of code space. Lots should already be know about the RAM needs, or computing needs. The big thing to consider is that the original, more porwerful, hardware is already out there bringing in money while the super-optimization is performed for the high-volume custom edition. So one of your own products is already trying to defend the market shares, and putting food on the table, while the new development is ongoing. Better with a two- or threestep process, than getting into bankrupcy trying to get that initial killer product ready to sell. And never forget the simplicity of debugging a processor that have a JTAG interface with extensive ICE capabilities and that have an extra high-speed output port for debug traces and that can perform some extra job in the background while still managing the required real-time performance. A C/C++ program with 30% of speed/memory free for debugging is such a joy to debug compared to a processor where you are already at the limits. And reengineering in case initial pilot testing shows some conceptual problems is so much easier since there isn't a need to take a very extensively optimized algorithm and turn inside out to get a new, very extensively optimized algorithm - just to still get the code space, RAM or speed to suffice for the task at hand. |