The user of the ISP feature is the one who pays for the adapter with the quadrillion-gate FPGA. It's part of the cost of doing business. After all, the field-fixes are required because the device manufacturer wasn't willing to ensure the code was correct at the outset. If I'm building a $40 device and it would cost $50 to build an ISP adapter, I have to figure out whether the end user would be willing to pay the $50 or whether he'd rather pay another $40 for an upgraded device rather than field-fixing it.


Hmmm, where did I say that? However, you're right! That's the basis on which I make my decision. I don't care what the other guys pay. It's the total cost that I consider, though. If it costs $1 for the chip and $50 for an ISP adapter, then I have to look at how many customers might want that ISP adapter. If I figured it is a lot of them, I'd want to make it as easy and reliable as possible for them.

Consider that flash-upgrade that's available for your PC motherboard. The motherboard maker provides all the necessary hardware and software, and, maybe 1 in 10000 of his end-users use it. OTOH, there's a standard HD interface since lots of his end users will need that.


That's not quite how it works. The chip makers don't waste their time sitting around trying to think up a really good chip design. The marketing guys to out and try to get someone else to work out the concepts, in a form that they're willing to specify and sign up to pay for, and then they try to implement it. Sometimes they succeed, and sometimes they "almost" succeed, but, in the end, they have a chip that someone's paid for and they now try to sell it to everybody else.

Don't forget, it's the million-chip-a-year user who gets to specify what goes into the chip. He's going to do his work right the first time and probably won't even need to do a "field fix" since he can simply say, "It will be fixed in the next revision." In fact, in today's market he's unlikely to use a "stadard" MCU, but, rather, is likely to incorporate its functions in an ASIC costing him about $0.50, ignoring his $3E6 NRE. However, in the unlikely event that he does decide he wants to support field-fixes, he won't mind spending the extra bucks on an adapter to his chip, as the ATMEL and PHILIPS people did when promoting that capability for their various (and apparently quite different) chips. After all, he won't necessarily need to build that into his chip if he includes a $2 CPLD to create the necessary ISP adapter logic on his PCB, and sells the CPLD as part of a product maintenance kit. (several high-volume product manufacturers have done just that!) With a "standard" host interface, all he has to provide for software is the URL to the chip vendor's web site and the upgraded code hex files.


Of the few high-volume MCU users I have, over the years, supported, each one started out with a design I provided. I made my MCU selection not so much on MCU cost as on a combination of convenience of coding, convenience of programming the device, and, of course, cost. When I made that decision, I was a small user. One of these items, at the time, was envisioned to be a <100 units per year design. Because I knew at the time that I had competitors, I wasn't willing to lay out lots of my own money for a programmer and costly development software and hardware on the perhaps even chance that my design would be the winner and I'd recover costs on the follow-on work.

BTW, not one of those field-fixable MCU's I have in these devices has async serial comm's.



I have no illusion that any chip maker is going to listen to a small user, even a consultant like myself, in making decisions about building new products. He's going to listen to the guys who pay for its design by contracting to buy the first million units.

I've often read your exhortation to buy rather than make an ISP adapter. I have to agree, with the wide variation between ISP-compatible devices from manufacturers that make their parts differ, despite the fact they look and behave nearly identically, makes it vital that one have the appropriate ISP adapter. What I've been advocating, however, is that (a) new devices use a standard ISP physical host-interface, (b) that the device manufacturer provide software to make that device programmable via that interface, and a precise and correct specification including timing and schematic circuitry if required, for an adapter to their "nonstandard" ISP function, so that, when necessary, the device can be programmed in-situ.

The reason I mentioned JTAG was because it uses a simple interface through either USB or the parallel port. I've had really good and reliable results with those JTAG adapters, though they're all different, from ALTERA, CYPRESS, XILINX, among others. I haven't been terribly disappointed with other schemes but believe a standard logic-level interface that adapts to the application's Vcc would be both simpler and safer.

I do believe that manufacturers of older chips, i.e. those we can get today, could easily provide both software and hardware that uses the 4-wire JTAG scheme as the host interface. New devices could even use USB. It's even conceivable that the mfg's could get together on a standard that actually uses USB. What's more, they could be a lot more helpful with this ISP stuff, so 8052 doesn't always have traffic related to this or that circuit that "doesn't work" ... probably because it's not built correctly.

I know you rely heavily on the UART in your 805x-like devices. However, if you had a device that needed EVERY pin for parallel I/O and had no normal need for async serial I/O, you'd probably figure out a way to make ISP work if you needed a field-fix ... or would you make your customer pay for a device with more pins even though you only need a 20-pin part and don't need the level-shifters. wouldn't you?

RE