Search |
 |
|
 |
| Author |
Message |
|
|
 Posted: Mar 19, 2007 - 10:17 PM |
|
Joined: Feb 16, 2007
Posts: 15
|
|
Greetings,
I'm trying to interface a 16-bit TFT LCD (with a standard 5:6:5(R:G:B) interface) to the AVR32, and want to make sure I don't have any signals crossed.
On Page 818 of the 02/07 datasheet, there's a bit of confusion in Table 35-12. The table calls out 16-bit LCD in the right most column, yet the signal descriptions suggest 18 bits., @ 6-bits/color.
Curious if anyone else has experienced this confusion, and has any suggestions how to best map the pins correctly.
TIA, Ace
{Edit:} At the moment, I have the mapping of: LCD red0 -> LCDD[3] and LCD blu0 -> LCDD[19] |
Last edited by AceyTech on Mar 23, 2007 - 03:51 AM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Mar 22, 2007 - 08:54 AM |
|
Joined: Feb 16, 2007
Posts: 15
|
|
|
|
|
|
|
|
Posted: Mar 22, 2007 - 09:53 AM |
|
Joined: Apr 26, 2006
Posts: 1079
Location: Trondheim, Norway
|
|
It looks like the suggested interface is 5:5:5 with common intensity bit, adding up to 16 digital signals. However, I think the LCDC has a fairly straightforward data path from the framebuffer to the output signals, so I wouldn't be surprised if you could actually use a standard 5:6:5 format even though it isn't "officially" supported by the documentation. That is, you use the intensity bit as the most significant blue bit and the least significant blue bit as the most significant green bit.
In other words:
RED[3..7] => RED[0..4]
GREEN[3..7], BLUE[3] => GREEN[0..5]
BLUE[4..7], BLUE[2] => BLUE[0..4]
Does this make sense? |
|
|
| |
|
|
|
|
|
|
Posted: Mar 23, 2007 - 01:13 AM |
|
Joined: Sep 14, 2003
Posts: 4228
Location: Queanbeyan, Australia
|
|
OK, makes sense to me.
Would you need to change anything but the colour offsets and lengths in sidsafb.c -> sidsafb_check_var() to reflect the longer green field? The author seems a little confused in that function regarding the intensity bit:
Code:
switch (var->bits_per_pixel) {
[...]
case 15:
case 16:
/*
* Bit 16 is the "intensity" bit, I think. Not sure
* what we're going to use that for...
*/
var->red.offset = 0;
var->green.offset = 5;
var->blue.offset = 10;
var->red.length = 5;
var->green.length = 5;
var->blue.length = 5;
break;
That is, it doesn't look like the most significant bit of a 16 bit pixel, the intensity bit, can ever be set by this driver. The 16 bit pixel gets treated the same way as a 15 bit pixel.
His comment does seem to reflect what you're saying though, that if the green field is extended up a bit in the 16 bit case then the LCD's MS blue bit would be driven by the intensity bit.
Hmmm.. Maybe trial and error time 
-S |
|
|
| |
|
|
|
|
|
|
Posted: Mar 23, 2007 - 03:45 AM |
|
Joined: Feb 16, 2007
Posts: 15
|
|
Thanks for the responses fellas! Here's how I have it connected., I've left it open so that if I need to reorder the bits, It's only a bit of work under the microscope... (good thing I'm using 0201 pkg resistors... this is gonna be fun)
Page 804; section 35.6.2.5, last paragraph. It reads:
Code:
In TFT mode, all the bits in the blue, green and red values are used (32768 colors). In this mode,
there is also a common intensity bit that can be used to double the possible colors. This bit is the
least significant bit of each color component in the LCDD interface (LCDD[18], LCDD[10],
LCDD[2]). The LCDD unused bits are tied to 0 when TFT palletized configurations are used
(LCDD[17:16], LCDD[9:8], LCDD[1:0]).
@HOW: I'm pretty confused actually. I can't find anything in the datasheet that supports your mapping method.
Perhaps that's more documentation that's in the source code as opposed to the datasheet. It's quite frustrating to have a 938 page datasheet for a part, yet so much of the useful data is in the source code.
I'd really love to hear from an Atmel hardware person what they think the 16 bit mapping should be for a TFT panel.
Again, thanks for the responses, AceyTech... |
|
|
| |
|
|
|
|
|
|
Posted: Mar 23, 2007 - 11:01 AM |
|
Joined: Apr 26, 2006
Posts: 1079
Location: Trondheim, Norway
|
|
It would probably be a good idea to modifiy the bitfields returned by the driver, yes. But AFAIK those are only advisory, so if you're writing the test code yourself, you're free to ignore the driver's advice
It looks like you've wired the intensity bit to G0, right? That would probably work if you _do_ use the MSB as an intensity bit (although it will only affect the green signal) but I don't think it will work with a 5:6:5 framebuffer format.
I think the reason why the 16-bit panel setup isn't documented is that it isn't actually a supported configuration. So you should only follow my advise if you're prepared to do a bit of testing, i.e. modify the color bitfields, compile a standard fb application and see if it works. If you're wiring the intensity bit to B4, it should be very visible if it doesn't work... |
|
|
| |
|
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
