Posts by Oldsmobile

    Moin!


    Nachdem ich mittlerweile meinen Pi in das vorgesehene Gehäuse (von einem alten Autoradio) verfrachtet habe, muss ich nun die ganzen USB-Geräte anstöpseln — und habe keinen Platz mehr für gewöhnliche USB-Stecker:



    Eines der anzuschließenden Geräte ist die Radio-Platine weiter unten mit miniUSB-Buchse. Die übrigen Geräte befinden sich außerhalb des Gehäuses.


    Nun meine Frage: Wie lassen sich hier USB-Geräte anschließen bzw. die USB-Ports des Pi rausführen? Ich habe mich schon ein wenig schlau gemacht und bin auf folgende Lösungen gestoßen:

    • Nackten USB-Stecker (der sich komplett in der Buchse versenken lässt) verwenden und passende Adern dranlöten
    • Abgewinkelten Stecker anschießen (geht aber nur bei ≤2 Geräten)
    • Buchsen vom Pi entfernen und die erforderlichen Adern direkt an die freigelegten Stellen löten (Dieser Vorschlag stammt nicht von mir!)

    Da im Betrieb mit Stößen und Vibrationen zu rechnen ist (Pkw…), sollten die Anschlüsse nicht allzu leicht rausrutschen können. Welche Lösung ist nun die praktikabelste?

    Also, eigentlich war die UART-Konsole schon aus:

    Code
    The serial login shell is disabled
    The serial interface is enabled


    Nichtsdestotrotz bin ich nochmal durch raspi-config gegangen, einen Reboot gemacht — und habe urplötzlich einen UART mit der richtigen Gruppe und den richtigen Privilegien:

    Code
    pi@autoradio:~ $ ls -al /dev/ttyS0
    crw-rw---- 1 root dialout 4, 64 Sep 11 22:51 /dev/ttyS0

    Warum bloß? War die vorherige Konfig fehlerhaft? :denker:

    Leider stecke ich wieder mal ganz tief in einem Schnittstellen-Problem. Diesmal ist es der UART, an dem ein GPS-Board hängt und das ich per gpsd anspreche. Nach einer Neuinstallation von Raspbian Buster verschluckt sich der gpsd beim Start an falschen User-Rechten für den UART (also /dev/ttyS0). Siehe die Ausgabe von systemctl:



    So sehen die Rechte derzeit aus:

    Code
    pi@autoradio:/import/valen/autoradio $ ls -al /dev/ttyS0
    crw--w---- 1 root tty 4, 64 Sep 11 00:06 /dev/ttyS0


    Das ist aber nicht, was der gpsd erwartet. So ich mich noch erinnern kann, sah mit der alten Installation die Rechtestruktur so aus:


    Code
    crw-rw---- 1 root dialout


    Passe ich sie von Hand an, läuft das GPS-Board, aber leider nur bis zum nächsten Shutdown! Boote ich den Pi nochmal, habe ich wieder die alte (und falsche) Struktur.:@


    Nun: Was mache ich, damit Raspbian die Rechte an ttyS0 nicht bei jedem Booten zurücksetzt, sondern sie einfach belässt? :helpnew:

    OK, ich habe mir einen Wolf gesucht und gefunden: Es war nicht etwa die ALSA-Konfiguration, sondern ein Dienst namens pigpiod, welcher sämtliche GPIO-Anschlüsse ansteuert und das Taktsignal per PWM oder PCM erzeugt. Standard ist PCM, doch dann trampelt der Dienst der Soundkarte auf die Füße. Das Problem hatte ich schon bei der ersten Einrichtung des Sounds vor einigen Jahren. So geht's richtig:


    Code
    /usr/bin/pigpiod -t 0 -l


    Mit -t 0 schaltet der Dämon auf PWM um, und der Sound wird nicht mehr gestört.

    Moin!


    Nachdem ich kürzlich das Raspbian von meinem Pi 3B+ komplett neu aufsetzen musste, hapert es mit der Tonausgabe über ALSA und das JustBoomm-DAC-HAT: Alle Klänge haben eine viel zu geringe Tonhöhe (vielleicht ½ der geforderten Frequenz). Dabei ist es egal, welche Sorte von Sound-Daten es ist: Ich habe ein MP3-File mit mpg123 abgespielt und einen kurzen Text mit eSpeak sprechen lassen. Beide tönten viel zu tief. Hier meine Audio-HW-Konfiguration (der Onboard-Sound des Pi ist per Boot-Config ausgeschaltet):



    Und hier meine /etc/asound.conf:



    Was läuft hier schief?

    Moin!


    Nachdem der TDA7318-Mixer-Chip immer noch Probleme macht (ignoriert Befehle, doch den I²C-Bus habe ich per Logik-Analysierer geprüft), hätte ich hier folgende Frage: Muss ich immer, wenn ich via I²C einen Befehl an den Mixer schicke, alle acht Befehls-Bytes senden? Die Doku macht da keine eindeutigen Angaben, doch vielleicht kann einer von Euch zwischen den Zeilen lesen:


    [Blocked Image: https://i.stack.imgur.com/SXLXR.png]


    Register hat der TDA anscheinend nicht. Er versteht lediglich acht verschiedene Befehle, die allesamt (mitsamt Argumenten) 1 Byte lang sind:


    [Blocked Image: https://i.stack.imgur.com/laMn6.png]

    In die Variable N (Anzahl Bytes) wird im gesamten Dokument nirgends ein Wert eingesetzt, doch die Tabelle mit den Data Bytes lässt sich dahingehend auslegen, dass immer alle acht Bytes gesendet werden müssen, selbst wenn nur ein einziger Befehl erteilt werden soll, oder sehe ich da etwas falsch? Danke.

    Nachdem ich von meinem alten Raspi 3B wegen eines Defekts auf einen 3B+ wechseln musste, macht das Sound-HAT (JustBoom DAC HAT) nicht mehr mit: Es wird gar nicht mehr erkannt, obwohl nur der Pi neu ist und das Raspbian ein Update erfahren hat! Selbst wenn ich den I²C-Bus scanne, finde ich es unter seiner Adresse (0x4D) nicht mehr (die anderen Adressen gehören zur USV):



    An der /boot/config.txt habe ich ebenfalls nichts geändert:


    Code
    dtparam=audio=off
    dtoverlay=justboom-dac


    Auch werden die Treiber anscheinend geladen:



    Zum Schluss noch die aktuelle Systemversion:


    Code
    pi@autoradio:~ $ uname -a
    Linux autoradio 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux


    Heißt das, die Soundkarte ist im Eimer?

    mal als 2 Phase, mal als N usw.

    In einer Ex-Firma hatten wir mal einen (angestellten) Elektriker, der mal tatsächlich statt N eine zweite L-Ader nahm, um Steckdosen anzubinden. Die Folgen waren etwas unschön und kosteten ihn auch den Job.


    Die Draufsicht im Datenblatt ist aber auch etwas fies! Der Halbmond wird zwar dargestellt, die Beschriftung des Chips aber nicht. So setzt man den Chip schon mal verkehrt rum ein:

    Nur gut, wenn man's vorher weiß! :wallbash: Trotzdem danke für den Tipp mit den Wandlern. Ich habe schon mal welche benützt, aber an einem SPI-Bus mit einem 5-Volt-Slave dran. Da steht gar keine Spannung vorher fest, und es gibt zwei Datenleitungen (eine pro Richtung). Der TDA (der ja keine PURs hat) sagt ja übrigens auch: 3 V Mindestspannung auf dem Bus.


    Gemäß Norm müssen aber alle I²C-Slaves Open Drain haben.

    Pustekuchen! Gerade habe ich einen brandneuen Pi angeschlossen, vorsichtshalber vorher (!) einen gpiotest gemacht (fehlerfrei) — und habe das Problem mit den Phantom-Adressen jetzt schon wieder, nachdem ich den TDA gerade mal eine Minute lang am neuen Pi hängen ließ. Anscheinend habe ich auch ihn ruiniert.:@


    UPDATE: Ich habe den brandneuen Pi mal durchgemessen und sowohl an SDA, als auch an SCL +3,29 V messen können (sowohl mit «Normalbetrieb», als auch, wenn ich beide Pins gezielt auf HIGH setze). Doch habe ich schon wieder nur noch 800 Ω zwischen +3,3 V und SCL (und 1600 Ω bei SDA). Dazu, ob ein Pegelwandler zwischen einen 9-Volt-Slave und Pi rein soll, kriege ich leider widersprüchliche Antworten: Mal sagte man mir NEIN, weil die Spannung auf dem Bus von dem Gerät abhängt, an dem die PUs montiert sind (also dem Pi: 3,3 V), während an anderen Stellen von einem 3,3-auf-5-Volt-Wandler berichtet wird, wenn man einen Arduino als Slave vom Pi aus steuern will.

    Selber Troll!! :P


    Was ich (und nicht nur ich) schon vorher befürchtet hatte, hat sich nach dem Kauf eines neuen Pis bewahrheitet: Der I²C-Anschluss meines alten Pis ist tatsächlich im Arsch! SD-Karte in den neuen Pi gesteckt, Upgrade gemacht, gpiotest gestartet, et voilà:

    Code
    Testing...
    Skipped non-user gpios: 0 1 28 29 30 31 
    Tested user gpios: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 
    Failed user gpios: None