search

robert-hh / SH1106

MicroPython driver for the SH1106 OLED controller
Other
157 stars 38 forks source link

Adding partial updates #22

Closed CRImier closed 2 years ago

CRImier commented 2 years ago

They needed FrameBuffer inherited method overrides, so I added those too. Tested all the methods I overrode.

robert-hh commented 2 years ago

Thank you for the PR. It will speed up operation with a slow I2C interface, but at the cost of an increased code size, RAM usage and python code being executed. For fast MCU with a lot of memory that is surely not an issue, for restricted ones like the ESP8266 it is. So the total benefit has to be analyzed.

CRImier commented 2 years ago

I specifically am running this on an ESP8266, where CPU time is precious and best spent on anything else ^__^ Main CPU cost is in the overridden drawing functions, and my tests show that any losses from overridden functions are dwarfed by the speedup of the show(). See here for a simple demo.

With regards to the RAM+flash costs, the changed page tracker is [0,..7] (8 elements) at its longest, so the main driver of cost increase would be due to overridden functions that were previously inherited. I can find some time in the near future and make some tests in case you are not in a position to do so.

CRImier commented 2 years ago

mpy-cross gives 1942 bytes for the pre-patch version and 2959 for the post-patch version, for an estimate

robert-hh commented 2 years ago

I made a timing test on a ESP8266 @ 80MHz. Freq set to 400kHz, but is actually ~150kHz. Full display redraw: ~80ms Single page ~10ms There was no significant difference between the old and new version for a full display redraw. So for small display changes, the PR improves the speed substantially. Edit: @160MHz I2C clk is 235 kHz, and full display redraw takes ~52ms.

CRImier commented 2 years ago

There was no significant difference between the old and new version for a full display redraw.

Yep, that'd be expected, since full redraw pushes all 8 pages anyway! Possible to push it further, but unless I figure out how to optimize it, it'd require a few more bytes and code than I'd be comfortable with

CRImier commented 2 years ago

Hmm. I appreciate the merge, and also - it does make sense to provide lower-footprint libraries! The 50% increase in compiled code side feels like quite a bit, in retrospect. I'd have no qualms with maintaining a fork for sped-up small display redraws, so, at any point, please do let me know if you'd rather have us work together in that dimension.

Thank you for your work!

robert-hh commented 2 years ago

I do not worry so much about the increase of the size. In case of a large project with ESP8266, one has to use frozen bytecode. I did that for the project in which I adapted the sh1106 driver initially. What could get more likely an issue is the page page, being a list. Using that will create allocations, and with the small heap allocation fails are more likely. So maybe it's better to use just bits in an single integer to flag, which page is to be drawn.

CRImier commented 2 years ago

ooh! oh yes, that's apt! I shall absolutely look into it next time I am near this project, which is likely to be very soon ^__^

robert-hh commented 2 years ago

I sketched a version. Execution times are the same, the size as well. sh1106_bitmap.zip

CRImier commented 2 years ago

Tested, this works wonderfully, and diff looks good to me!