floresta:
There are some things you cannot do within an interrupt service routine (ISR) and Serial.print() is one of them.In general your ISR should do as little as possible, such as setting or clearing a flag, and it should then return control to the main program. The main program should be set up to periodically check the flag and decide what to do.
Actually for a while now there is code in HardwareSerial write() code that will revert back to polling the UART if it is called from ISR to allow printing from an ISR.
I'm assuming that since the OP didn't mention that the serial output is not working that serial output is working.
Deep_Sky,
I haven't done the math to see how often the ISR is called,
but if the ISR is triggered faster than the output time for the characters that are being printed.
The ISR prints 2 characters most of the time, so at 9600 baud if the ISR is called more than every 2ms there will be issues as the code will be continually calling the ISR with virtually no time for anything else.
But the main problem here looks like the variable being printed on the LCD "i" in this case, was not declared as volatile.
So more than likely LCD output is working but the value of i showing up on the LCD is not changing since the optimizer is calling lcd.write(i) with the same value over and over again instead of the actual value of i stored in memory.
You could see this if you declared another variable that you printed that you incremented in loop() instead of the ISR.
That variable would increment, but the value if i would not.
Change the declaration of i to include volatile and the "problem" with printing i should go away.
However, the next issue will likely be that the LCD isn't properly showing the value of i when it is less than 10 which is because the code in loop() doesn't clear out the character positions before it prints the value so when i wraps around back to a single digit, there will be left over '9' to the right of the single digit.
Just keep that in mind.
--- bill