2010-02-03 06:40:23     TFT

Document created by Aaronwu Employee on Aug 20, 2013
Version 1Show Document
  • View in full screen mode

2010-02-03 06:40:23     TFT

Rob Maris (GERMANY)

Message: 85533   

 

due to an analog devices announement (IP-thinking kit), I have yet gained attention to using TFT's with BF537 devices. I know about connectivity to TFT, but I'm quite sceptic about performance. An existing Atmel ARM9-with-embedded-TFT-controller-based project is targeted with an VGA TFT.

 

Porting to blackfin could be interesting. I see a limited list of displays supported by the 2.6.32 kernel. Some questions:

 

    what about CPU load when a VGA display is controlled from the PPI bus (clock approx. 25 MHz) ?

    what about approximate efforts to customize to a specific TFT?

    what about U-boot awareness of such a blackfin TFT?

 

Of course, links that discuss these questions would be OK.

 

-Rob

QuoteReplyEditDelete

 

 

2010-02-03 06:58:17     TFT

Michael Hennerich (GERMANY)

Message: 85535    Take a look here:

  docs.blackfin.uclinux.org/doku.php?id=framebuffer&s[]=tft

 

customizing for a specific TFT with CLK, VSYNC, HSYNC and RGB data isn't difficult.

Also resolutions up to 640x480 are possible.

 

I suggest to watch this video:

  docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:directfb&s[]=graphics

 

  docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:sdl&s[]=graphics

 

  docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:mplayer

 

-Michael

QuoteReplyEditDelete

 

 

2010-02-03 08:04:21     Re: TFT

Rob Maris (GERMANY)

Message: 85536   

 

Michael, thanks for your information. Regarding CPU load: is any white paper out there that outlines the concept of TFT driving without dedicated hardware? I'd wish to have an indication about CPU load of keeping any frame alive (also when display content is not altering). When I'm right, it is software that keeps the frame content alive on the display, not a typical TFT-controller entity.

 

TFT size: 640x480 absolute limit? - I'm also considering WVGA - 800x480.

 

Regarding the video you referenced to, you mean a video that runs on a target, isn't it?.

QuoteReplyEditDelete

 

 

2010-02-03 08:34:51     Re: TFT

Michael Hennerich (GERMANY)

Message: 85537    >Michael, thanks for your information. Regarding CPU load: is any white paper

>out there that outlines the concept of TFT driving without dedicated

>hardware? I'd wish to have an indication about CPU load of keeping any frame

>alive (also when display content is not altering).

 

CPU load is 0.00

It's the DMA engine that keeps updating the display - no core involved.

However your bandwidth to external memory goes down, with increased resolution,

Frame rate and pixel depth. Which also slows down your core due to external code execution.

Core and DMA share bandwidth to L3

 

Simple example QVGA 320x240 16-bit RGB565 with a 5MHz clock.

320*240*2bytes*5MHz = 768kBytes/s no a problem at all.

 

>When I'm right, it is

>software that keeps the frame content alive on the display, not a typical

>TFT-controller entity.

 

No - DMA together with the PPI and timers - are pretty much a display controller.

 

>

>TFT size: 640x480 absolute limit? - I'm also considering WVGA - 800x480.

 

There is no real limit that tells you 640x480 are max.

The limit is when the core starves the DMA, so it will cause an PPI underrun error.

800x480 should work as well - try to keep the pixel clock as slow as possible.

 

>

>Regarding the video you referenced to, you mean a video that runs on a

>target, isn't it?.

 

No the video on youtube: Graphics (SDL, DirectFB & Qt) and Video on Blackfin Linux

  www.youtube.com/watch?v=fKyQOntPEFs

 

-Michael

QuoteReplyEditDelete

 

 

2010-02-03 09:32:12     Re: TFT

Rob Maris (GERMANY)

Message: 85538   

 

Video answers also U-boot splash question. Thanks.

 

DMA, OK. Memory bandwidth is a logical consequence. This is a comparable impact as with e.g. Atmel AT91 TFT machines, where e.g. 20 % of memory bandwidth is consumed by the embedded TFT controller when  a TFT @ 16 bit colour with pixel clock of 25 MHz is used.

 

Can you provide an approximate bandwidth figure under comparable conditions?

 

BTW: much thanks for the infos supplied above!

 

QuoteReplyEditDelete

 

 

2010-02-03 10:35:48     Re: TFT

Michael Hennerich (GERMANY)

Message: 85539    >

>Can you provide an approximate bandwidth figure under comparable conditions?

 

640 * 480 * 2bytes * 25MHz = 15360 kBytes/s

Depending on System Clock 20% is a theoretical value.

 

However point is that Core/DMA and EBIU arbitration isn't ideal.

At this bandwidth a slow EBIU (shared with the SDRAM controller) access can cause a PPI underrun.

 

-Michael

Attachments

    Outcomes