A simulation tells you that a given circuit might work. A prototype tells you that your particular implementation and construction of that circuit appears to work.

A hand-built prototype, e.g a wire-wrapped version or one that's soldered point-to-point, or even one that's "hooked up" on one of those "solderless breadboards" that some people like, tells you nothing about any circuit other than the one immediately in front of you.

It tells you that the components might work. It tells you that the configuration might work. The "better" (note the quotation marks!) the construction, the more information you can realistically extract from a prototype. However, one prototype will tell you little about how another even if constructed on the same model, will behave. Above all, a hand-built prototype will shed little light on the future behavior of a printed circuit board of the same circuit.

When events involve a few MHz, or even oe or two tens of MHz, a hand-built prototype, fabricated in the kitchen or basement, can behave quite well, but as MCU performance reaches up into the range beyond the capabilities of "TTL" devices (~25 MHz) it's tempting to combine it with circuitry that is expected to perform at rates approaching the 100 MHz realm. That's a dangerous area for hand-wired circuits, not because you might hurt yourself, but because you might fool yourself.

Please don't confuse "debugging" with "testing." The former is a process of determining what the system under test does and how to fix it when it doesn't do what's desired. Testing is what you do to ensure that you know what the system under test does once it's apparently working perfectly 100% of the time when stressed by power supply noise, termperature variation, mechanical stress, EMI, and extreme variation in system stimuli.

You can't "test" a system that's unproven. You can only "try" it. When you test a system, you have a rigorous procedure which you must follow, for a defined period, say, 100 hours, or 1000 hours, just to ensure that it meets predfined specifications.

Testing is normally reserved for deliverable hardware, firmware, and software. A simulator will never produce results that take the place of testing.

Abhishek Bk has asked for freeware that will test his hardware. No such software exists, nor can it. Software can provide stimuli, control the mechanical environment, and control power supplies, sources of noise, and sources of signals.

There are lots of "toys" provided by manufacturers of MCU's, that enable the code developer to step through his code and see what the MCU might be doing with it. These seldom allow automatic simulation of any external events, nor do they make any pretense of genuinely representing the behavior of the hardware. Such software requires considerable development effort despite its limited capabilities. One can't expect such an effort to go uncompensated, so it's really unlikely a tool such as this will be both effective and "free" as in "free beer." The primary weakness of these tools is their total inability to interact with external hardware. Consider that before wasting lots of time searching for tools that are both "good" and "free."

RE