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