Remove unnecessary delays from SSD1306 SPI transfer code #756
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
for my recent project I'm using a small SSD1306 display, 128x32, over SPI.
I've noticed that the SPI communication code - the tx function - has 1ms delay for each SPI transfer, which is quite a lot even if considered a "safety margin". There's 7ms of total delay introduced each time new screen contents are sent (set column address, set page address, then send buffer data). Actually, on lower performance microcontrollers this can be as much as 10ms, as tested with custom SAMD21 board. This makes it impossible to create an application that tries to target 60fps - games, smooth UI, etc.
This behaviour was introduced with the very first version of SSD1306 driver. I guess this went unnoticed because most of the time 128x64 displays are used, and registers are not updated in that case. The delay of 1.5ms was simply less of a problem than 10ms.
As an example, MicroPython SSD1306 library does not have any delay before each transaction. TinyGo SH1106 driver has 1µs (not 1ms), but based on comments even such tiny delay may be unnecessary.
I also fail to see why CS pin needs to be pulled high before DC pin is changed, but since other implementations have this logic let's keep it as is.