You've guessed wrong as to my use of 'C'. I use it on the PC whenever necessary. I don't write much on the PC in ASM, though I do write short test fixture exercises in ASM. The stuff that talks to hardware is nearly always in ASM, but that's easily rolled in to a 'C' program.

I don't believe I'll understand the functions provided by a compiler until I've thrashed 'em quite a bit. That's one thing that takes time. What I would consider a substantial evaluation is regeneration of an entire completed project's firmware, already written in some language, and satisfactorily funcitonal, in that it meets all requirements as witnessed by passing all acceptance testing. If the result successfully meets those tests, that's step 1. If it is not substantially larger, that's step 2. If it is not substantially slower, that's step 3. If it's significantly quicker generating the HLL source, that's a plus. If it's significantly quicker verifying the code, that's a plus, though that's not easy to verify on an already-proven project. This, of course, says nothing about the simulator and other features of the compiler, depending on what features it purports to provide.

If the doc's were adequate, and one could adequately evaluate a compiler, no matter what the HLL, the first thing I would do is to verify that the documentation accurately reflects what the software is does as observable from the user's viewpoint. If that fails in any way, I'd stop. Then I'd have to try a considerable number of different application techniques to determine whether they work adequately, particularly the interaction between HLL and ASM functions. That's where regenerating an already-proven project comes in. I'd probably have to make it a fairly large one, or, perhaps, several of them just to "cover all the bases" as far as techniques are concerned.

Then, of course, I'd have to examine the debugger and the simulator, if there is one. If it covers the MCU types in which I'm interested, I'd consider it, and if not, well ... then I wouldn't. If they want me to pay for a simulator, then it has to simulate the parts I want to use. I'm certainly not going to pay for one I can't use or won't because of lack of device support.

Frankly, if someone actually produced a stand-alone simulator for the 805x core with a library of MCU-specifics, one that could simulate interactions with external hardware, particularly scheduled interrupts, I'd consider it as a standalone product. I've even considered, at times, writing one myself, but I don't use 805x much ... Only when I'm working follow-on for stuff done in the late-'70's and early '80's on client-specified hardware ... aside from my "mental masturbation" projects of more recent vintage.

After all, I believe that all these "RESET" problems are really power supply issues, among other things, hence, I can't get to the bottom of that if I completely ignore 805x.

RE