|
Authors: jcw
The Graphics Board is going to enable a bunch of fun projects around here.
Unfortunately, the ST7565 library is a bit slow in one specific way – display updates. Since everything is buffered in RAM, most other operations are actually quite fast, but to get that data onto the gLCD takes time.
I had to find out how much time, of course. Here’s my test sketch:
All the loop does is send the same RAM buffer contents to the display, over and over again. The time it takes in microseconds is sent to the serial port, and the result is quite bad, actually:
- 126 milliseconds, i.e. 8 refreshes per second, max!
The good news is that it’s a clear bottleneck, so chances are that it can be found and then hopefully also avoided. Sleuthing time!
The ST7565 core primitives, responsible for getting the data out to the display were coded as follows:
Guess what: the shiftOut() in the Arduino library is written with calls to digitalWrite(). That rings a bell.
Ah, yes, good OLD digitalWrite() again, eh? Of course …
So I rewrote this code using fixed pin numbers and direct port access:
And sure enough, it’s almost exactly TEN times faster:
- 12.3 milliseconds, i.e. 80 refreshes per second.
Needless to say, I’m going to leave these changes in my copy of the ST7565 library – even though that means it’s no longer general purpose since the pin assignments are now hard-coded. A 10-fold performance increase of something which really needs to be snappy and responsive is non-negotiable for me.
Here is a copy of the ST7565 code I use.
Could this bottleneck have been avoided?
The ST7565 library was clearly written as general purpose library, so making it usable with any set of pin assignments makes a lot of sense. The price paid in this case, was a 10-fold drop in performance, plus a few extra bytes of RAM used in the ST7565 class.
I’ll revisit this topic some other time, to discuss the trade-offs and implications of compile-time vs run-time logic, as well as tricks such as: putting the pin choices in a header file, using #include for source files, pre-processing and code generation, and C++ templates.
For now, I’m just happy with the 80 Hz refresh rate :)
Read more: |
