[newbie] Butterfly LCD - system or async clock?

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

In the LCD Demo app for the Butterfly, the LCD_Init routine sets up LCDCRB, the ATmega169's LCD Control and Status Register B, like this:

LCDCRB = (3<<LCDMUX0) | (7<<LCDPM0);

This sets bit 7, the LCD Clock Select bit, to 0. According to http://www.atmel.com/dyn/resources/prod_documents/doc8018.pdf (the ATmega169 user guide) that should select the system clock. But the comment above this line says it selects the asynchronous clock source instead. Also, in his post "[CODE] [C] Simple Butterfly LCD driver", Dean Camera comments that he selects the asynchronous clock; sure enough, he sets the bit to 1 not 0. It looks like Dean's right and the comment in Atmel's code is wrong, so does that mean the Butterfly demo's using the wrong clock source? If so, how come it works?

TIA

Lloyd

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

Without getting too involved in this (it's late here), I looked at some Butterfly LCD code I wrote from scratch and I also set bit 7. My guess is that they're setting bit 7 somewhere else - did you look for any other references to LCDCRB?

As for comments, take them with a grain of salt. Not only do programmers get them plain wrong, they often change the code without updating the comments. And, just to add insult to injury, several of the datasheet examples for several devices are cut and pasted from other datasheets, so some have atrocious errors in them.

If this stuff weren't free I'd say buyer beware. Coder beware.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

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

Chuck, hi

Thanks for that. No, I haven't looked at the rest of their example code yet but I'm picking you're right: they'll have set the bit somewhere later on. Or maybe the clocks are so close in speed that it accidentally didn't matter! Yeah, comments are an interesting topic. After commenting everything in sight for years - assembler tends to need it more - I now tend to avoid using them and take more care with self-documenting code; the fewer comments, the less to get out of sync as you suggest.

Cheers,

Lloyd