I received it today and I connected it with jumper wires to FEZ Panda.
I tested the performance of the Flush() method and got ~20ms per call.
I tried different things to optimize it and the best improvement was obtained replacing Locate() with this code :
I had tried your new method on my application. (My Console app that went to the Makers Faire).
And It’s amazingly faster than before, and can be noticed with the bear eyes!
I can cleary see the different between the previous method and your method.
Remember Sam, I told there are many thing you can do to make it faster. His optimization is on full screen refresh but you can do partial screen refresh I think.
Just for fun I tested both the array copy and locate by themselves by commenting out everything else in ‘Flush’ and came up with the following times. (Same method by calling 100 times in a loop).
Array copy: 0.0799 seconds
Locate: 0.5201 seconds
I was surprised that the bulk of the time is still spent in Locate.
Instead of calculating the values with Locate each time (since they are the same each time you do a flush) I modified flush like this:
static public void Flush(byte[] vram)
{
locate[0] = 176; locate[1] = 16; locate[2] = 0;
for (int i = 0; i < 8; i++)
{
_DC.Write(false);
locate[0] += (byte)i;
_spi.Write(locate);
//Locate(0, i);
//Array.Copy(vram, i * 128, one_line, 0, 128);
//_DC.Write(true);
// _spi.Write(one_line);
}
}
I obtained the values for the ‘locate[]’ array by dumping out what the location function was generating. This took the ‘locate’ portion of the flush time down to 0.4872 seconds for 100 flushes. Not really a big improvement. So perhaps the SPI write to set the location is taking a lot of time? Commenting that line out showed that 100 cycles now takes 0.1263 seconds.
Anyhow, I thought this was an interesting topic and I’m glad it got started.
A few other things to play with: this little display is really pretty fast and has internal buffers so you can really feed data to it fast. I changed the SPI configuration to what is shown below and not see a 100 cycle flush time of 0.8773 seconds! After about 5 minutes of running the display did goof up so I’m guessing that the SPI clock is too fast (just trying to see how fast it would go The SPI clock does not have as big an effect as lowering the chip select setup and hold times. I just set the SPI clock back down to 10,000kHz and it seems pretty stable (but this is still a wee bit optimistic I think.)
