Paul wrote:
-------------------------------
But how can you debug your program on your target hardware in realtime without using an emulator?

- - - - - - - - - - - - - - - -
As I add a routine or process to my code, I immediately test and evaluate it with a co-written test routine. By testing a routine out completely before proceding, I have few mysterious bugs appear during a project. I do a lot of three dimension calculations in my business and this approach allows me to do an exhaustive test for all possible number inputs to validate a routine or algorithm instead of relying merely upon test-lab induced circumstances. Lab induced tests can miss those algorithms failures that occur on the edges of rollover.

For reading the test outputs, I rely upon primarily the serial to pc link that I use to program the FLASH. Sometimes I use system displays but seldom do I rely upon a scope; it takes too much time to hook up and it has to be hooked up everytime I decide to run a test. Its much easier to run a test a thousand times and measure that runtime.

Obviously, these test modules are only included when one module is tested and removed immediately after passing its acceptance. I often dump data back to the PC into a buffer that I import into Microsoft Excel to evaluate.

Like Peter mentioned, adding a printf() statement in code is just as effective as having trace information from an emulator. In some ways, forcing you to place these signposts, makes you think more closely about the flow problems than when using an emulator. I've observed that many people using emulators get too involved in working out the emulator display issues to get information just they way they want it... instead of focusing that mental time on the target.

Emulators can be fun, too fun. I prefer to take them away and keep the attention on the target and code.

After all it doesn't cost me much to keep reprogramming a FLASH micro over and over.

aka j