Documentation, Install - Githubissues

gnbl commented 7 years ago

Re: https://github.com/rm-hull/luma.oled/blob/master/doc/install.rst

May I suggest simply duplicating the required command for their Python 3 counterparts, and removing the equally long substitution list? This would simplify and eliminate error, since not all pip are to be changed:

$ sudo apt-get install python-dev python-pip3 libfreetype6-dev libjpeg-dev build-essential
$ sudo -H pip3 install --upgrade pip
[ $ sudo apt-get purge python-pip3 ] (removes pip3, see below)
$ sudo -H pip3 install --upgrade luma.oled

Additionally, purge in line 3 just removed my pip3 which is required in line 4.

rm-hull commented 7 years ago

I think we may just revamp the instructions to not do any of these acrobatics since Raspbian Stretch has the latest pip by default (see https://github.com/rm-hull/luma.core/issues/106) ... well, possibly just move it to a footnote perhaps instead.

There is also a longer term aim to move all the documentation into a single place.

gnbl commented 7 years ago

Thanks, otherwise the install went OK. In the meantime I've managed to hook up the display successfully and am trying out some examples. ~/luma.examples/examples $ python3 video.py -d ssd1322 --width 256 --height 64 -i spi The pyav library could not be found. Install it using 'sudo -H pip install av'.

But that fails, lacking numerous libav dependencies. The 280 MB fix:

sudo apt-get install libavformat-dev libavcodec-dev libavdevice-dev libavutil-dev libavfilter-dev libswscale-dev libswresample-dev

and then

sudo -H pip3 install av

which takes quite a while.

But then

~/luma.examples/examples $ python3 video.py -d ssd1322 --width 256 --height 64 -i spi

works..very...slowly :-)

BTW: Zero W 1.1 running

$uname -r
4.9.41+
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"

rm-hull commented 7 years ago

works..very...slowly :-)

Kinda expected - you'd see better performance on a RPi model 3B than a PiZero (obviously), and remember its having to push out greyscale-converted 256*64 pixels per frame for video.

For simpler drawing tasks where only parts of the frame changes, then it does a "diff-to-previous" to only draw the changed areas - this helps improve performance significantly (but not for video where there is a lot of churn between frames).

The main intent for this library is a simple and accessible drawing abstraction (without too many dependencies) rather than high frame-rate video rendering. I've just implemented a driver for SSD1351 (128x128 full color, see #174) and handling that many pixels sequentially is getting to the limit of what is achievable in python.

Maybe a future direction might be to look at rewriting the display loop rendering in C with python FFI...

gnbl commented 7 years ago

Thanks for the feedback, this was not meant as a complaint. I'm happy it worked on the first attempt.

rm-hull commented 7 years ago

Didnt take it as a complaint - just wanted to provide some context :) It's actually really interesting hearing other peoples opinions and experiences with the library: there are so many permutations of SBCs / kernels / firmware / python versions / interfaces (spi/i2c) / displays - so much so, I'm sometimes amazed that it works first time at all !!

gnbl commented 7 years ago

OK, thanks. Regarding speed: I tried doubling the SPI clock rate. Things I learned:

no visible change in "frame rate"
it is indeed the hardware SPI being used
the SPI speed setting does affect the clock rate, I tried up to 16000000 and also 15600000 (see below)
SSD1322 seems to handle this speed even over jumper wires, despite the 100 ns clock cycle time minimum (datasheet v1.2 p. 53)
py-spidev also seems to accept "odd" rates, so this assert in serial.py#L251 may not be neccessary
- In contrast, this post actually suggests only certain "odd" values are acceptable by RPi.
- This is where it gets intricate as the different models' CPUs may differ:
- https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md#hardware
- https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications
SPI frame data transfer only every 150-200 ms, matching the approx 5 Hz determined by bounce.py
the interface is not the bottleneck, as you suggested already

gnbl commented 7 years ago

While I'm at it, here is how to get info on the SPI drivers:


pi@raspberry:~/luma.examples/examples $ lsmod | grep spi
spidev                  7034  0
spi_bcm2835             7424  0

pi@raspberry:~/luma.examples/examples $ modinfo spidev
filename:       /lib/modules/4.9.41+/kernel/drivers/spi/spidev.ko
alias:          spi:spidev
license:        GPL
description:    User mode SPI device interface
author:         Andrea Paterniani, <a.paterniani@***.it>
srcversion:     3C0840175512DC1D2C71326
alias:          of:N*T*CspidevC*
alias:          of:N*T*Cspidev
alias:          of:N*T*Clineartechnology,ltc2488C*
alias:          of:N*T*Clineartechnology,ltc2488
alias:          of:N*T*Crohm,dh2228fvC*
alias:          of:N*T*Crohm,dh2228fv
depends:
intree:         Y
vermagic:       4.9.41+ mod_unload modversions ARMv6 p2v8
parm:           bufsiz:data bytes in biggest supported SPI message (uint)

pi@raspberry:~/luma.examples/examples $ modinfo spi_bcm2835
filename:       /lib/modules/4.9.41+/kernel/drivers/spi/spi-bcm2835.ko
license:        GPL v2
author:         Chris Boot <bootc@***.net>
description:    SPI controller driver for Broadcom BCM2835
srcversion:     64E8A93AAE8A9E8C014112F
alias:          of:N*T*Cbrcm,bcm2835-spiC*
alias:          of:N*T*Cbrcm,bcm2835-spi
depends:
intree:         Y
vermagic:       4.9.41+ mod_unload modversions ARMv6 p2v8

pi@raspberry:~/luma.examples/examples $ ls /dev/spi*
/dev/spidev0.0  /dev/spidev0.1

Sorry, that is mostly in http://luma-oled.readthedocs.io/en/latest/hardware.html#pre-requisites already.

SPI settings in raspi-config are currently in:

Interfacing Options P4 SPI

(https://github.com/rm-hull/luma.oled/blame/master/doc/hardware.rst#L179)

thijstriemstra commented 7 years ago

A pull request to add that info about pyav install in the example would be useful.

gnbl commented 7 years ago

It's just two lines. Feel free to use it!

thijstriemstra commented 7 years ago

It's already in there: https://github.com/rm-hull/luma.examples/blob/master/examples/video.py#L10

gnbl commented 7 years ago

Not sure why you close before fixing, but it's your project :-) Though my bad for mixing up several topics in this "issue". Cheers anyway.

thijstriemstra commented 7 years ago

Not sure why you close before fixing, but it's your project :-)

Fixing what? Please open a ticket for each issue.

gnbl commented 6 years ago

@rm-hull If you wanted to improve the speed for this display controller, consider to optimize the bit-packing (two pixels / greyscale nibbles per byte). This seems to be quite slow in Python. Outsourcing this loop to a compiled Cython module speeds this up significantly.

Increasing SPI driver buffer size and patching py-spidev accordingly does probably not gain very much, although it would allow writing the whole display / RAM in one transfer (8 kiB / 32 kiB).

However, both of these are probably a bit involved for the end user.

thijstriemstra commented 6 years ago

@gnbl sounds interesting, can you make a pull request?

rm-hull / luma.oled

Documentation, Install #176