ISR and LCD updates

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I update my graphic LCD, I have done an cli() and sei() before and after. This does not affect SPI or i2c protocols nor are they affected by ISR's.

Problem is I now want a PWM signal to control an RGB LED and cli() obviously affects this.

So there is either some LCD corruption or LED flicker and I can't find a solution for both.
It looks to me that this can't be done or can someone point me in the right direction.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most AVR systems can operate without any interrupts at all. PWM needs no intervention at all. It runs by itself.

Many systems do use IRQs. I cannot think of any reason to disable IRQs for your LCD.

Look carefully at your code. Are you sharing port pins? e.g. if LED is on the same port as your LCD, always use |= and &=, never use =.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeh Dave you right, I am being dumb.
I am oscillating another port in the ISR instead of just using the native OC pins. Thanks for the wake up.

I am using a ks0108 lib for the GLCD which has a few delay routines in it. I assume this is the issue with ISR's.

I guess this lib may need a rethink.

Anyway, I now know how to resolve the issue, thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Without posting a link to your ks0108 delays, no-one knows.

At a guess they will be simple NOP... delays.

There is seldom any need to stop IRQs. This is the whole point. Use swift ISR()s and let any slow or blocking code run in the foreground.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What ks0108 glcd library are you using?

The delays should not need to have interrupts masked during the delay. Delays on a ks0108 are minimums, and do not have to be exact and can be much longer.

However, depending on the AVR and the i/o method used on the glcd data lines, interrupt masking may be necessary.
For example, if the AVR used is a m168/m328 you can't get a full 8 bit port when you use a UART.
But you still can get 2 nibbles.
The problem is the 2 nibbles span ports.
Updating a nibble can be faster than setting all 4 bits separately. The catch is that
if any of the other bits in the same port are used by ISRs, the nibble updating code
MUST mask interrupts during the nibble update, to avoid corrupting the other bits in the port.

Also, on other AVRs using |= and &= may not always generate bit set/clear instructions. It depends on the port address.

Now if you are trying to update the glcd from both foreground code *and* interrupt code, that is another matter.

--- bill