11 Oct
2010
11 Oct
'10
10:50 p.m.
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