drawLine performance v0.69b64 vs. v0.70b11p11

[242bpm]

Hi,

i figured out that there is a big difference in performance between these 2 versions. Version v0.69b64 (shipped with the teensy software - located in "hardware" folder) draws lines much faster than the latest version.

For example:

drawing vertical lines one by one from left to right.

v0.69b64 ~ 650 iterations/min (still shipped with teensy software) v0.70b11p11 ~ 250 iterations/min (github version)

tested with teensy 3.2 at 72MHz and Eastrising 7" display

#include <SPI.h>
#include <RA8875.h>

#define RA8875_CS         10 
#define RA8875_RESET      9                 

RA8875 tft = RA8875(RA8875_CS, RA8875_RESET);

int moves;

void setup(){
  tft.begin(RA8875_800x480);
  randomLines();
}

void randomLines() {
  uint16_t k;
  //draw vertical lines 1 by 1 from left to right
  for (k = 0; k < tft.width(); k++) {
    tft.drawLine(k, tft.height() - 150, k, random(200, 300), random(0x00FF, 0xFFFF));
  }
}

void loop(){
  randomLines();
  moves++;
  tft.setCursor(50, 100);
  tft.print(moves, DEC);
}

I already compared the drawLine funtions at the source code but could't find a code change resposible for the performance change.

Any idea ... is pjrc distributing an optimized version?

Steffen

[sumotoy]

No, it's should a really stupid thing, try to see if #define USE_ADAFRUIT_PHASE_FIXUP in settings file is commented, it should be commented or the speed drops down!

[242bpm]

Hi, there are some things wrong with USE_ADAFRUIT_PHASE_FIXUP-condition in RA8875Registers.h.

1.) USE_ADAFRUIT_PHASE_FIXUP can't be set, as user settings are not loaded at that point, right? 2.) Even with the "right?" include order - for me the opposite is the case - the performance drops when USE_ADAFRUIT_PHASE_FIXUP is UNDEFINED.

For now i changed:

if !defined(USE_ADAFRUIT_PHASE_FIXUP)

const static uint8_t sysClockPar[3][2] = { //{0x0B,0x01},//0 -> 320x240 -> {0x0B,0x02},//1 -> 480x272 -> 0 //{0x0B,0x01},//2 -> 640x480
{0x0B,0x02},//3 -> 800x480 -> 1 {0x0B,0x02} //4 -> 800x480_ALT -> 2 };

else

const static uint8_t sysClockPar[3][2] = { //{0x0B,0x01},//0 -> 320x240 -> {0x0B,0x01},//1 -> 480x272 -> 0 //{0x0B,0x01},//2 -> 640x480
{0x0B,0x01},//3 -> 800x480 -> 1 {0x0B,0x01} //4 -> 800x480_ALT -> 2 };

endif

to: const static uint8_t sysClockPar[3][2] = { //{0x0B,0x01},//0 -> 320x240 -> {0x0B,0x01},//1 -> 480x272 -> 0 //{0x0B,0x01},//2 -> 640x480
{0x0B,0x01},//3 -> 800x480 -> 1 {0x0B,0x01} //4 -> 800x480_ALT -> 2 };

and it runs as fast as v0.69 again :-)

However, i'm no c++ expert (so far my biggest c++ task was to debug this) ... so please take my 5 cents with caution ;-)

Btw. ... thanks for the cool library :-) With this issue fixed i can start coding my swipeable audio wave form display ... hope Teensy 3.2 + the display have enough power for it. BTE_move + drawLine are a good team so far :-)

[sumotoy]

thanks for test. I'm gonna update this for compatibility with ES8266 soon so I will take a look to this. The damn adafruit patch was created for some adafruit TFT that are so slow that the whole library is useless to me. The patch modify the Clock internal divisor, maybe it need a revision.

[PlastiBots]

Really looking fwd to that ESP8266 update. Max. I've got an Adafruit Huzzah and a NodeMCU ESP that I want to try to get working with a BuyDisplay RA8875+TFT. Let me know if I can help test.

[sumotoy]

There's an undocumented (till now) hardware issue on ESP8266 related on SCLK, all my ESP8266 modules (I have 15 here) shows a very weak SCLK signal so the SPI isolator I have designed for solve SPI compatibility won't work, I'm currently experimenting with different buffer chip and I will get a solution soon.