Closed GoogleCodeExporter closed 8 years ago
Thanks for the issue.
However, the picture loop is a basic feature of u8glib. In fact u8glib has been
build around the picture loop. Replacing the picture loop with a frame buffer
would mean to write a complete new library. A Framebuffer is can not be an
enhancement. Its a new lib.
This topic has been discussed in much more detail here:
http://arduino.cc/forum/index.php?&topic=91395.90
What i can do: I could extend the page buffer for specific displays for speed
up.
To do this, i need to know which display you use.
I am sorry that i can not implement this.
Oliver
Original comment by olikr...@gmail.com
on 16 Jan 2013 at 5:43
Oliver,
Could you make parameter "page buffer size" configurable?
Original comment by dzmitry....@gmail.com
on 16 Jan 2013 at 10:32
Oh, I forgot, I use ST7920.
Original comment by dzmitry....@gmail.com
on 16 Jan 2013 at 10:38
What i can do, is to increment page size for ST7920, so that the number of
iterations gets reduced for the picture loop.
Original comment by olikr...@gmail.com
on 16 Jan 2013 at 11:22
Original comment by olikr...@gmail.com
on 16 Jan 2013 at 11:22
How big can you make the page buffer?
Original comment by dzmitry....@gmail.com
on 16 Jan 2013 at 11:51
Usually i implement a device with doubled memory, but also 4x or 8x page size
is possible (also requires more programming effort). In fact i could increase
it up to the frame buffer size, but only for individual graphics devices. But
picture loop will still be there.
I would suggest to implement doubled memory and let you decide if this is
sufficient for your speed requirements.
Original comment by olikr...@gmail.com
on 16 Jan 2013 at 12:04
One more question: What are your screen dimensions? 128x64?
Original comment by olikr...@gmail.com
on 16 Jan 2013 at 12:05
I would be appreciated if you increase page buffer size up to frame buffer
size. And yes I use ST7920 128x64.
Thanks for your help.
Original comment by dzmitry....@gmail.com
on 16 Jan 2013 at 12:23
Original comment by olikr...@gmail.com
on 27 Jan 2013 at 6:44
current memory architecture is pb8h1. pb16h1 exists
Original comment by olikr...@gmail.com
on 24 Feb 2013 at 10:42
added pb32h1
ToDo
- constructor update
- testing
- port to 128x64
- dev table update
Original comment by olikr...@gmail.com
on 27 Feb 2013 at 9:22
fps:
ST7920_192X32_1X, SPI: FPS: Clip=10.3 Box=5.5 @=7.2 Pix=3.9
ST7920_192X32_4X, SPI: FPS: Clip=10.9 Box=6.7 @=8.8 Pix=7.4
ST7920_192X32_1X, 8Bit: FPS: Clip=14.2 Box=6.1 @=8.4 Pix=4.2
ST7920_192X32_4X, 8Bit: FPS: Clip=14.2 Box=7.8 @=10.7 Pix=8.7
ToDo
- port to 128x64 (and the 202...device)
- dev table update
Original comment by olikr...@gmail.com
on 2 Mar 2013 at 7:53
update:
ST7920_192X32_1X, SPI: FPS: Clip=10.3 Box=5.5 @=7.2 Pix=3.9
ST7920_192X32_4X, SPI: FPS: Clip=10.9 Box=6.7 @=8.8 Pix=7.4
ST7920_192X32_1X, 8Bit: FPS: Clip=14.2 Box=6.1 @=8.4 Pix=4.2
ST7920_192X32_4X, 8Bit: FPS: Clip=14.2 Box=7.8 @=10.7 Pix=8.7
ST7920_192X32_1X, HW SPI: FPS: Clip=14.2 Box=6.3 @=8.7 Pix=4.3
ST7920_192X32_4X, HW SPI: FPS: Clip=15.3 Box=8.0 @=11.2 Pix=9.0
port to 128x64 and 202x32 done
... hope that the 4x mode is fast enough ...
todo:
device table
Original comment by olikr...@gmail.com
on 2 Mar 2013 at 9:43
todo: document 4x modes in device table
Original comment by olikr...@gmail.com
on 2 Mar 2013 at 10:00
documentation finished
Original comment by olikr...@gmail.com
on 2 Mar 2013 at 9:06
Original issue reported on code.google.com by
dzmitry....@gmail.com
on 15 Jan 2013 at 10:33