True enough, but what about the 100-unit-per-week instance?

Again, quite true, but sometimes the initial "guesstimate" as to what's needed is ridiculous.


This is where your case and mine differ a great deal. Whenever I use a multi-kBuck tool, I have to ensure that the tool is available to my client after I've gone away. I can't leave him in the situation of having to come back to me just because he wants to make a small change. If I were on someone's payroll and likely to remain so, it would be different, as the development tool cost would really only occur once. If I use the multi-k-Buck tool, every one for whom I provide service has to wind up with it, whether he buys it, or whether I provide it as part of my deliverables.



As I've said before, where you sit determines what you see. I guess one component in my HLL vs ASM decision is what it will add to the overall project cost as seen strictly in terms of my involvment. If I have to add the cost of the KEIL tools to my involvement, I am likely to be uncompetitive. Whether I provide that tool set or whether the client has to buy it himself, it's still part of the cost. I certainly can't, in good conscience, perform a firmware task and leave the client with the sources but no tools with which to process them. I also can't say, "I used KEIL, but there's a free SDCC into which you can translate/modify the code so you can rework it as needed in the future." I've found that well-documented ASM is the easiest and least troublesome way to deliver code. The Assembler is normally no-or-low-cost, and there has, in my case, anyway, been little need for after-the-fact fiddling with the code. Generally, follow-on work has been upgrades and enhancements rather than major reworks. That's why adding functions and features has generally required more code space and/or more performance, since MCU, memory volume, and speed were initially sized for the task at hand.

RE