2008-05-02 11:34:44 Framebuffer Driver and Microwindows
Michal Steyn (AUSTRIA)
I am working on a custom Blackfin system (designed by an outsourced company). We are using a Blackfin -BF549 processor, with a simple LCD connected (See schematic).
The LCD employs a ST7565P LCD controller (very similar to the popular TOSHIBA T6963C LCD Driver). It is a monochrome graphics LCD (without text support) and has a resolution of 65 x 132.
As the LCD is a graphics LCD I would like to use Microwindows, to write text and graphics to the LCD. I have found commercial libraries on the Internet that can drive these LCD's such as RamTex and EasyGui, but they are all very expensive. It would help a lot if I can use Microwindows.
I am not a Linux expert, and I have tried (without much luck) to obtain more info on writing Framebuffers, but I would REALLY like to AVOID going down that alley.
My questions are thus as follows:
Does anybody have a simple Framebuffer Driver, for these Simple LCD’s that I can use?
If not, how difficult would it be to modify existing Framebuffers that comes with the Blackfin?
Would it be overkill to use Microwindows on such a small display? If so, are there any good alternatives?
Are there hardware requirement in order to use a frame buffer? Ex, the way you connect the LCD to the Blackfin? We simply connected our LCD (All the pins, Data, CS, RD, WR, CD) directly to a general purpose IO Port. (See schematic attached.)
Can you use Microwindows without using a Framebuffer? Like using some direct way?
If I can't get a Framebuffer to work I might have to buy one of those commercial packages, or write my own simple "window manager" / graphic library, but I would like to avoid this if possible.
Please send me any advice.
2008-05-02 17:44:33 Re: Framebuffer Driver and Microwindows
Mike Frysinger (UNITED STATES)
there really is no such thing as a "simple framebuffer driver" as you need to manage the PPI and DMA for any display hooked up to the Blackfin, nor is there any "direct way" to use microwindows. the framebuffer is the direct way.
i dont know what your graphical needs are, but you could also evaluate DirectFB and SDL as those tend to be pretty light weight
unless someone already wrote a driver for the device you're using, or a similar one, you'll have to write your own. there are plenty of examples in the kernel in the drivers/video/ subdirectory.
2008-05-05 07:48:32 Re: Framebuffer Driver and Microwindows
Michael Hennerich (GERMANY)
>Does anybody have a simple Framebuffer Driver, for these Simple LCD?s that I can use?
This display using this LCD controller is more like an alphanumeric display.
I don't think there is a dev/fb driver for such displays.
Since you can't map the Video RAM somehow into the Blackfin Memory Map it's pointless doing a dev/fb driver for it.
(pixels are set using a command sequence)
>If not, how difficult would it be to modify existing Framebuffers that comes with the Blackfin?
It's possible - but you would need to periodically sync the display with the framebuffer memory exported using dev/fb.
For me this sounds like a No-Go...
>Would it be overkill to use Microwindows on such a small display? If so, are there any good alternatives?
In general this display is pretty small.
I would use a display without graphics controller and only a timing controller. Such as SHARP LQ035Q1DH02 (QVGA 16-bit Color TFT).
You can alternatively use similar 4/8 bit monochrome displays.
Then connect it to the PPI. (HSYNC, VSYNC, CLK, Data). For more information see BF548-EZkit schematics.
>Are there hardware requirement in order to use a frame buffer? Ex, the way you connect the LCD to the Blackfin? We simply connected our LCD (All the pins, Data, CS, RD, WR, CD) directly to a general purpose IO Port. (See schematic attached.)
>Can you use Microwindows without using a Framebuffer? Like using some direct way?
If you still want to use such as display hooking it up to GPIOs is ok.
Have a look here:
You could do a similar driver for your display hooked up to GPIOs. Then provide a microwindows/nano-X display driver that talks to your driver instead of /dev/fb.