805x devices that don't support JTAG are not necessarily ancient. The fact that some of them are older than you doesn't make 'em ancient either. I'm older than any of 'em, and I don't consider myself ancient, though I admit I'm well into what's commonly called "middle" age. There are PLENTY of currently manufactured and sold 805x devices, some with new revisions coming out in a month or so, that don't support JTAG. The fact that there are applications that I designed in the '80's using 805x devices that are still in successful use and still in production merely underscores the quality of that MCU's product line.

"Resident" simply implies that the debugger executes within the environment and on the core of the local 805x, not in an external device. In a case such as the little debug daughterboard I occasionally use, it substitutes the MCU on the daughterboard for the one normally in the socket which it occupies.

The fact that it resides within the environment under test is what makes it useful, since it then executes code with the timing and under other effects of the local environment. That way, if I'm debugging a synchronization problem between I/O and the firmware, I can execute test code within that environment, just as I would if I had an ICE plugged in, with the exception that I don't have to deal with the inherent weaknesses of the ICE, i.e. the imperfections in the manufacturer's hardware, software, and documentation, not to mention all the misrepresentations introduced by their sales and marketing departments.

What I use as a terminal, these days, is generally a notebook running some version of Windows and a terminal emulator.

However, I believe it's incumbent, ethically and morally, on me, to provide services at the lowest possible cost to my clients. This doesn't mean, simply, that I should do my work for nothing, but, rather, that I should do things in the most efficient and cost-effective way that I can.

If I have to learn how to use an ICE, or whatever, I have to recoup that lost learning-curve time somehow, and that's reflected in the rates I have to charge every one of my clients, whether their task requires a given tool or not. I do my work on time and materials, mostly, or I propose a flat rate, but both approaches require that I compensate myself for the effort, including that by-then-past learning curve time, the bulk of which is in discovering and developing workarounds for the weaknesses of whatever support tools I use.

If a particular tool that I use does what I expect, then I probably use it whenever it's appropriate. If it doesn't meet my expectations, I still have to charge for its cost and for the learning curve investment I've made, whether that's of benefit or not. I have to add, that, in most cases, it's not.

What would fix this would be that, if a sales person either fails to know absolutely everything about the hardware/software he sells, and therefore misrepresents it in any way, he should be taken out back of the plant, shot, and his transplantable organs sold at public auction to offset the purchaser's associated costs. Further, the top ten executives in the company that incentivized him to misrepresent their product in order to make that sale, should be required to eat their first-born in a public forum, say, during a televised football game.

In many cases, that would lead to a majorly interesting fight, possibly more interesting than the game.

That's not likely to happen, however.

The reason I want the functionality to be resident in the local MCU is that it's the only way that I can ensure that I know what I'm doing, since the use of a commercial support product only guarantees that there is a vast range of things I'll never know about it.

If there were some really cost/effort efficient way to do what a resident debugger, which, BTW, is what an ICE attempts to provide, albeit indirectly, I'd use that.

805x repesents perhaps less than 10% of all my MCU applications. The resident debugger I want will be available, with some effort on my part, in versions supporting most of the MCU's I service. That debugger will function as I make it do so, and will be available in multiple copies as I need it to be, yet won't cost me any more whether I use one or ten copies of it. That's not a claim I could make for any commercial product I can name.

The 805x is still in wide use and still supports a substantial memory map, despite the fact that most applicaitons require only a small part of it. This flexibility makes it my first choice for applications that are destined for limited-volume production. Those applications are the ones where the development and support/maintenance costs have the largest impact. That's the reason I want to support 'em with the lowest cost.

When I find a commercial tool set that helps me lower my investment in time and money, I'll use it. In the meantime, I'll use the tools I already have, and those I can get at low/no cost. That way I can be the one to decide how much to invest and pass on to my clients.

RE