How to speed up the ARM code?

[GoogleCodeExporter]

Using the ARM port of u8glib didn't really increase the frame rate (or the time 
it takes to draw a frame) to what I need for my application (freescale 
mk20dx128, ssd1351_128x128, need some spare time to do other processing).

The first thing I tried was to not wait for each byte to be transferred 
completely, but using the built-in 4-byte SPI FIFO. Waiting for the whole 
transmission to be completed did indeed save some time.

I thought about transferring the display data to the SPI with DMA, but that 
turned out to be _very_ hard due to the procedural nature of the picture loop 
and the internal interfaces between u8glib and the device. Also, the number of 
bytes that are transferred at a time (3*RGB_332_STREAM_BYTES in my case) is 
quite low, so the added overhead might even result in slower processing. I 
tried just increasing RGB_332_STREAM_BYTES, but that didn't work (trashed 
output).

Any ideas? Do you think this is feasible at all?

Original issue reported on code.google.com by avrbegin...@googlemail.com on 17 Oct 2013 at 9:35

[GoogleCodeExporter]

Which device do you use?  u8g_dev_ssd1351_128x128_4X_332_hw_spi should be the 
fastet solution.

Original comment by olikr...@gmail.com on 18 Oct 2013 at 4:50

[GoogleCodeExporter]

I'm using u8g_dev_ssd1351_128x128_4X_332_hw_spi and a frame takes about 62 ms. 
With the non-4x variant, a frame needs 75 ms and with a self-made "8x" device, 
it's 59 ms (so the increase in speed between 4x and 8x really isn't worth it, I 
think).

Much of the CPU time is wasted waiting for the SPI. 128x128x3 bytes at 8 MHz 
SCK need about 50 ms (please tell my if my numbers are wrong here).

Original comment by avrbegin...@googlemail.com on 18 Oct 2013 at 9:36

[GoogleCodeExporter]

some measures are here:
http://code.google.com/p/u8glib/source/browse/sys/arduino/FPS/FPS.pde
Your results are already quite good

U8glib has been optimized for 
- controllers with small amount of RAM
- Monochrome SPI displays

Original comment by olikr...@gmail.com on 18 Oct 2013 at 5:49

• Added labels: Milestone-1.15, Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

I'll post measurement results for my system when I'm working on it again.

Original comment by avrbegin...@googlemail.com on 18 Oct 2013 at 6:36

[GoogleCodeExporter]

Should the visible output of the draw clip test be "pretty"? The text showing 
the results is OK.

some triangles in the upper left corner and some rotated text here and there: 
draw clip 012.1
blue-ish waves from top to bottom: clear screen 007.0
@-signs all over the display: draw @ 008.0
1-pixel checkerboard: draw pixel 005.1

Original comment by avrbegin...@googlemail.com on 19 Oct 2013 at 9:21

[GoogleCodeExporter]

If you see triangles, then everything is ok

Original comment by olikr...@gmail.com on 19 Oct 2013 at 2:59

[GoogleCodeExporter]

closing this...

Original comment by olikr...@gmail.com on 22 Jan 2014 at 8:05

• Changed state: Done