Using LCD controller AT91SAM9G46 through VGA

This forum is for users of Microchip MPUs and who are interested in using Linux OS.

Moderator: nferre

rpalencia
Posts: 1
Joined: Wed Jan 07, 2015 7:14 pm

Using LCD controller AT91SAM9G46 through VGA

Thu Jul 23, 2015 6:32 pm

Hi,

We have a board with at91sam9g46 and linux kernel 2.6.30.
We have configured some tft right with 640 x 480 and 16 bpp.
Actually, we have to use new tft through vga, also in 640 x 480 but with 24 bpp.
Our configuration is:

Code: Select all

#define AT91SAM9G45_DEFAULT_LCDCON2 	(ATMEL_LCDC_MEMOR_LITTLE \
					| ATMEL_LCDC_DISTYPE_TFT \
					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)

static struct fb_videomode at91_tft_vga_modes_iberhDisp57[] = {
        {
                .name           = "IberHer 5.7",
                .refresh        = 60, //hz
                .xres           = 640,          .yres           = 480,
                .pixclock       = KHZ2PICOS(26082), //27690 clock
        .right_margin   =50 , /*10,*/ //Horizontal Back/Front Porch
				.left_margin    = 50,/*144,*/          .right_margin   =80 , /*10,*/ //Horizontal Back/Front Porch
                .upper_margin   = 33,/*35,*/           .lower_margin   = 10,/*7,*/ //Vertical Upper/Lower Porch
                .hsync_len      = 58,/*30*/           .vsync_len      = 2, //Horizontal/Vertical Pulse Width

                .sync           = 0,
                .vmode          = FB_VMODE_NONINTERLACED,
        },
};
static struct fb_monspecs at91fb_default_monspecs_iberhDisp57 = {
       .manufacturer   = "IBH",
       .monitor        = "IBH-5.7",

       .modedb         = at91_tft_vga_modes_iberhDisp57,
       .modedb_len     = ARRAY_SIZE(at91_tft_vga_modes_iberhDisp57),
       .hfmin          = 32500,//15000,
       .hfmax          = 64000,
       .vfmin          = 61,//50,
       .vfmax          = 150,
};
static struct atmel_lcdfb_info __initdata ek_lcdc_data_iberhDisp57 = {
        .lcdcon_is_backlight            = true,
        .default_bpp                    = 24,
        .default_dmacon                 = ATMEL_LCDC_DMAEN,
        .default_lcdcon2                = AT91SAM9G45_DEFAULT_LCDCON2 | ATMEL_LCDC_PIXELSIZE_24,
        .default_monspecs               = &at91fb_default_monspecs_iberhDisp57,
        .guard_time                     = 9,
        .lcd_wiring_mode                = ATMEL_LCDC_WIRING_BGR,
};
Our problem is, we can see images with a resolution smaller than 640 pixels (axis x), 639 x 480 pixels is right, but when we want show a image with a resolution of 640 pixels, all image loose the right colour and it seems with less quality.

Looking for the problem we made a simple application that makes mmap over /dev/fb0, and it let us painting pixel by pixel to check RGB is show correctly.

While we are painting from 0 to 638 pixels it works good, problems comes when pixel 639 is painted. No problem, painting from 0 to 479.

We've been watching with an oscilloscope signal periods and their duty cicle, in RGB bits. Almost, they are similar as tft 16 bpp without vga as this tft 24 bpp with vga.
We can see a signifcant difference in the duty cicle of color signal when we paint in the pixel 640.

For example,
We meassure a bit of red colour, and paint from 0 to 200 pixel in x and 0 to 480 in y. Our meassure are for a period of 32 us, about 8 us this signal is a high.
Then, we paint from 0 to 400 pixel in x and 0 to 480 in y. Our meassure are for a period of 32 us, about 16 us this signal is a high.
Then, we paint from 0 to 638 pixel in x and 0 to 480 in y. Our meassure are for a period of 32 us, about 26 us this signal is a high.
And now the problem comes we paint from 0 to 639 pixel in x and 0 to 480 in y. About 31.8 us this signal is a high.



We can't understand why it is to high so much time.
In this situation the falling edge of hsync is not synchronized with the color signal.

Neither we do know if this is because images with 640 pixels are not right.

Perhaps, tft without VGA doesn't have the problem, because doesn't have a DAC in the middle.

Somebody knows how we can modify the time of the color bit is to high? Or why we have this strange problem?

Thanks in advanced,
Regards

Return to “Linux”

Who is online

Users browsing this forum: No registered users and 1 guest