Atmega169 / 329 / 649 datasheet improvement?

1 post / 0 new
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The data sheets have a paragraph concerning how to disable the LCD. I quote, "When the LCD is disabled, port function is activated again. Therefore, the user must check that the port pins connected to a LCD terminal are either tri-state or output low (sink)."

Actually there are two other possibilities. Output high on all pins, and pullups activated on all pins. The only thing that matters to the LCD is that there is no DC voltage between pins.

Tri-state seems a poor choice because it leaves the pins on the Atmega floating. This can cause "crowbar current" to flow in the CMOS input of the Atmega. The amount of this current wanders all over the place. Sometimes it is zero but it can be as much as 2 ma. If there is no excess current flowing, touching some of the LCD pins will get it started.

Tri-state is the easiest because that's the default state after a reset. I think the Atmel Butterfly code uses tri-state and gets away with it because with their code the Atmega is almost always in power save mode when the LCD is disabled. In power save, power down, and sleep modes, the inputs are clamped to ground so the crowbar current doesn't happen.

There must be a momentary pulse of crowbar current each time the Atmega gets interrupted out of power save but the interrupts are processed so fast that the excess drain on the battery is probably trivial. But some applications could see an appreciable battery drain. If the USART is used, it requires idle mode instead of power save mode. So if you use the USART and insist on tri-stating the LCD port pins, you should ensure the LCD is enabled when you use the USART. I think this crowbar current will flow in ADC noise reduction mode too.

Anyway I think it's rather shabby to leave these I/O pins in tri-state, and at the least, Atmel's data sheet should warn the reader of the possible disadvantage of using tri-state.

Do you think I should send this to Atmel?

I wish to thank MegaUSBFreak for his informative post to my previous thread on this subject.