Posts by steipi

Quote from rpi444

BTW: Mit einem cronjob oder besser mit einer timer-unit (... als vorläufiger workaround) kannst Du minütlich oder alle 30 Sekunden testen lassen, ob der arping (arp-Protokoll) zum Router (gateway) noch funktioniert und wenn das nicht mehr der Fall ist, den PI rebooten lassen.

ja genau so mach ich das. Von außen kommt man ja nicht mehr drauf zum booten.

Schick wäre wenn der Job das Interface wieder hinbiegen könnte.

Quote from Urs-1956

Hast du mal das Netzteil überprüft? Auch die altern und können das "Mysterium" erzeugen.

Ja, Netzteil. Da bin ich ständig am rumpopeln weil es der häufigste Treffer auf das Fehlerbild ist. Das PI hängt an einem 5V-5A Buck-converter der direkt den GPIO speist. Ich hab inzwischen 2x5V und 2xGND verkabelt incl. Stützkondensatoren ein paar cm vor der Einspeisung.

Ich gebe ein wenig über 5V drauf, um Stromspitzen (welche die Spannung runter ziehen) zu "puffern". Da reden wir aber max um die 0.2V.

Quote from Der_Imperator

Laut https://forums.raspberrypi.com/viewtopic.php?t=310765 hilft ein otg_mode=1 in der config.txt

Hmm, den Link kenne ich schon. OTG bedeutet doch das der Raspberry als Client arbeiten kann (im Gegensatz zu Host).
Das will ich eigentlich nicht, aber evtl. funktioniert es trotzdem ... ?

Das sind die letzten 15 "uptimes" bis zum Fehler, auch keine Logik drin. Aber kann schon mal 2 Wochen durchhalten wie ich sehe...

224.51h
362.45h
48.63h
78.00h
98.40h
119.83h
254.98h
280.06h
341.26h
17.91h
27.55h
111.77h
141.09h
147.22h
153.40h

Hallo,

Ich bin jetzt schon ein paar Monate auf der Suche nach einer Lösung für mein Problem mit dem Pi3. Dieses ist irgendwann einfach nicht mehr ansprechbar via Lan.

Das ganze läuft headless und steuert diverse Elektronik 24/7.

jetzt bin ich dahinter gekommen dass, das OS eigentlich durchläuft und nur die NIC nicht mehr arbeitet. Das Symthom ist immer gleich:

Der USB-Treiber wirft diesen "Fehler":
dwc2 3f980000.usb: dwc2_hc_start_transfer: chdis set, channel 2, hcchar 0xe1fc8808

(Keine weiteren Meldungen im dmesg.)

Ab dann sendet die interne NIC (lan78xx) keine Pakete mehr. Ping geht nicht raus und nicht rein. Device bleibt unverändert im lsusb. Interface wird vom Kernel weiter als online und verfügbar gezeigt. Ein networking restart bringt nix. Ich hab inzwischen auch alle anderen USB-Geräte vom gesharten Host-Port entfernt, Fehler zeigt sich unbeeindruckt.

Ich habe keine Undervolage-Meldungen.

Hat jemand eine Idee? Mir würde auch reichen wenn ich die NIC irgendwie resette. Derzeit boote ich das OS sobald ich den Fehler erkenne, das hilft dann wieder für Tage oder Wochen.

Kann man die interne NIC per USB stromlos machen (unbound)? Ich denke ich muss aber den dwc2 entladen und neu laden. Aber dazu müsste ich alle USB-Geräte trennen. Dann kann ich auch gleich booten.

Ok... die Auflösung der Geschichte ist folgende:

Wenn man das pigpio SPI Modul einmal verwendet hat, wird jeder folgende spidev Aufruf nicht mehr aktiv CS steuern.
Nach einem Reboot tut spidev wieder.

Nachdem ich immer mit pigpio rumgetestet habe, ist spidev immer ausgestiegen. Erst ein "Oszilloskop" hat mich auf die Lösung gebracht. Hier kann ich piscope empfehlen, weil man kein extra Gerät braucht (kann man auf dem PI laufen lassen wo auch der SPI Master läuft, also nur 1 PI).

Sprich mit 1m Kabel, spidev und dem System wie beschrieben angeschlossen auf SPI0 auf CE0, frisch gebooted, tut es.

OK geht so doch nicht. Denn der adxl345 unterstützt mehrere Register. Um die zu wechseln (bzw zu resetten) muss man den IC per CS abwählen. Sprich wenn ich den CS auf GND zwinge, hänge ich auf einem Register fest.

Ich hab inzwischen den ganzen Aufbau auf einem ESP8266 nachgebaut. Der adxl345 funktioniert. (Funktioniert ja auch am PI, nur halt ohne spidev).

Das hat was mit der Kombination von Linux-Kernel + bcm-Kernel-Modul zu tun.

Also... ich hab was, was für mich funktioniert.

Ich hab den CS Pin vom IC auf GND gezogen. Sprich der SPI Master auf dem PI kontrolliert nicht mehr CS. Das funktioniert zumindest für den Testcase hier. Ich hab aber auch nur einen IC am SPI BUS.

Und schon läuft die Kommunikation mit ioctl und auch spidev.
Klipper tut auch.

Ich frag mich allerdings warum ich zu dem Problem hier keine Treffer bei Google bekomme. So wie ich das lese ist das ein Fehler im Kernel(Kernelmodul) der seid 5.4 irgendwas drin ist. Die HW vom PI kann es, die OS-Software erlaubt es einfach nicht.
...Oder ich bin auf dem komplett falschen Dampfer unterwegs.

Wenn ich im pigpio den Mode 7 anfordere, bekomme ich auch 0 auf die 0x80 Anfrage. Damit schließt sich der Kreis.

Hi. Der C Code steigt bei 5kHz mit Fehlermeldung aus. 50kHz ist das langsamste was tut. Also hab ich das python mit 50kHz getestet. Keine Änderung im Verhalten.

Ich hab inzwischen das python modul spidev auseinandergenommen und die Initialisierung und Xfer2 in einem eigenen Binary übertragen.
Wie es ausschaut arbeitet spidev per ioctl direkt mit dem Kerneldevice.

Wenn ich auch so arbeite verhält sich das PI (oder der Kernel wie man es sieht) seltsam.

Was mir auffällt ist, dass wenn ich den SPI Mode abfrage ich 7 bekomme. Da ist ein Bit zu viel drin. Auch wenn ich vorher 3 setze. (Das kann richtig sein, müsste ich mich in die SPI Kernel Doku einlesen). SPIDEV greppt das Bit per default einfach mal weg.
Und ich bekomme bisher per ioctl auch nur 0 als Antwort auf die Anfrage 0x80.

Linux Kernel auseinander nehmen hab ich eigentlich keine Lust zu. Alternativ könnte man die pigpio Library auseinander nehmen was die anders macht das es da tut.

EDIT:
OK habs gefunden warum der 7 sagt. Das ist das Thema mit dem CS_HIGH. 0x04 ist das Bit für CS_HIGH. Zu dem Thema gibts ja auch Seitenweise Diskussionen im Internet. Da wurde das Verhalten in irgendeinem Kernelrelease verändert. Das ist nicht mehr setzbar.

EDIT2:
Pigpio popelt direkt per nmap im "Speicher" der Physik rum. Da ist gar kein Kernel(-aufruf) dazwischen. Wow...

Ja Sackgasse.

Hi, nein ich übermittle nicht 2 Byte. Ich sage ja spixfer explizit das es count "1" ist. Mach ich ja auch auf der CLI nicht.

Ist aber hin wie her, geht auch so nicht:

import spidev
import time

spi = spidev.SpiDev()
spi.open(0, 0)

spi.max_speed_hz = 5000
spi.mode = 3

reply=spi.xfer2([0x80, 0x00])
print(reply)

spi.close()

######
pi@mainsailos:~/Dokumente $ python test.py 
[0L, 0L]

Wenn man mehr als 1 Byte übertragen will müsste man das multibyte Bit noch setzen. Aber auch mit dem klappt es nicht.

Hallo,

ich hab folgendes Problem. Ich habe einen ADXL345 welchen ich per C++ auslesen kann und auch auf der CLI. Aber Python weigert sich.
Der Hintergrund ist das ich hier ein Mainsailos habe und das mit Klipper zum laufen bringen will. Also hab ich das ganze reversed runter zu simplen aufrufen:

Was hab ich:
Model : Raspberry Pi 4 Model B Rev 1.4
OS: Raspbian GNU/Linux 10 (buster)

Was möchte ich erreichen:

Ich sende dem ADXL345 ein 0x80 (ein "READ" | "Register 0" ) und erwarte ein E5 als Antwort (Q:"Hallo wer bist du." A: "Ich bin ein ADXL345").

CLI:

pi@mainsailos:~/ $ sudo systemctl start pigpiod 
pi@mainsailos:~/ $ pigs spio 0 2000000 3
0
pi@mainsailos:~/ $ pigs spix 0 0x80
1 229

#229 = E5 = OK!

C++:

#include <stdio.h>
#include <pigpio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    if (gpioInitialise() < 0) {
        printf("Failed to initialize GPIO!");
        return 1;
    }

    char data[7];
    int bytes=0;
    int h = spiOpen(0, 2000000, 3);
    data[0] = 0x80;
    data[1] = 0;
    bytes = spiXfer(h, data, data, 1);
    if( bytes ){
      printf("Got ID %x [%u]\n",data[bytes-1],bytes);
    }
    gpioTerminate();
    return 0;
}

###
pi@mainsailos:~/ $ sudo ./test
Got ID e5 [1]

Python:

import spidev
import time

spi = spidev.SpiDev()
spi.open(0, 0)

spi.max_speed_hz = 5000
spi.mode = 3

r=spi.xfer2([0x80])
print(r)

spi.close()

########

pi@mainsailos:~/ $ python test.py 
[0L]
pi@mainsailos:~/ $ python3 test.py 
[0]

Klipper geht natürlich auch nicht. Der meldet mir auch die Id 0 und verweigert den Dienst.

Irgendwas stimmt doch mit den Python Libraries nicht. Ideen?

Was ich bisher zum Thema gefunden habe ist das man zwingend den max_speed_hz setzen muss. Ansonsten kommt genau das verhalten. Aber das mache ich schon.

Ich könnte Hilfe gebrauchen...

Danke fürs lesen.

Hallo Forum,

ich würde gern den 5V per Spannungsüberwachung MCP3008 überwachen. Allerdings vergleicht der ja nur gegen den 3.3V als Referenzspannung. Sprich ich muss die 5V per Spannungsteiler in die 3V drücken, aber das ist gar nicht mein Problem.

Die Frage die sich mir stellt ist, wenn der 5V Eingang schwankt, schwankt der 3.3 Pin dann linear mit (hängt der auch nur per Spannungsteiler am 5V dran)? Weil dann wäre die Messung sinnlos, da sich Vref linear zur zu messenden Spannung ändert. Sprich mein ADC am MCP3008 bleibt konstant unabhängig von der eigentlichen Spannung.

Ich hab mal einen Test aufgebaut und bisher schaut es genau danach aus...

Ich hab ein Raspberry PI 1 2011.12 hier.

Frage: Ist der PIN1 ein auf 3.3V geregelter Ausgang?