Posts by Oldsmobile

    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

    Wo hast du die denn gefunden?

    Reichelt. Die haben jede Menge von den Tantal-Dingern. Und dass die «nicht mehr verwendet werden sollten», da muss ich Dir widersprechen, denn in der Computerindustrie kommen die heute noch en masse zum Einsatz. Ich habe selber früher in der Branche gehackelt und mich auch mit durchgepafften Elkos (dann aber meist in der Aluminium-Variante mit flüssigem Elektrolyten, der beim Auslaufen ganze Leiterplatten zerfressen konnten) rumschlagen dürfen.

    Nur zur Info: Einer der beiden Kondensatoren, die an Pin 2 des Mixers hängen (C8; Tantal-Elko mit 47 µF), hat sich als kaputt entpuppt. Obwohl richtig eingesetzt, erzeugte er einen Kurzschluss! :@Das könnte der Grund dafür sein, dass plötzlich eine zu hohe Spannung am SDA-Pin lag und so den SDA vom Pi grillte, oder?