Programs may, at times, have runtime errors. These are sometimes hard to find and can easily be missed. Is there any way to test the program before actually burning it onto the board ?
There are a few Arduino Simulator projects out there.
The Virtronics page linked above also lists a few other Arduino simulators, both free and paid.
Given the interest the Arduino evokes, there are likely to be many more such simulators out there, so no point trying to list them all in an answer here.
What is worth noting is that there is also an Arduino Simulator iPhone app: This is not a recommendation, not having seen it in operation yet.
On a side note:
The Arduino is in itself a prototyping / experimentation board. It is ideal for programming experimental code, debugging it, modifying and then re-flashing fresh code, pretty much as many times as one likes. If the code hangs, reset and reflash with any changes.
Therefore, the merit of using a simulator, which can never perfectly emulate the various real-world timing or other issues an application might face, is questionable.
If the cost of the Arduino is the concern, there are a couple of options open:
- Inexpensive Arduino Nano clones off eBay - I have several Meduino Nano Enhancement boards, they work excellently, and are priced at under $10 including world-wide shipping:
- Make your own Arduino - The Arduino site walks you through making one on a breadboard, which does not even need you to solder anything!
You can find runtime errors if you can manually step through your program with the Arduino connected and debug (after downloading code to the Arduino). This is available in Visual Micro although it requires Visual Studio. You can set breakpoints, evaluate variables, and change variable values. You can also get visualization of of memory over time:
One way to do this would be to create a wrapper program for the actual code which simulates all the inputs and accepts outputs (thereby creating a feedback loop) as per the real environment. This would take variable amount of effort depending on the type of program, degree of testing and number of inputs.
Keep in mind that while writing the wrapper program, you should follow a black-box approach.
Otherwise, your outer code may not test the program as well as possible as keeping in mind the actual code while creating the test code may bias you to ignore boundary cases or problem areas (This has been observed to happen while doing White-Box Testing which is the alternative).