luma.oled
luma.oled copied to clipboard
rm-hull
Only 1.06 fps with ssd1327
I'm sure the issue is mine, but I've yet to figure out what it is. The ssd1327 produces a very poor frame rate:
Linux orangepizero 4.14.18-sunxi #24 SMP Fri Feb 9 16:24:32 CET 2018 armv7l GNU/Linux
Waveshare SSD1327 (https://www.amazon.com/gp/product/B079KRC9X3) in i2c bus (tried both 0 and 1).
perfloop.py -d ssd1327 --width 128 --height 128 --i2c-port 1 --i2c-address 0x3d produces a whopping 1.06 fps.
What do I do to improve this frame rate?
That is truely terrible.
What version of python are you using?
You should:
- check what the system load is
- check memory usage and see how much swap is being used
- see what the cpu temperature is and if the cores are being throttled
- try using a raspberry pi zero for comparison
my personal experience with opizero shows they have poor performance characteristics generally.
Thanks for the quick reply.
Python 2.7.13
While running perfloop.py for several minutes, armbianmonitor -m yields:
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 11:50:11: 1200MHz 1.16 5% 2% 2% 0% 0% 0% 56.1°C 0/8 11:50:16: 1200MHz 1.14 5% 2% 2% 0% 0% 0% 56.5°C 0/8 11:50:21: 1200MHz 1.13 5% 2% 2% 0% 0% 0% 55.9°C 0/8 11:50:26: 1200MHz 1.12 4% 2% 2% 0% 0% 0% 55.5°C 0/8 11:50:31: 1200MHz 1.11 4% 2% 2% 0% 0% 0% 57.0°C 0/8 11:50:36: 1200MHz 1.10 4% 2% 2% 0% 0% 0% 55.2°C 0/8
Appears that no throttling is taking place. According to top, there is 131068 KiB swap and zero swap being used. Doesn't seem to be a system performance issue.
I'll have to dust off a RPi to try it out. Give me a bit. In the meantime, if you have any other suggestions, I'm most appreciative.
I now have it on a Beaglebone Black with exactly the same result - 1.06 fps...
Could you run the perfloop demo with an additional flag of --mode=1 and let me know what FPS that gives please?
What version of pillow is installed?
I’m working away from home at the moment and haven’t got access to a raspberry pi to check this SSD1327 implementation... and it’s going to be early July until I’m back.
That got it up to 1.13 fps on the BBB...
I'm not in a rush and appreciate your work on this!
I think rmhull never got his hands on an actual ssd1327, so anyone out there willing to donate one, please do.
You could try increasing the I2C baud rate. On a Raspberry Pi it is quite straightforward (http://www.mindsensors.com/blog/how-to/change-i2c-speed-with-raspberry-pi), but you'll need to check in the relevant forums for Orange Pi and BeagleBone how to do this on those devices.
Sorry, doing other things.
I think I have the clock set to 400kHz; it's all the way up to 3.1 fps! I'll send you this display if you want to play with it.
I was pushing ~16FPS with a 128x128x1 black & white OLED (sh1106) after modifications to the library, so a framerate of 3.1 on a display needing 4x the data would seem about in line with my experience.
The reason for this is that the underlying i2c transport splits the data into 32byte chunks in order to get around the buffer limitations imposed by smbus/smbus2 etc, which implement the SMBus protocol to the letter. i2c itself does not have a 32byte limit.
This is 256 chunks for 128x128x4 bits of data, resulting in 512 additional bytes (address/register) needing to be sent every single frame. Okay it's not quite this bad since you probably have to set a page address register every X bytes anyway, but this doesn't help.
But this is not actually necessary- smbus2 supplies an i2c_rdwr method which can read/write in unlimited size blocks.
It seems both command and data could depend upon a test for this method against the supplied library, and make use of it where available. Since this feature would greatly benefit the users of our 128x128 OLED breakout, I'd be happy to prepare a PR for it. I've had it running before during some of my internal testing.
Still 128x128x4 = 65536 bits, at 400kHz is 0.16384sec ignoring any address/register data or paging that might take place to transfer this kind of buffer. At 400kHz I'd say your best possible framerate is maybe 5-6fps so you're not really far off. Don't hold your breath for a miracle.
Since this feature would greatly benefit the users of our 128x128 OLED breakout, I'd be happy to prepare a PR for it. I've had it running before during some of my internal testing.
sounds great.
Already working on it ;)
Update: First draft: https://github.com/rm-hull/luma.core/pull/147
(Amazing how long a couple of lines of code can take! Granted I had to walk into the office to grab some OLEDs for testing.)