Jee Labs Talk

This forum has moved to forum.jeelabs.net - this read-only archive is for reference only!

1. tankslappa
   

   I've been playing about with the LCD plug, using lcd.createChar() to perform animations of characters that were already written onto the LCD.

   It works really well. Reminds me of VDU23 from the BBC micro days :-)

   So then I decided to implement a screensaver on the Timer2 interrupt to turn the screen off after 10 seconds if I hadn't pressed any buttons.

   This worked really well too.

   Then after a few minutes I noticed some corruption on the screen... Due to a bit of lazy programming I was sending lcd.noBacklight() every 10 seconds, even if the screen was already off. However this seems to have shown up an issue.

   I think what is happening is the i2c message in the main loop updating the custom characters is sometimes getting interrupted (literally) with the backlight off message and ending up as a strange hybrid mix up of bytes.

   Now I know how I can solve this, just put the noBacklight command in the main loop, and just set a boolean flag in the timer which it checks.

   So my question is: Is this expected (mis)behaviour? Is putting the command in the interrupt considered bad programming?

   Posted 26/06/2010 05:11:45

2. jcw
   

   Generally speaking, most of the code in an Arduino sketch isn't interrupt-safe. Best to do things either only in interrupt mode, or entirely outside interrupts. The RF12 driver is an example where just about everything happens inside interrupts, it just sets flags which get polled in the app loop.

   The I2C code in Ports is not interrupt-safe. If you want to trigger something which uses I2C from interrupt code, I suggest setting a flag of some sort, and then testing for it and acting on it outside interrupt. Make sure you use a "volatile" variable for this.

   General code structure:

       volatile byte turnOff;

       ISR(..) {
         ...
         turnOff = 1;
         ...
       }

       void loop() {
         ...
         if (turnOff) {
           lcd.noBacklight();
           turnOff = 0;
         }
         ...
       }

   You have to be very careful about race conditions (turnOff can change any moment, even while testing for it) - but in this specific example you don't need to do anything special.

   Here is an example which shows that there can be some very nasty side-effects when using interrupts. Even something as "simple" as digitalWrite() can be tricky: . The problem can show up when changing one pin outside interrupt mode, while changing another pin inside an interrupt, but the race condition is so brief that it might take months before it ever happens.

   Posted 26/06/2010 09:32:50

3. tankslappa
   

   Hi JC,

   Thanks for confirming that. I suspected as much, but thought I'd ask as it might be a good warning to others. The effects can be rather peculiar.

   Thanks for the heads up about digitalWrite.

   I think I need to blow the dust off my DOS TSR programming head and see if it still works :)

   Posted 26/06/2010 19:43:12