Phoniebox mit Dual-TFT 1,8" mit Peppymeter

  • Liebe Community,

    ich versuche einmal, den aktuellen Stand dieses Projektes softwareseitig vorzustellen, verbunden mit ein paar Fragen an euch.

    Hardware:

    Raspi 3B+

    2x 1,8" TFT von az-delivery mit st7735-Controller

    x400 v3.0 Audio HAT mit Amp, unter iqaudio-dacplus.dtbo

    alternativ / zusätzlich 3,5" joy-TFT mit Touch (SPI)

    Software:

    - Systemische Einrichtung der Displays (2x 1,8" oder 2x1,8" + 3,5" oder 1x1,8" + 3,5")

    - peppyalsa

    - peppymeter

    - phoniebox v2.3

    Ziel:

    A) Idealerweise zeigt die Phoniebox auf einem 3,5"-Display die Titelinfos + Cover, auf beiden 1,8"ern sollen die Audiokanäle R/L getrennt dargestellt werden.

    B) Da das nicht klappt, s.u., soll nun auf einem 1,8"er ein Peppymeter und auf dem anderen die Titelinformationen angezeigt werden.

    C) Eine Verbindung 3,5"+1,8" werde ich auch noch angehen, weil dann das Cover wieder dazu kann. Das scheint mir nur eine schwierigere GPIO-Schieberei zu werden.

    Stand der Dinge (Dateien s.u.)

    Hardware:

    - eine dual-TFT1,8"-Konfiguration war unter Nutzung einer selbst modifizierten st7735r_dual.dtbo endlich erfolgreich. SPI is a bitch. Beide Displays zeigen sich als /dev/fb1 und /dev/fb2 und können jeweils die Konsole anzeigen (cmdline.txt mit "fbcon=map:10" oder "fbcon=map:20"). Beide devices zeigen sich in der proc mit den Hardware-Daten leider als WxH "128x160", also aufrecht stehend. Ich hänge hier in der Frage, wie ich das "hardwareseitig" um 90° gedreht bekomme.

    - Zusätzlich läuft auch nach vielen Kopfschmerzen der audio-HAT, nachdem für alle drei Komponenten die GPIO-pins "sortiert" werden mussten.

    - Das 3,5" TFT lief nach Einrichtung "allein" auch mit PeppyMeter und Phoniebox reibungslos, allerdings mit fürchterlichem Lag. So machte das keinen Sinn, das Ding läuft mit 16MHz, das scheint einfach zu langsam zu sein. Die 1,8"er sind auf 40MHz getaktet, da erwarte ich mehr. Das 3,5"er als Info-Screen für Titel und Cover ist noch tbd.

    Software:

    - Phoniebox erfordert in der non-dev-aktuellen Fassung noch Debian Buster mit Alsa. Die Einrichtung ist inkl. WLAN und Audio erfolgt; etwas unschön ist, dass unter Nutzung beider 1,8"-Displays das tool "raspi-config" den Audio-HAT nicht listet und ich manuell unter /usr/share/alsa/alsa.conf auf die hw1,0 umstellen musste. Evtl. ein verbleibender GPIO-Konflikt?

    - peppyalsa gemäß WiKI problemlos eingerichtet; die asound.conf ist unter /etc abgelegt und ebenfalls manuell auf hw1,0 und card 1 gesetzt. Das Hilfstools "peppyalsa-client" funktioniert auf Anhieb. In Verbindung mit dem 3,5"er s.o. auch in der Einrichtung easy.

    Achtung! Bei Debian bullseye ist der Standard-user "pi" abgeschaltet bzw. ein individueller user einzurichten. Phoniebox v2.x funktioniert as-it-is nur mit dem user "pi" problemlos, die Verzeichnisse sind "softcoded" in den Scripten.

    - PeppyMeter: Läuft mit den 1,8"ern noch nicht. Beim 3,5" zu träge = untauglich.

    Zu meiner Frage an wesentlich kompetentere Programmierer als ich es bin:

    Peppymeter: Ich bekomme es partout nicht hin, eine Auflösung "128x160" dort einzurichten, geschweige denn, die Hardware um 90° zu drehen und in Peppymeter 160x128 anzusetzen, s.u. Peppy-Dateien und -fehlermeldungen.

    - Es sind bgr, fgr und needle-Bilder auf 128x160 und 160x128 vorhanden und in ein Verzeichnis "mikro" als "blue128" bzw. "blue160" abgelegt.

    - in der Datei configfileparser.py wurde folgendes ergänzt:

    Code: configfileparser.py
    + 126 "MIKRO = "mikro"
    + 129 "MIKRO_WIDTH = 128
    + 130 "MIKRO_HEIGHT = 160
    +225-227:
    elif meter_size == MIKRO:
        self.meter.config[...]WIDTH
        self.meter.config[...]HEIGHT

    In der config.txt vom Peppymeter wurde "meter = blue128", "meter.size = mikro", screen.width = 128, screen.height = 160 eingetragen, unter sdl.env beide Frambuffer-devices fb1 und fb2 ausprobiert.

    Die Größen 128 und 160 wurden in allen Dateien auch getauscht und auf die 160x128er Bilder verwiesen.

    Gleiches Ergebnis bei 128x160 oder 160x128:

    pi@toriabox:~/PeppyMeter $ sudo python3 peppymeter.py

    pygame 1.9.4.post1

    Hello from the pygame community. https://www.pygame.org/contribute.html

    Traceback (most recent call last):

    File "peppymeter.py", line 293, in <module>

    pm.init_display()

    File "peppymeter.py", line 165, in init_display

    self.util.PYGAME_SCREEN = pygame.display.set_mode((screen_w, screen_h))

    pygame.error: No video mode large enough for 128x160

    Das sieht nicht wirklich nach einem Peppymeter-Fehler aus, sondern als ob meine Framebuffer-devices sich nicht richtig melden?

    Wer kann helfen? Ich habe unten einige Infos/Dateien/Dateiauszüge angefügt, wenn etwas fehlt ergänze ich gerne.

    vG

    Daniel

    Dateien:

    Display-Infos vom System

    pi@toriabox:~ $ ls /sys/class/drm

    card0  card0-SPI-1  card1  card1-SPI-2 version

    pi@toriabox:~ $ cat /sys/class/drm/card1-SPI-2/modes

    128x160

    pi@toriabox:~ $ cat /sys/class/drm/card0-SPI-1/modes

    128x160

    pi@toriabox:~/PeppyMeter $ fbset -i -fb /dev/fb1

    mode "128x160"

    geometry 128 160 128 160 16

    timings 0 0 0 0 0 0 0

    rgba 5/11,6/5,5/0,0/0

    endmode

    Frame buffer device information:

    Name : st7735rdrmfb

    Address : 0

    Size : 40960

    Type : PACKED PIXELS

    Visual : TRUECOLOR

    XPanStep : 1

    YPanStep : 1

    YWrapStep : 0

    LineLength : 256

    Accelerator : No

    pi@toriabox:~/PeppyMeter $ fbset -i -fb /dev/fb2

    mode "128x160"

    geometry 128 160 128 160 16

    timings 0 0 0 0 0 0 0

    rgba 5/11,6/5,5/0,0/0

    endmode

    Frame buffer device information:

    Name : st7735rdrmfb

    Address : 0

    Size : 40960

    Type : PACKED PIXELS

    Visual : TRUECOLOR

    XPanStep : 1

    YPanStep : 1

    YWrapStep : 0

    LineLength : 256

    Accelerator : No


    /boot/config.txt

    dtoverlay=iqaudio-dacplus

    dtoverlay=st7735r_dual

    max_framebuffers=4

    dtparam=spi=on

    dtparam=i2s=on

    dtparam=audio=on

    #dtoverlay=vc4-fkms-v3d

    cmdline.txt

    ergänzt um „fbcon=map:10,font:VGA8x8“

    dmesg

    […]

    [ 7.181794] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.

    [ 7.186616] mc: Linux media interface: v0.10

    [ 7.191524] bcm2835_vc_sm_cma_probe: Videocore shared memory driver

    [ 7.191558] [vc_sm_connected_init]: start

    [ 7.200791] [vc_sm_connected_init]: installed successfully

    [ 7.273730] videodev: Linux video capture interface: v2.00

    [ 7.301490] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.

    [ 7.327734] bcm2835_audio bcm2835_audio: card created with 8 channels

    [ 7.338864] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.

    [ 7.340075] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.

    [ 7.352666] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.

    [ 7.359056] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.

    [ 7.369016] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.

    [ 7.371824] spi-bcm2835 3f204000.spi: chipselect 1 already in use

    [ 7.371871] spi_master spi0: spi_device register error /soc/spi@7e204000/spidev@1

    [ 7.371902] spi_master spi0: Failed to create SPI device for /soc/spi@7e204000/spidev@1

    [ 7.374146] bcm2835-codec bcm2835-codec: Device registered as /dev/video10

    [ 7.374207] bcm2835-codec bcm2835-codec: Loaded V4L2 decode

    [ 7.404078] bcm2835-codec bcm2835-codec: Device registered as /dev/video11

    [ 7.404143] bcm2835-codec bcm2835-codec: Loaded V4L2 encode

    [ 7.405373] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13

    [ 7.407561] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14

    [ 7.408196] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15

    [ 7.408956] bcm2835-codec bcm2835-codec: Device registered as /dev/video12

    [ 7.409013] bcm2835-codec bcm2835-codec: Loaded V4L2 isp

    [ 7.409709] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16

    [ 7.409744] bcm2835-isp bcm2835-isp: Register output node 0 with media controller

    [ 7.409771] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller

    [ 7.409792] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller

    [ 7.409833] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller

    [ 7.410249] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp

    [ 7.412792] bcm2835-codec bcm2835-codec: Device registered as /dev/video18

    [ 7.412848] bcm2835-codec bcm2835-codec: Loaded V4L2 image_fx

    [ 7.868917] cfg80211: Loading compiled-in X.509 certificates for regulatory database

    [ 8.006816] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'

    [ 8.145465] brcmfmac: F1 signature read @0x18000000=0x1541a9a6

    [ 8.160324] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1

    [ 8.162318] usbcore: registered new interface driver brcmfmac

    [ 8.432074] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1

    [ 8.432239] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1

    [ 8.432332] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 8.433444] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 22 2019 01:59:28 version 7.45.98.94 (r723000 CY) FWID 01-3b33decd [ 8.995403] [drm] Initialized st7735r 1.0.0 20171128 for spi0.1 on minor 0

    [ 11.196805] st7735r spi0.1: [drm] fb1: st7735rdrmfb frame buffer device

    [ 11.242127] [drm] Initialized st7735r 1.0.0 20171128 for spi0.0 on minor 1

    [ 11.245566] st7735r spi0.0: [drm] fb2: st7735rdrmfb frame buffer device

    [ 12.129305] random: crng init done

    [ 12.129337] random: 7 urandom warning(s) missed due to ratelimiting

    [ 12.393208] 8021q: 802.1Q VLAN Support v1.8

    [ 12.442105] uart-pl011 3f201000.serial: no DMA platform data

    [ 12.695260] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS

    [ 12.765899] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

    [ 13.217671] SMSC LAN8700 usb-001:003:01: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=usb-001:003:01, irq=PO

    LL)

    [ 13.220716] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup

    [ 13.231241] smsc95xx 1-1.1:1.0 eth0: Link is Down

    [ 14.285428] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

    [ 15.276211] smsc95xx 1-1.1:1.0 eth0: Link is Up - 100Mbps/Full - flow control off

    [ 15.276279] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

    [ 16.751214] Bluetooth: Core ver 2.22

    [ 16.751350] NET: Registered protocol family 31

    [ 16.751362] Bluetooth: HCI device and connection manager initialized

    [ 16.751392] Bluetooth: HCI socket layer initialized

    [ 16.751411] Bluetooth: L2CAP socket layer initialized

    [ 16.751442] Bluetooth: SCO socket layer initialized

    [ 16.764194] Bluetooth: HCI UART driver ver 2.3

    [ 16.764217] Bluetooth: HCI UART protocol H4 registered

    [ 16.764332] Bluetooth: HCI UART protocol Three-wire (H5) registered

    [ 16.764603] Bluetooth: HCI UART protocol Broadcom registered

    [ 17.062671] Bluetooth: BNEP (Ethernet Emulation) ver 1.3

    [ 17.062684] Bluetooth: BNEP filters: protocol multicast

    [ 17.062703] Bluetooth: BNEP socket layer initialized

    [ 24.640803] pcm512x 1-004c: No SCLK, using BCLK: -2

    [ 24.702917] pcm512x 1-004c: No SCLK, using BCLK: -2

    [ 24.755825] pcm512x 1-004c: No SCLK, using BCLK: -2

    [ 24.782997] pcm512x 1-004c: No SCLK, using BCLK: -2

    2 Mal editiert, zuletzt von listenmitglied (19. Oktober 2022 um 15:59)

  • Moinsen,

    da du uns hier mit wirklich wichtigen Daten nicht gerade überhäufst, eine grobe Einschätzung und einige Erklärungsversuche, die mehr als Hinweis, als denn Lösungshilfe zusehen sind.

    Der SPI Bus und damit das Signal Befehlsfolge ist immer an den CS gekoppelt.
    Das heist du musst, wenn die einzelnen SPI Bus Slaves nicht über eigene Adressen verfügen, für jeden Slave ein einen GPIO Pin vorsehen, mit dem das CS diesen Slave aktiviert.
    Da du keinerlei Aussagen machst, wie du das ganze verkabelt hast, kann man hier nur mutmaßen, was du meinst wenn du sagst:

    nachdem für alle drei Komponenten die GPIO-pins "sortiert" werden mussten.

    Der 3B+ hat nur einen Hardware SPI Bus und hardwareseitig, sowie Kernel-unterstützt nur 2 ( zwei) CS GPIO-Pins ( Pin Nr: 24 = GPIO10 und Pin Nr. 26 = GPIO11 ) sowie als Alternativebelegung für MOSI, MISO, SCLK, CS die Pins 35, 36, 38, 40.
    Das bedeutet, wenn du eine zeitgleiche synchrone Darstellung auf den beiden 1,8" Displays erreichen willst musst du beide SPI Hosts benutzen, und irgendwoher dann noch eine Zeitlücke finden worin du die Daten zudem dritten Display übertragen kannst. Alternativ kannst du auch die Software-Emulation des SPI Bus nutzen.
    Willst du nun eine Levelmeter Kanal-getrennt über zwei Displays darstellen musst du eine Scheduler für die Aufteilung der MOSI Signale mit dem passenden CS Signal erstellen.
    Da du hier nun auch einen Codeschnipsel einer Routine die Python erinnert präsentiert hast, ist nun die Frage welche Bibliothek dem Ganzen zu Grund liegt ? ( SPIDEV oder einer der Adafruit Codes )

    Selbst wenn du diese Darstellungsprozesse auf mehrere Tasks aufteilst kommst du hierbei möglicher Weise ins Straucheln, weil der Adafruit Code wenn dieser über mehrere einzelne Tasks / Threads ausgeführt wird nicht selektiv unterscheiden kann welche CS gerade aktiv ist. Somit kann es zu einer Überlagerung mehrerer Befehlsfolgen über den MOSI kommen, bzw. auch das zwei CS Pegel auf LOW = Aktiv stehen, und somit keine eindeutige BUS-Slave Zuordnung mehr möglich ist. Auf Deutsch gesagt, die Bus-Slaves = Displays verstehen dann nicht mehr was sie wirklich machen sollen.

    Kommt nun noch das dritte, größere Display hinzu, wo auf Grund der Datenmenge noch mehr übertragen werden müssen, musst du für eine klare Trennung der SPI BUS-Hosts sorgen, die du über getrennte eigene BUS-Nummern ansprichst.

    Am besten du machst mal eine Verdrahtungsskizze, damit man nicht im trüben fischen muss, sondern jeder erfährt, welches Display über welche Pins mit welcher Funktion wie mit dem 3B+ verbunden sind. Sowie auch mal die vollständige Quelle, bzw den Code dieser Ansteuerbibliotheken hier Preis gibts.

    Grundsätzlich drei SPI Displays sind möglich, aber je nach Aktualisierungsrate und Displaygröße = damit zu übertragende Datenmenge pro Änderungsintervall sollte man hier schon Prioritäten setzen, bzw. für eher Nebenbeisachen, auf ein Display mit I²C ausweichen. Zwei Displays die wirklich Synchron und zeitkritisch laufen dann nur wenn du die beiden SPI Hosts nutzt, und den Rest dann über SoftSPI mit erheblichen Verzögerungen einsetzen.
    Vor allem Python ist hier nicht der Burner , und schon gar nicht der Adafruit Code, der ausschließlich auf wenige C++ Anteile setzt, sondern hier auch die hauptsächlich in Python interpretierten Funktionen sehr langsam umsetzt. Hier solltest du dich ggf auch mit der Programmiersprache C/C++ beschäftigen.

    Franky

  • Moin Franky,

    Danke für die reichlichen Ausführungen.

    Ok. GPIO-Verkabelung. Das hätte ich natürlich gleich ausführen können, anstatt die dmesg/etc einfach anzufügen:

    Die 1,8"-Displays nutzen je acht Adern

    SPI0.0: "VCC": Pin2/5V, "GND": Pin6, "CS": Pin24/CE0, "Reset": Pin18/GPIO24, "A0"="DC": Pin16/GPIO23, "SDA"="MOSI"=Pin19/GPIO10, "SDK"="SCLK":Pin23/GPIO11, "LED":Pin22/GPIO25

    SPI0.1: "VCC": Pin4/5V, "GND": Pin6, "CS": Pin26/CE1, "Reset": Pin11/GPIO17, "A0"="DC": Pin36/GPIO16, "SDA"="MOSI"=Pin19/GPIO10, "SDK"="SCLK":Pin23/GPIO11, "LED":Pin22/GPIO25

    Zu "sortieren" war es, weil das angeschlossene Audioboard sich per Kontaktleiste laut Beschreibung folgende GPIOs nimmt:

    X400 rev3.0: "LRCK - IO19, BCK - IO18, DATA - IO21, IR - IO26, AMP mute - IO22"

    Damit belegt das Audioboard einiges vom Standard-SPI1.

    Das 3,5" legt sich treiberseitig als Touch-Display auf SPI0.0 und 0.1, damit wären es sechs SPI-Geräte in der gedachten Vollvariante - das ist eher für später mal eine Herausforderung und nach meinem Verständnis nur mit Raspi4 / SPI2 machbar. Daher lasse ich das 3,5" liegen: 2x 1,8" und Audioboard. Aktuell s.o. verdrahtet und alle drei Geräte funktional.

    Der Treiber geht auf DRM, vgl. dmesg, daher würde ich nicht die adafruit-Bib vermuten, habe aber tatsächlich hier noch erhebliche Wissenslücken.

    Aktuell frage ich mich, warum pygame sich nicht auf meine fb1/fb2-devices binden möchte, die als Framebuffer-devices problemlos das Terminal darstellen.

    Edit: "sechs" SPI, weil das Audioboard vom SPI1 das CE0 und den SCLK belegt. Nach meinem Verständnis ist SPI1 damit besetzt.

    Einmal editiert, zuletzt von listenmitglied (21. Oktober 2022 um 15:24)

  • Um ganz sicher zu gehen, dass die Tochter Weihnachten eine Phoniebox mit Display hat, sind nun Waveshare 5" HDMI-Displays eingetroffen.

    Wie erwartet läuft auf denen Peppymeter sofort ohne Probleme.

    Für das Eingangsproblem auf den 1,8"-TFTs habe ich die Lösung zur Vermeidung der Fehlermeldung "no video mode large enough" gefunden, wenngleich PeppyMeter trotzdem noch nicht läuft:

    In die Datei /etc/fb.modes muss der 160x128 (beim DRM-Modul "adafruit-st7735r") bzw. 128x160 beim adafruit18-modul als mode hinterlegt werden.

    Dazu rufe man fbset -i /dev/fb1 auf und kopiere die Zeilen "geometry" und "timings" als zusätzliche Definition in die Datei:

    mode "160x128"

    geometry 160 128 160 128 16

    timings 0 0 0 0 0 0 0

    endmode

    Dann verschwindet die Fehlermeldung beim Start von pygame.py. Es bleibt noch ein dunkler Bildschirm. Ich teste weiter...

  • Hi,

    die 1,8"SPIs habe ich erst einmal beiseite gelegt. Projekt "auf Eis", das braucht offensichtlich mehr Zeit...

    Ergebnis nach dem pragmatischen Umstieg auf das HDMI-Display s.u.

    Konfig:

    HDMI-Display 5"

    AudioBoard x400 v3.0 vom ali, nutzt GPIO 18,19,21,22,26

    RotaryEncoder auf GPIO 5,6 ("Volume") mit Druckswitch auf GPIO 17 ("Pause")

    RotaryEncoder auf GPIO 23,27 (Funktion unbelegt) mit Druckswitch auf GPIO 4 ("NextPlay")

    RotaryEncoder auf GPIO 16,20 (Funktion unbelegt) mit Druckswitch auf GPIO 13 ("ToggleBluetoothHeadset<->Amp")

    Die unbelegten Drehfunktionen sollen noch für "Höhen/Tiefen" (Equalizer...) und für ein LED-Band mit WS2801 nachgerüstet werden.

    Insbesondere das perfekt funktionierende Umschalten zwischen BT-Kopfhörer und Lautsprechern ist wirklich cool.

    Software: Phoniebox 2.4, Peppymeter/peppyalsa via rc.local gestartet, rsync der audio und RFID-files mit dem Server (der Bruder hat auch eine Box...).
    So läuft es erst einmal.

    Für den dual 1,8"-Betrieb habe ich hier einen Raspi4 liegen.... next project pending.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!