Posts by Oldsmobile

Danke erstmal für die Antworten. Wovor ich mich am meisten fürchte, ist der Ersatz der alten Kabel durch die USB-Strippe, denn im Cockpit sind die Verhältnisse sehr beengt, und an die Kabelage kommt man nicht sonderlich gut ran.

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!

Aaaahhh, Flachbandkabel! Perfekt wäre es, hätte es eine miniUSB-Buchse am anderen Ende.

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:

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:

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?

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:

pi@autoradio:/import/valen/autoradio $ sudo systemctl status gpsd
● gpsd.service - GPS (Global Positioning System) Daemon
   Loaded: loaded (/lib/systemd/system/gpsd.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-09-11 00:05:55 CEST; 17min ago
 Main PID: 608 (gpsd)
    Tasks: 1 (limit: 2059)
   CGroup: /system.slice/gpsd.service
           └─608 /usr/sbin/gpsd /dev/ttyS0

Sep 11 00:05:55 autoradio systemd[1]: Starting GPS (Global Positioning System) Daemon...
Sep 11 00:05:55 autoradio systemd[1]: Started GPS (Global Positioning System) Daemon.
Sep 11 00:13:18 autoradio gpsd[608]: gpsd:ERROR: SER: device open of /dev/ttyS0 failed: Permission denied - retrying read-only
Sep 11 00:13:18 autoradio gpsd[608]: gpsd:ERROR: SER: read-only device open of /dev/ttyS0 failed: Permission denied
Sep 11 00:13:18 autoradio gpsd[608]: gpsd:ERROR: /dev/ttyS0: device activation failed.
Sep 11 00:13:18 autoradio gpsd[608]: gpsd:ERROR: /dev/ttyS0: activation failed, freeing device

So sehen die Rechte derzeit aus:

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:

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?

Welche parallele Schnittstelle ist das? Der alte Centronics-Port, den man früher zum Ansteuern von Druckern nützte? Für den gibt es m.W. USB-auf-Centronics-Adapter fix-fertig.

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:

/usr/bin/pigpiod -t 0 -l

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

Ich arbeite derzeit mit einem Smartphone-Headset an der Klinkenbuchse des HATs (das am Telefon auch klaglos funzt). Die Stromversorgung geht über eine S.USV, die bisher immer perfekt gearbeitet hat.

Weder noch. Das Abspieltempo ist völlig normal, auch die Obertöne sind da, nur klingt alles so, als hätte man Klänge / Stimmen mit einem Harmonizer um eine ganze Oktave nach unten transponiert. Sie klingen auch nicht blechern (vocoder-mäßig).

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):

**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: sndrpijustboomd [snd_rpi_justboom_dac], Gerät 0: JustBoom DAC HiFi pcm512x-hifi-0 [JustBoom DAC HiFi pcm512x-hifi-0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
pi@autoradio:/import/valen/autoradio $ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
jack
    JACK Audio Connection Kit
pulse
    PulseAudio Sound Server
dmixer
cdplay
dsnooper
duplex
default
sysdefault:CARD=sndrpijustboomd
    snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0
    Default Audio Device
dmix:CARD=sndrpijustboomd,DEV=0
    snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0
    Direct sample mixing device
dsnoop:CARD=sndrpijustboomd,DEV=0
    snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0
    Direct sample snooping device
hw:CARD=sndrpijustboomd,DEV=0
    snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0
    Direct hardware device without any conversions
plughw:CARD=sndrpijustboomd,DEV=0
    snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0
    Hardware device with all software conversions
usbstream:CARD=sndrpijustboomd
    snd_rpi_justboom_dac
    USB Stream Output

Und hier meine /etc/asound.conf:

pcm.dmixer { 
    type dmix
    ipc_key 1024
    ipc_perm 0666 
    slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        buffer_size 4096
        rate 44100
        format S16_LE
        channels 2
    }
    bindings {
        0 0
        1 1
    }
}

pcm.cdplay {
    type dmix
    ipc_key 1024
    ipc_perm 0666
    slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        buffer_size 4096
        rate 44100
        format S16_LE
        channels 2
    }
    bindings {
        0 0
        1 1
    }
}

pcm.dsnooper {
    type dsnoop
    ipc_key 2048
    ipc_perm 0666
    slave
    {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        buffer_size 4096
        rate 192000
        format S32_LE
        channels 2
    }
    bindings {
        0 0
        1 1
    }
}

pcm.duplex {
    type asym
    playback.pcm "dmixer"
    capture.pcm "dsnooper"
}

pcm.!default {
    type plug
    slave.pcm "duplex"
}
 
ctl.!default {
        type hw
        card 0
}

Was läuft hier schief?

Danke, Bernd666. Ich dachte fast schon kein Mensch benütze noch den TDA. Ich bastle da noch ein wenig rum.

Schau mal auf die Tabelle. Das sind 8 Befehls-Bytes à 8 Bit. Meine Frage war ja, ob ich immer, wenn ich dem TDA einen Befehl senden will, alle 8 Befehls-Bytes hintereinander (selbst, wenn sich nur an einem der Bytes etwas ändert) und ganz hinten das Stoppsignal schicken muss. Die Grafik mit der Bit-Sequenz scheint zu suggerieren, eine Nachricht bestünde grundsätzlich aus mehreren Bytes.

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.

OK, die Soundkarte war anscheinend tatsächlich in'n Mors! Ich kaufte ein neues Exemplar — und zack! lief es sofort.

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):

pi@autoradio:~ $ aplay -l
aplay: device_list:272: no sound cards found ...

pi@autoradio:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- 0f 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

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

dtparam=audio=off
dtoverlay=justboom-dac

Auch werden die Treiber anscheinend geladen:

pi@autoradio:/proc/device-tree/aliases $ lsmod | grep snd
snd_soc_pcm512x_i2c    16384  0
snd_soc_pcm512x        32768  1 snd_soc_pcm512x_i2c
snd_soc_justboom_dac    16384  0
snd_soc_bcm2835_i2s    16384  0
snd_soc_core          225280  3 snd_soc_justboom_dac,snd_soc_pcm512x,snd_soc_bcm2835_i2s
snd_compress           20480  1 snd_soc_core
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_pcm               106496  5 snd_compress,snd_soc_pcm512x,snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_soc_core
snd_timer              32768  1 snd_pcm
snd                    77824  5 snd_compress,snd_soc_pcm512x,snd_timer,snd_soc_core,snd_pcm
regmap_i2c             16384  2 rtc_ds1307,snd_soc_pcm512x_i2c

Zum Schluss noch die aktuelle Systemversion:

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?

Quote from Thomas H

Hat es der TDA7318 überlebt?

Nein. Ein neuer Chip hat's allerdings gerichtet.

Quote from jar

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:

So, ich habe jetzt den Chip mit einem zweiten I²C-Bus und Pegelwandlern ausprobiert und nach mehreren erfolglosen Versuchen den Chip aus dem Steckbrett geholt. Er war schlichtweg verkehrt rum montiert. Richtet man sich nämlich nach der Beschriftung, ist Pin #1 unten links (statt oben links).

Nur gut, wenn man's vorher weiß! 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.