Posts by Oldsmobile

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!

    Moin!


    Nachdem sich mein Projekt langsam dem Abschluss nähert, habe ich noch ein Problem mit dem Einbau meines Raspi 3B mitsamt USB-2.0-CD-Laufwerk: Der Raspi (+ Tasten-Pad, Bildschirm, Verstärker etc.) kommt in den Autoradio-Schacht im Armaturenbrett, von wo aus zwei (~ 60 cm lange) Kabel zur Mittelkonsole führen:



    Die Adern sind recht dick (zwar Litzen, aber viel dicker als die bei USB-3.0-Kabeln üblichen Äderchen), aber weder verdrillt, noch geschirmt.


    In die Mittelkonsole kommt das USB-CD-Laufwerk. Nun meine Frage: Kann ich die USB-Buchse des Rapis (via Adapter) an den (weißen) Stecker des vorhandenen Kabels und den Stecker des CD-Laufwerks an den Stecker am anderen Ende des Kabel anschließen und das Laufwerk so über die im Auto schon vorhandene Kabelage anbinden, oder muss ich da wirklich ein USB-Kabel durch den Tunnel zwischen Armaturenbrett und Mittelkonsole durchfrickeln (und die vorhandene Kabelage rausreißen), damit es beim Abspielen nicht zu Aussetzern kommt? Danke!

    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:


    command sequence


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


    list of commands

    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.