Hi,
I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles.
It currently supports the C123 and the C155, the only two phones I own.
On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte
- we need a way to select between individual fonts
...
Something like display_select_font(FONT_5x8) to be called before a display_puts() sounds like a reasonable API for this.
the current API looks like this:
fb_clear();
fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14);
fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4);
fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE);
fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38);
fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4);
fb_flush();
Which results in an output such as:
http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg
- If we want to support arbitrary sized fonts, we either should buffer the display in RAM (might be wasteful on high res color displays?)
...
This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes.
- Removing all the special characters might not be the best idea to do.
If at all, it should be a compile time option whether or not to drop the special characters. Also, the check for replacing a character with '?' needs to be a font-specific and not a global decision.
This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts.
I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff
It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above.
It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done.
Please send me your comments on that patch.
Greetings from the Dillberg,
Chris
Two things I did want to mention, but forgot to write in my first email are:
(1) For future work, it should be attempted to call the synchronisation of the framebuffer memory and the LC display in a low-priority task or timer so that the fb_flush() method that blocks on updates is no longer necessary
(2) The price we pay for having the framebuffer, in terms of object-size, is detailed below, by comparing the original version of hello_world with the "new and improved" framebuffer.
Comparing hello world before/after transition to framebuffer code.
For hello world on E88 (C123) (with HelvR08 and HelvB14 fonts):
.text +1696 byte (grows from 0x3fd0 - 0x3930) .rodata +944 byte (0xc76 - 0x1026) .data +80 byte (0x15c - 0x10c) .bss +860 byte (0x4470 - 0x47cc)
For hello world on E99 (C155) (w/ HelvR08, HelvB14):
.text +1344 byte .rodata +1088 byte .data +80 byte .bss +6564 byte
Generally .rodata is mostly due to font data, .bss is our in-ram framebuffer. .text increase is due to the code for character- and box drawing.
Individual sizes:
$ /usr/opt/arm-gcc/bin/arm-elf-size *.o text data bss dec hex filename 1873 0 0 1873 751 fb_bw8.o (C123 ) 1764 0 0 1764 6e4 fb_rgb332.o ( C155) 706 72 6568 7346 1cb2 fb_ssd1783.o ( C155) 328 72 864 1264 4f0 fb_st7558.o (C123 ) 76 8 0 84 54 font.o (C123, C155) 0 0 0 0 0 framebuffer.o (C123, C155) 1804 0 0 1804 70c helvB14.o (C123, C155) 1212 0 0 1212 4bc helvR08.o (C128, C155)
(Currently unused, optional further fonts:) 60 56 0 116 74 fb_dummy.o 1220 0 0 1220 4c4 helvB08.o 3548 0 0 3548 ddc helvB24.o 3480 0 0 3480 d98 helvR24.o 1116 0 0 1116 45c 4x6.o 1188 0 0 1188 4a4 5x8.o
Old display code (everything compiled in for all mobiles): 88 0 0 88 58 display.o 2048 0 0 2048 800 font_r8x8_horiz.o 2048 0 0 2048 800 font_r8x8.o 920 0 0 920 398 ssd1783.o 399 0 0 399 18f st7558.o 638 0 0 638 27e td014.o
baseband-devel@lists.osmocom.org
-
Christian Vogel