Speed

128x128 pixel 1.5" full colour OLED display with MicroSD card slot. [Product page]
Post Reply
csconsulting
Posts: 63
Joined: Fri Sep 21, 2012 7:22 am

Speed

Post by csconsulting » Sun Sep 01, 2013 2:38 pm

Is there a datasheet to the actual controller for this device?

I would like to get faster line drawing code, i actually want to play with 3d objects and the accelerometer module for some cool stuff heh.

And when using the "secondary" connections, is that hardware SPI? or software.

There is a MCU running at 16mhz, and i definitely think there are speedups available to make this thing run stupid fast. I am thinking "sound wave displays" for an audio amp.

angusgr
Freetronics Staff
Freetronics Staff
Posts: 853
Joined: Tue Apr 09, 2013 11:19 pm
Location: Melbourne, Australia
Contact:

Re: Speed

Post by angusgr » Sun Sep 01, 2013 11:20 pm

csconsulting wrote:Is there a datasheet to the actual controller for this device?

I would like to get faster line drawing code, i actually want to play with 3d objects and the accelerometer module for some cool stuff heh.
Awesome! The controller is a Solomon Systech SSD1351. EDIT: Datasheet as PDF.

I'd be great if you could share any improvements you come up with.
csconsulting wrote:And when using the "secondary" connections, is that hardware SPI? or software.
All of the connections shown in the quickstart guide are using hardware SPI (8MHz on an AVR-based 16MHz board) for moving data.

There are some additional lines (CS, DC, RST) which are driven as standard GPIOs. This is one example of "low hanging fruit" for optimisation, because at the moment these are variable pin numbers which are driven high and low via Arduino's digitalWrite() functions. This is comparatively slow compared to direct port writes. If you tweaked the library to make them constants (ie non-configurable from the sketch) then you could change the digitalWrite()s to direct port writes, or there's a library I wrote (outside of Freetronics) a while ago called digitalIOPerformance that can rewrite them for you once they're constants.

The FTOLED library itself doesn't do this because the gains (in this case) remain relatively marginal, and it's more flexible and maintainable to use the cross-platform Arduino functions.


csconsulting wrote:There is a MCU running at 16mhz, and i definitely think there are speedups available to make this thing run stupid fast. I am thinking "sound wave displays" for an audio amp.
Excellent. :)

You may find a good place to start is the 'stripchart' example. If you pull the 'delay' option out then it updates pretty quickly already, and if you took out the text printing then it'd update even more speedily.

- Angus

csconsulting
Posts: 63
Joined: Fri Sep 21, 2012 7:22 am

Re: Speed

Post by csconsulting » Mon Sep 02, 2013 12:42 pm

Ooo thanks for the speedy reply!

I have already attacked the stripchart sketch and removed all unneccessary code down to basically measuring and drawing one analog channel only.
Its nice and fast until you get a big signal on the analog line, and the extra pixels being drawn significantly slow down the refresh rate.

I will have to see if its the line code, or the pixel code thats actually causing the slow down, i guess my first point of attack would be the simple comms to the display and the single pixel code that could be optimised.
I bought the accelerometer module today, so will be having a play soon with some old legacy 3d code from my Qbasic 4.5 days!


Oh EDIT!
Just found out that one of my favourite libs (u8glib) has been updated to support this exact chip.

https://code.google.com/p/u8glib/wiki/gallery

csconsulting
Posts: 63
Joined: Fri Sep 21, 2012 7:22 am

Re: Speed

Post by csconsulting » Tue Sep 03, 2013 6:25 am

Just found something that doubles the speed of some of the operations.

https://code.google.com/p/digitalwritef ... p&can=2&q=

csconsulting
Posts: 63
Joined: Fri Sep 21, 2012 7:22 am

Re: Speed

Post by csconsulting » Tue Sep 03, 2013 7:33 am

I have gotten the following code down to a benchmark value of 2314 ms from the original of 7020ms.

Thats under a third of the original speed.


That has involved the hardcoding of the pins used however.
And the use of digitalWriteFast2, plus some inlining of the SPI code.

I have edited FTOLED.h a bit to speed it up, especially the writeCommand and writeData segments.

edit: now down to 2292ms.

Code: Select all

// the FTO led code is hardcoded to use 7 and 2.


const byte pin_cs = 7;
const byte pin_dc = 2;
const byte pin_reset = 3;

#include <SPI.h>
#include <SD.h>
#include "FTOLED.h"
#include "fonts/SystemFont5x7.h"

OLED oled(pin_cs, pin_dc, pin_reset);
// Text box takes up bottom 32 characters of the display (ie 4 rows)

OLED_TextBox box(oled);

long TStart;
long TFinish;


void setup() {
  oled.begin();
  oled.selectFont(System5x7);
  box.setForegroundColour(OLDLACE);
}

void loop() {

  int x;
  int y;
  int c;
  Colour PIX;
  
  
  TStart=millis();
  
  for(c=0;c<7; c++){
  
  PIX.red=c;
  
  for(y = 0; y < 127; y++) {
    for(x = 0; x < 127; x++) {
     oled.setPixel(x, y, PIX);
    }  
  }
  }
  TFinish=millis();
  
  box.print(TFinish-TStart);
  
  delay(1000);
}

angusgr
Freetronics Staff
Freetronics Staff
Posts: 853
Joined: Tue Apr 09, 2013 11:19 pm
Location: Melbourne, Australia
Contact:

Re: Speed

Post by angusgr » Tue Sep 03, 2013 9:22 am

Good to hear. Calling setPixel() will definitely benefit the most from the faster writes on the other pins, because it has to assert/deassert CS and DC each time it runs, as well as set up the column/row for the data write.

(To see what I mean, try calling fillScreen(c) instead of the x/y loop - much faster once all the pixels are written from inside one single SPI transfer. This is an optimisation path you may want to consider as your next step once you figure out your approach for the 3d stuff.)

For what it's worth I would still recommend using DigitalIOPerformance over DigitalWritefast though, and not only because I wrote DigitalIOPerformance. ;). The DigitalWriteFast library isn't updated for the Leonardo compatible boards and it's also not type safe, although it's the exact same concept (I just took their idea and expanded on it a bit.) :)

- Angus

angusgr
Freetronics Staff
Freetronics Staff
Posts: 853
Joined: Tue Apr 09, 2013 11:19 pm
Location: Melbourne, Australia
Contact:

Re: Speed

Post by angusgr » Tue Sep 03, 2013 9:25 am

csconsulting wrote: Just found out that one of my favourite libs (u8glib) has been updated to support this exact chip.

https://code.google.com/p/u8glib/wiki/gallery
This is great news. There will probably be one small tweak required before it works with the OLED128 module, because on that module we enable/disable the higher voltage power for the OLED (a 15V boost converter power supply is onboard the OLED128) by toggling GPIO0 on the SSD1351 itself (it has two GPIOs built in.)

Should be very simple to add support now, though.

csconsulting
Posts: 63
Joined: Fri Sep 21, 2012 7:22 am

Re: Speed

Post by csconsulting » Tue Sep 03, 2013 9:59 am

Ahh that explains why that u8glib worked but was incredibly dark. It wasnt turning on the supply.

That benchmark test was only designed to see if i could tweak setpixel, it didnt seem to make much of a difference to text.

It DID make drawing lines a LOT faster though!

Post Reply