void loop() // run over and over again
{
if(var1 > 99)
{
var1=0;
I'm glad to hear you have things working better. I took a closer look at your code and can see a few small problems and one potentially large one. I've quoted the big problem above. This is the reason why things improved after you removed your delays. Basically you are assuming that your main loop is excecuting so fast that you are evaluating this statement at least once for every new value of var1, but if you experience some kind of delay in your program var1 might be updated several times by the interrupt before you check its value.
Let's assume var is 99 when such a delay hits. 30 ms later you reach the top of loop(), notice that var is greater than 99 (it's actually 102 right now), and clear it. By now clearing var1, you've completely lost any record of those extra two counts, and your concept of the current time is now off by 20 ms. The solution to this is to do the following:
if (var1 > 99)
{
var1 -= 100;
...
}
Usually this will cause var1 to reset to zero, but if for some reason var1 is something like 102 when you reach the top of loop(), subtracting off 100 preserves those extra two counts, giving var1 a head start on the next cycle that will keep you from losing time. If you do this, the time-keeping ability of your program should pretty much become impervious to overhead from the Arduino framework, and you won't have to worry about delays from other interrupts.
The minor problems I see are that you aren't using your timer1 interrupt in a safe way. For one thing, you could experience an interrupt in the middle of reading or writing to var1 (var1 is a two byte value, so reading and writing it are non-atomic operations that can be interrupted). What this means is that you might have read the first byte of var1, then the interrupt happens and changes var1, then you read the second byte of var1. Your resulting two-byte integer is now potentially corrupted. Fortunately there is a simple solution to this problem in your case: make var1 an unsigned char. This turns it into a single-byte value, so reading it and writing it become uninterruptable atomic operations. This works for you because you never require var1 to be much higher than 100, so you can get by with it having a range of 0 - 255. Does this make sense?
Lastly, you could experience an interrupt to the line
var1 -= 100;
because at the assembly level what you're doing is
load var1 from RAM into a register
decrement register by 100
save register to var1
If the interrupt happens after the load but before the save, you will miss that interrupt's incrementing of var1, and you will have lost 10 ms. Fortunately, the chance of the interrupt happening in that critical place is incredibly small, so what you end up with is a very slim chance that you will lose 10 ms every loop cycle (i.e. it's not going to be a very big source of error). The way to protect yourself against this, if you even think such a thing is worth it, is to disable interrupts for the duration of that non-atomic operation:
if (var1 > 99)
{
cli(); // disable all interrupts
var -= 100;
sei(); // enable interrupts again
...
}
I think if you do all those things, the only source of systematic error in your timing will be the inaccuracy of the external resonator.
Q. How does one find out what other intrpts are in use that might interfere?
You could figure it out by looking at the assembly version of your code. Check out the ISR jump table for non-zero entries. Or you could try to trace through what the Arduino code is doing behind the scenes. For example, before setup is called, the function init() defined in wiring.c is called. This enables an overflow interrupt on timer0 that is used to drive millis() and delay(). I don't think the Arduino code enables any other timer interrupts, and I don't think it uses serial interrupts (but I'm not certain of this). The timer0 overflow interrupt might be the only one.
Q. Why dont the include i/o and interrupt headers need to be added? Are they
included in arduino 11?
These files are automatically being included by the Arduino code that frames your code.
How do you see assembly output from compiler to see what it does?
I'd be very interested to know if this is easily doable using the Arduino IDE (or even just GCC). One really inconvenient way is to use avrdude to generate a hex file of your program. You can then open this hex file in a text editor and decode the assembly from the hex by hand (ugh). The only convenient way I know of is to use AVR Studio to compile your code and configure your project to output a list file. This list file shows the assembly in a remarkably readable format. You can even step through this list file line by line as you debug your program in the AVR Studio simulator (just switch from the standard view to the disassembler view). I'm not sure how you would get the Arduino backbone of your program into AVR Studio, though.