Raspi 40-polige Steckerleiste:
Der gesunde Entwickler läßt an einer 40-poligen Steckerleiste immer noh
2 Pins frei
wenn die Entwicklung abgeschlossen ist. Merke: mit dem Raspi wird viel
gebastelt.
Der gesunde Entwickler vergißt nicht das Reset Signal auf diese
40-polige Steckerleiste zu legen.
Eigentlich solllte jeder Entwickler der das-ein Reset Signal vergißt
sofort aus der Firma
rausgeschmissen werden, vielleicht ist er dann noch als CEO oder
Kundesbanzler zu gebrauchen.
Schreib' doch mal was über den Raspi.
Falscher Empfänger.
Was soll das werden, ein öffentlicher Pranger?
Du beklagst dich also im Ernst über ein Produkt, dessen winziges
Designzie billig, billig, billig ist?
Es steht Dir frei, eine bessere Alternative herzustellen und zu
verkaufen.
Werner Schubert schrieb:> Eigentlich solllte jeder Entwickler der das-ein Reset Signal vergißt> sofort aus der Firma> rausgeschmissen werden
Es scheint sich noch nicht allgemein herumgesprochen zu haben, dass man
einen Rechner mit Linux, Windows usw. nicht einfach mit Reset abwürgt.
Dabei ist es schon seit mindestens 2 Jahrzehnten so, dass so ein Rechner
kontrolliert heruntergefahren werden sollte.
Ganz abgesehen davon, dass es einen Reseteingang gibt, nur nicht auf der
I/O-Steckerleiste, sondern auf einem Extra Stecker. Die Ahnungslosigkeit
ist wohl allumfassend, und wer da rausgeschmissen gehört ergibt da ganz
logisch.
Georg
Linux stürzt ja bekanntermaßen nicht ab ( ;-) ), also per gpio ein
Script triggern was des reboot auslöst. Aber warum? Linux braucht doch
auch keine reboots? ;-)
Aber mal ernsthaft, warum zwei Pins freilassen? Wenn dann einen
weglassen und das Loch im Stecker verschließen (Verpolungsschutz). Aber
warum zwei freilassen?
Horst S. schrieb:> Der Pi hat noch nicht einmal einen Startpinökel, geschweige denn einen> Ausschalter - also, was soll der Geiz?
Pin 5 gegen Masse hohlt den pi aus dem Tiefschlaf und lässt ihn wieder
booten.
Ne Hand voll Codezeilen und Pin 5 gegen Masse lässt den Pi wieder
Runterfahren wenn er den Gestartet ist. Nun hast du dein
ein/ausschalter.
georg schrieb:> Werner Schubert schrieb:>> Eigentlich solllte jeder Entwickler der das-ein Reset Signal vergißt>> sofort aus der Firma>> rausgeschmissen werden>> Es scheint sich noch nicht allgemein herumgesprochen zu haben, dass man> einen Rechner mit Linux, Windows usw. nicht einfach mit Reset abwürgt.> Dabei ist es schon seit mindestens 2 Jahrzehnten so, dass so ein Rechner> kontrolliert heruntergefahren werden sollte.>> Ganz abgesehen davon, dass es einen Reseteingang gibt, nur nicht auf der> I/O-Steckerleiste, sondern auf einem Extra Stecker. Die Ahnungslosigkeit> ist wohl allumfassend, und wer da rausgeschmissen gehört ergibt da ganz> logisch.>> Georg
Ja, dieses Reset-Signal habe ich auch schon auf zwei Pins auf dem
Kärtchen gefunden.
Noch was zum "Abwürgen Linux" eines obigen Posters.
Natürlich fährt man Linux anständig herunter.
Ich benutze das Reset-Signal doch nicht zum herunterfahren.
(Höchsten wenn er sich verpisst hat.)
Ja zu was dann ???
Wenn du freie Pins verwenden möchtest, dann musst Du sowieso am Raspi
rumlöten. Dann kannst du auch gleich die Leiterbahen trennen. Warum
schaded es, wenn der Hersteller alle Pins "vorbelegt"?
Stefanus F. schrieb:> Du beklagst dich also im Ernst über ein Produkt, dessen winziges> Designzie billig, billig, billig ist?
Das wäre jedenfalls kein Grund grobe Designfehler machen. Den Raspi hat
man nicht mal eben über Nacht zusammengekloppt. Der richtige Grund ist
eher: Das ist kein (grober) Designfehler.
Werner Schubert schrieb:> Das muß ich mir mal anschauen.> Danke.> Tiefschlaf.> ... auch wenn er sich verpisst hat ?
wenn er sich verpisst hat hast du verkackt.
Sinnvolle Antworten benötigen sinnvolle Fragen :)
Dirk D. schrieb:> Pin 5 gegen Masse hohlt den pi aus dem Tiefschlaf und lässt ihn wieder> booten.>> Ne Hand voll Codezeilen und Pin 5 gegen Masse lässt den Pi wieder> Runterfahren wenn er den Gestartet ist. Nun hast du dein> ein/ausschalter.
@Dirk Danke!
Werner Schubert schrieb:> Der gesunde Entwickler vergißt nicht das Reset Signal auf diese> 40-polige Steckerleiste zu legen.
Auf einem System mit Linux? Da schießt Du Dir mit Reset so derart in den
Fuß, das beide Unterschenkel gleich mit weg sind. Stichtworte: Kaputtes
Dateisystem oder Datenbank.
Und ja, auf einer SD Karte will man signifikant Daten im Schreib-Cache
zwischenlagern - die hat ja nur begrenzt Schreibzyklen.
Werner Schubert schrieb:> Der gesunde Entwickler läßt an einer 40-poligen Steckerleiste immer noh> 2 Pins frei
Wozu, wenn man die GPIOs abklemmen oder auf Input stellen kann?
Reine Verschwendung von Ressourcen, Board Space ist teuer.
Man könnte auch sagen, dass alle Laptops einen Designfehler haben, weil
sie keinen Reset-Knopf (und keinen Anschluss dafür) haben.
Die Sache mit dem Power-Knopf festhalten ist eher für Notfälle gedacht.
Beim Raspberry Pi würde das der Methode "Stecker ziehen" entsprechen.
Ja, Stecker ziehen, so habe ich das bis jetzt auch immer gemacht.
Aber jetzt habe ich ein kleines Gerät mit dem Raspi-Zero.
Da schreibe ich auch einige Code-Zeilen.
Oft schreibe ich Mist verpisst.
Da habe ich doch bedenken am kleinen USB Stromversorgungs-Stecker
dauernd zu ziehen deshalb der Reset-Taster.
> Da habe ich doch bedenken am kleinen USB> Stromversorgungs-Steckerdauernd zu ziehen
Hätte ich auch. Am anderen Ende des Kabels ist jedoch ein viel
robusterer Stecker.
gute Idee,
... aber da muß ich mich immer bücken liegt unterm Tisch,
manchmal haue ich mir beim Aufstehen dann den Kopf an.
Wieviele Steckungen hält so eine Micro USB Buchse aus.
mehr als 100, oder sogar 1000 ???
Das wäre auch interessant zu wissen für mein Handy.
Jim M. schrieb:> Stichtworte: Kaputtes Dateisystem
Das war mal, Linux hat mittlerweile mit Windows gleichgezogen was die
Robustheit der Dateisysteme angeht ;-)
FAT32 war schon unkaputtbar während sich Linux noch ständig selbst
zerlegt hat. Aber das ist schon sehr sehr lange her, heutzutage können
Dateisysteme das ab. Es besteht sogar die Möglichkeit Anwendungen so zu
schreiben das noch nicht mal deren offene Dateien kaputt gehen.
Also vorm Reset muss man keine Angst mehr haben, es sei denn Anwendungen
sind wirklich extrem schrottig programmiert.
nur zufällig hier schrieb:> Das war mal, Linux hat mittlerweile mit Windows gleichgezogen was die> Robustheit der Dateisysteme angeht ;-)
Ähm, nein. Siehe die Diskussionen zu SD-Karten.
Das beste Dateisystem bringt nichts, wenn die zugrundeliegende Hardware
unzuverlässig ist.
Werner Schubert schrieb:> ... aber da muß ich mich immer bücken liegt unterm Tisch,> manchmal haue ich mir beim Aufstehen dann den Kopf an.
Trollala - nicht das geringste Interesse an Lösungen, bloss immer neuer
Blödsinn.
Georg
> aber da muß ich mich immer bücken liegt unterm Tisch,
Dann lege Dir halt eine Steckdose auf den Arbeitstisch, wies es die
meisten Menschen tun. Aber wenn du einen Linux Rechner (selbst wenn es
ein Bastelgerät ist) häufiger als einmal pro Woche resetten mußt, läuft
ohnehin etwas gehörig schief.
Ich nehme an, dass du den "reboot" Befehl kennst, oder?
...wie habt ihr das gelöst mit dem reset per GPIO? Ein script was
ständig im Hintergrund läuft und den Pin pollt (müsste bei mir so
sein, da meine Taster über I2C angeschlossen sind) und dann den reboot
auslöst, wenn die Taste gedrückt wird?
Ich habe das Problem auch, weil ich headless arbeite, aber wenn die Inet
Verbindung weg ist, habe ich wieder die Finger am USB Micro Stecker ;)
Klaus.
Ich denke, der Raspberry Pi ist nicht für einen harten reset ausgelegt
(wie jeder PC). Die Methode, einen Pin per Script zu pollen scheint mir
daher naheliegend.
Werner Schubert schrieb:> Wieviele Steckungen hält so eine Micro USB Buchse aus.> mehr als 100, oder sogar 1000 ???
Das hängt hauptsächlich davon ab, wie oft man das Gerät bei
eingestecktem Kabel vom Tisch fegt. ;-)
Ansonsten:
USB2.0 Standard: 1.500 Steckzyklen, flash-vergoldet.
USB2.0 Mini: 5.000 Steckzyklen, 15µin vergoldet.
USB2.0 Micro: 10.000 Steckzyklen, 30µin vergoldet.
USB3.0 Standard: 5.000 Steckzyklen, 30µin vergoldet.
USB 3.0 Micro: 10.000 Steckzyklen, 30µin vergoldet.
Typ C: 10.000 Steckzyklen, 30µin vergoldet.
...kann man den RaspI dazu bringen, sich nach einem shutdown selbst vom
Strom zu trennen? Idee wäre ein kleines Relais bzw Mosfet, aber dazu
müsste man ja einen I/O Pin haben, der erst "ganz zum Schluß" auf LO
geht...die RTC vom shield könnte ihn dann auch wieder wecken.
Klaus.
Ob ganz am Ende des Shutdowns noch irgendein Pin den Shutdown-Status
anzeigen kann weiss ich nicht. Aber zeitverzögert geht es natürlich.
Also eine kleine Ansteuerung eines MOSFETs, die 20s nach Auslösung vom
Strom trennt. Dazu gibts noch einen Taster, der neben der RTC wieder
einschaltet.
...das mit der externen Zeitverzögerung ist klar - wäre aber eigentlich
am liebsten zu vermeiden, daher die Frage nach einem "pin" oder "pad"
oder sonstwas...wird beim power down vll die Stromversorgung einer
Peripherie beendet?
Klaus.
Klaus R. schrieb:> worst case muss das so
Wieso worst-case? Ist die simpleste Lösung; müssen ja auch keine 5s
sein, 100ms reichen genauso (und hast immer noch eine fette zeitliche
Reserve). Du musste doch nur unterscheiden ob die UART gerade sendet
oder abgeschaltet ist.
...wieso beziehst du dich auf die uart? Der Trick dahinter ist mir
unklar. Läuft die noch, wenn der RasPi runterfährt? Ich vermute die wird
zml schnell abgeschaltet - und ich möchte eigentlich keine externe
Schaltung (NE555 o.ä.) dafür aufbauen.
Klaus.
Hallo zusammen,
noch eine weitere Frage:
Ich habe versch scripte, die auf ein über i2c angebundenes user
interface (Tasten & LCD) zugreifen - das geschieht für die Tasten zB
über "button_stop=$(bw_tool -a 94 -I -D /dev/i2c-1 -a 94 -R 23:s)".
Wenn nun verschiedene scripte async. auf die Fkt zugreifen, kommt es
aber zum chaos, bw_tool gibt dann tw falsche werte zurück.
-> Ziel wäre nun ein zentrales script anzulegen, welches die
lese/schreiboperationen übernimmt und diesem Script über "globale
variablen" mitzugeben, was zu tun ist...
Ist das vorgehen korrekt? Wie legt man solche GV an?
Klaus.
Alexander S. schrieb:> Ja, das ist ja der Witz dabei.
Nein, der eigentliche Witz ist: Wenn der Raspi bei nem Update mal wieder
am Uart-Treiber rumfummelt, und dabei den Uart disabled, schießt er sich
während des Updates selber ab.
Kommt mit auf meine Liste der bescheuerten Ideen.
...grmpf - korrekt. Könnte man nun noch mit einem GPIO wired-or-en, aber
das ist auch schon wieder Müll. Ohne das update Problem wärs allerdings
ne gute Lsg (gewesen)...bzw, wenn man bei nem Update auf "dauer ein"
schaltet, ist es ja auch egal? Das muss man ja eh selber anstoßen, von
daher...
Klaus.
Werner Schubert schrieb:> aber da muß ich mich immer bücken liegt unterm Tisch,> manchmal haue ich mir beim Aufstehen dann den Kopf an.
Offenbar hat das schon zu Dauerschäden geführt.
Das ist dann aber ein medizinisches Problem, kein technisches.
Klaus R. schrieb:> Könnte man nun noch mit einem GPIO wired-or-en, aber> das ist auch schon wieder Müll.
Man könnte auch einfach einen nicht anderweitig benutzten GPIO mittels
Monoflop das Abschalten verzögert erfolgen lassen. Dabei würde ich
allerdings darauf achten, dass auch der Puls vom GPIO eine Mindestlänge
haben muss.
So oder so kommst Du um eine externe Schaltung nicht herum. Ob das ein
555 oder ein ATtiny ist.
Klaus R. schrieb:> ...wie habt ihr das gelöst mit dem reset per GPIO?
Taster zwischen Pin 4 und Pin 6.
NICHT NACHMACHEN, KINDER!
Im Ernst, ich hatte mal das Problem, dass sich der Raspi regelmäßig
festgefahren hat, so richtig mit eingeschlafenem Bild und keinerlei
Reaktion. Hab extra eine 2-polig Stiftleiste zum Reset aufgelötet.
Nach Wechsel der SD-Karte keine Probleme wieder.
A. K. schrieb:> USB2.0 Standard: 1.500 Steckzyklen, flash-vergoldet.> USB2.0 Mini: 5.000 Steckzyklen, 15µin vergoldet.> USB2.0 Micro: 10.000 Steckzyklen, 30µin vergoldet.
Nach meiner Erfahrung geht Micro am Schnellsten kaputt, sowohl der
Stecker als auch die Buchse. Gefolgt von Mini. Einen kaputten
Standardstecker hatte ich selber noch nie.
Bei Micro hatte ich schon mehrere ausgerissene Buchsen (Was vermutlich
bei den Zyklen nicht mitgezählt wird).
Außerdem: Kann es sein, dass bei den Zyklen nur die Buchse
berücksichtigt wird, bei den Micro-Steckern sind die Federkontakte ja im
Stecker?
Karl K. schrieb:> So oder so kommst Du um eine externe Schaltung nicht herum. Ob das ein> 555 oder ein ATtiny ist.
Was spricht gegen die einfache Kondensator Lösung?
Kondensator mit passendem Widerstand der rund 10s auf High hält, an
einen Pin sowie an den Ein-Schalter legen.
Dazu irgendwo früh im Bootprozess, den Pin auf high setzen.
Wenn nun der Knopf gedrückt wird, wird der Kondensator schnell geladen
und hält den Pegel high bis das der Pin übernimmt.
Beim Ausschalten fällt der Pin auf Low, der Kondensator entlädt sich und
irgendwann ist das Signal auch auf low.
Alex G. schrieb:> der Kondensator entlädt sich und> irgendwann ist das Signal auch auf low.
Ja und dann? Was machst Du mit dem "Signal"?
Der - je nach Sichtweise - Vor- oder Nachteil der GPIOs am Raspi ist,
dass jedes Programm drauf zugreifen darf. Und man kann meines Wissens
auch keinen GPIO "sperren". Es kann also immer sein - und ist mir auch
passiert -, dass andere Programme den Zustand der GPIOs ändern, zum
Beispiel bei einem Update, oder wenn man Node-Red startet.
Deswegen würde ich so eine Lösung möglichst nicht von einem Zustand
abhängig machen, sondern von einem Vorgang, wie einem für bestimmte Zeit
auf High gesetzten GPIO. Sonst kann es passieren, dass Dein Raspi
plötzlich ausgeht und Du weisst nicht warum.
A. K. schrieb:> USB2.0 Micro: 10.000 Steckzyklen, 30µin vergoldet.
Schöne Theorie. Der Kontakt zwischen Stecker und Buchse mag sehr gut
sein. Das wird erreicht durch sehr wenig Spiel.
In der Praxis macht gerade das der Rest aber mechanisch nicht lange mit.
Entweder sind die Stecker/Kabel bald hinüber oder die Buchse irgendwo
abgerissen.
Karl K. schrieb:> Alex G. schrieb:>> der Kondensator entlädt sich und>> irgendwann ist das Signal auch auf low.>> Ja und dann? Was machst Du mit dem "Signal"?
Achso, hätte ich noch dazu schreiben. Das Relais wurde weiter oben
erwähnt.
An das Signal hängt ein Mosfet welcher entweder direkt (oder für
absolute Trennung, ein Relais schaltet welches widerum) die
Hauptversorgung des Raspberries betreibt.
Das Relais wird dabei auch mit dem Schalter verbunden damit es
durchschaltet sobald man das Gerät einschalten will.
Karl K. schrieb:> Der - je nach Sichtweise - Vor- oder Nachteil der GPIOs am Raspi ist,> dass jedes Programm drauf zugreifen darf. Und man kann meines Wissens> auch keinen GPIO "sperren". Es kann also immer sein - und ist mir auch> passiert -, dass andere Programme den Zustand der GPIOs ändern, zum> Beispiel bei einem Update, oder wenn man Node-Red startet.>> Deswegen würde ich so eine Lösung möglichst nicht von einem Zustand> abhängig machen, sondern von einem Vorgang, wie einem für bestimmte Zeit> auf High gesetzten GPIO. Sonst kann es passieren, dass Dein Raspi> plötzlich ausgeht und Du weisst nicht warum.
Sinnvolle bedenken, allerdings reden wir ja hier von einem
Embedded-ähnlichen Aufbau. D.h. man sollte schon wissen was die Software
genau tut.
Während dem Entwickeln und Debuggen braucht man das Abtrenn-System nicht
wirklich da es nicht um Akkuverbrauch geht.
Man könnte also nen kleinen Schalter oder Jumper vorsehen, der den
Kondensator immer geladen hält.
Das Runterfahren an sich wird ja per Software ausgelöst, nicht über den
GPIO.
Einziges Problem besteht vielleicht wenn man auf dem "Endprodukt"
Updates laufen lassen will und entsprechend dann nicht der "immer on"
jumper gesetzt ist.
Alex G. schrieb:> An das Signal hängt ein Mosfet welcher entweder direkt (oder für> absolute Trennung, ein Relais schaltet welches widerum) die> Hauptversorgung des Raspberries betreibt.
Ein langsam fallender Pegel an einem Mosfet, der ein Relais schaltet.
Wunderbar definiert.
Bau wenigstens einen Schmitt-Trigger mit zwei Transistoren.
Alex G. schrieb:> allerdings reden wir ja hier von einem> Embedded-ähnlichen Aufbau. D.h. man sollte schon wissen was die Software> genau tut.
Sorry, nein. Ich finde auf meinem Raspi mit Standardeinrichtung immer
wieder Programme oder Services, von denen ich keinen Plan habe was die
machen oder wozu die gut sind.
Das System ist inzwischen dermaßen komplex, das durchschaut keiner mehr
mal eben so. Zum Beispiel waren bei den letzten Updates reihenweise
Änderungen am "kernelhack" dabei. Also den Änderungen am Linux-Kernel,
die speziell für den Raspi sind.
Ich hab eine Dauermessung per Uart laufen. Da hat mir irgendwas immer
nach ein paar Tagen die Baudrate am Uart zurückgesetzt, so dass die
Anfragen nicht beantwortet wurden. Keine Ahnung welcher Service dafür
zuständig ist. Jetzt schreibe ich vor jedem Uart-Zugriff die Parameter
neu und hab Ruhe.
Klaus R. schrieb:> Hallo zusammen,>> noch eine weitere Frage:>> Ich habe versch scripte, die auf ein über i2c angebundenes user> interface (Tasten & LCD) zugreifen - das geschieht für die Tasten zB> über "button_stop=$(bw_tool -a 94 -I -D /dev/i2c-1 -a 94 -R 23:s)".> Wenn nun verschiedene scripte async. auf die Fkt zugreifen, kommt es> aber zum chaos, bw_tool gibt dann tw falsche werte zurück.>> -> Ziel wäre nun ein zentrales script anzulegen, welches die> lese/schreiboperationen übernimmt und diesem Script über "globale> variablen" mitzugeben, was zu tun ist...>> Ist das vorgehen korrekt? Wie legt man solche GV an?>> Klaus.
...jmd einen konstruktiven Kommentar dazu? ;)
Klaus.
Hallo Andreas,
und diese existieren dann, weil vererbt von einem sehr frühen Prozess,
immer und man kann sie zum Austausch zwischen untersch. scripten nutzen,
die sich zur Laufzeit gestartet und auch wieder beendet werden?
Ich würde zB gerne die Taste 5 meines ui_shields in einem script dauernd
auslesen und dann "global" für andere scripte zur Verfügung stellen -
die können dann, je nach ihrer Funktion, entscheiden was sie mit der
Info tun. Andersrum sollten diese auch in den lcd_buff schreiben können
und das "change" flag setzen - dann schreiben die anderen nicht mehr,
bis in der main lcd_buff geleert und das flag zurückgenommen wurde...
Oder ist das so "bullshit"? Bei einem AVR würde ich das so machen. Ob
das bei einem RasPi aber schlau ist, weiß ich nicht.
Danke.
> Nach meiner Erfahrung geht Micro am Schnellsten kaputt, sowohl der> Stecker als auch die Buchse. Gefolgt von Mini. Einen kaputten> Standardstecker hatte ich selber noch nie.
Dito. Die versprochenen Zahlen sind wohl nur unter unrealistischen
Laborbedingungen entstanden.
> bei den Micro-Steckern sind die Federkontakte ja im Stecker?
Das allerdings finde ich gar nicht mal dumm, denn so kann man einfach
das Kabel auswechseln, wenn die Kontakte locker werden.
Ich stehe ja total auf magnetische Stecker, die gibt es (bis 1A) auch
zum Nachrüsten. Sie haben zwar häufiger Kontaktfehler, aber das lässt
sich leicht mit einem Tuch und/oder Zahnstocher beheben. Dafür fürchte
ich nie wieder, eine Buchse abzubrechen.
Klaus R. schrieb:> Hallo Andreas,>> und diese existieren dann, weil vererbt von einem sehr frühen Prozess,> immer
Ja.
> und man kann sie zum Austausch zwischen untersch. scripten nutzen,> die sich zur Laufzeit gestartet und auch wieder beendet werden?
Nein. Änderugnen, die in Kindprozessen geschehen haben keine
Auswirkungen auf das Environment des Elternprozesses.
> Ich würde zB gerne die Taste 5 meines ui_shields in einem script dauernd> auslesen und dann "global" für andere scripte zur Verfügung stellen -> die können dann, je nach ihrer Funktion, entscheiden was sie mit der> Info tun. Andersrum sollten diese auch in den lcd_buff schreiben können> und das "change" flag setzen - dann schreiben die anderen nicht mehr,> bis in der main lcd_buff geleert und das flag zurückgenommen wurde...
Für Parallelprogrammierung gibt es diverse Konzepte zur Synchronisation
von Prozessen bzw. deren Datenaustausch untereinander. Sieh dir mal
"Monitor", "Semaphor", "Queue" an - das kann man auch aus der Shell
heraus benutzen (Semaphore z.B. über Filelocking, Queues über FIFOs aka
"named pipes").
> Oder ist das so "bullshit"? Bei einem AVR würde ich das so machen. Ob> das bei einem RasPi aber schlau ist, weiß ich nicht.
Man sollte schon mal ein paar Vorlesungen über Parallelprogrammierung
gehört bzw. ein paar gute Bücher dazu gelesen haben. Die Tücken stecken
wie üblich in den nicht so offensichtlichen Fällen/Situationen, die man
selten findet, ohne darauf hingewiesen zu werden.
Stefanus F. schrieb:> Das allerdings finde ich gar nicht mal dumm, denn so kann man einfach> das Kabel auswechseln, wenn die Kontakte locker werden.
Nunja, ich hatte auch schon ein Gerät, da hat sich beim zweiten Mal
einstecken einfach der Kontaktsatz in der Buchse nach Hinten geschoben.
Und ja, der Stecker war richtig rum. ;-)
Ich hab dann das Gerät aufgemacht, den Kontaktsatz wieder vorgeschoben
und dahinter Kleber gepappt. Nicht schön, aber ging.
Andererseits hab ich auch schon USB-A Buchsen gehabt, die am PC komplett
zerstört waren, weil die Leute die Stecker falschrum versucht haben
reinzustecken, oder was auch immer die da gemacht haben.
Meinen Raspi versorge ich über die Stiftleiste mit 5V, weil ich der
µ-USB auf Dauer auch nicht traue.
Ich vermute, die meisten Mikro-USB Anschlusse gehen nicht aufgrund
normaler Steckvorgänge kaputt, sondern aufgrund von Gewalt. Zu jener
Zeit, als man Handys und Tablets noch ohne destruktive Nebenwirkungen
auf bekam, gehörte neben dem Panel die Platine für diesen Anschluss zu
den häufigsten Ersatzteilen. Nicht aufgrund von Abnutzung, sondern
aufgrund von Schwerkraft und Hebelgesetz.
Hallo Ralf,
ja, an sowas wie Semaphoren dachte ich auch schon, das ist aus der RT
Vorlesung hängen geblieben :) Named Pipes liefen mir auch schon über den
weg und "naiv" betrachtet ist das eine Datei, in der alle schreiben und
lesen könne - was ja exakt das ist, was ich benötige, einen "blinden
Briefkasten" :)
Danke, Klaus.
A. K. schrieb:> Nicht aufgrund von Abnutzung, sondern> aufgrund von Schwerkraft und Hebelgesetz.
Und manchmal durch Vorsatz des Herstellers: Ich hab hier noch ein
"Kannst Du das reparieren"-Navi rumliegen, wo die Mini-USB-Buchse so
bescheuert angebracht ist, dass der ständige Zug durch das Kabel die
abgedreht hat.
Allerdings: Angesicht dessen, dass man bessere Navi-Apps aufs Smartphone
bekommt, war das Reparieren dann doch nicht so wichtig. Deswegen liegt
das Ding noch rum.
A. K. schrieb:> Ich vermute, die meisten Mikro-USB Anschlusse gehen nicht aufgrund> normaler Steckvorgänge kaputt, sondern aufgrund von Gewalt.
Im Prinzip hast du recht, nur eben nicht durch einmalige rohe Gewalt,
sondern viele kleine Gewalten. "Normale" gewaltfreie Steckvorgänge
brauchen beim Microstecker viel Feingefühl und Geduld. Eine USB-A oder
USB-Mini Verbindung hat Spielraum, der bei der Microverbindung fehlt. So
geht jede Krafteinwirkung unmittelbar auf Buchse und/oder Stecker.
Klaus R. schrieb:> Ich habe das Problem auch, weil ich headless arbeite, aber wenn die Inet> Verbindung weg ist, habe ich wieder die Finger am USB Micro Stecker ;)
Was macht Ihr eigentlich für komische Sachen mit Euren Pis, daß die
"sich verpissen" (TO) bzw. "die Inet Verbindung weg ist"? ;-)
Ansonsten einfach ein Netzteil mit USB-Buchse Typ A benutzen, die ist
robuster.
...das "Drecksteil" verbindet sich halt nicht immer mit dem WLAN nach
dem Booten, da bleibt mir nichts anderes übrig (gut, es gibt jetzt eine
Taste für den sauberen reboot via script), aber mich nervst es trotzdem,
dass es nicht geht...:
# prüfen ob wlan0 läuft, wenn nicht, bis zu 5 Verbindungsversuche
while [ -z "$(ifconfig wlan0| grep RUNNING)" ]
...
# Zwangskopplung...die aber nicht klappt :/
sudo iwconfig wlan0 essid ABC key s:ABC
Klaus.
Das ist keine Zwangskopplung. Damit konfigurierst du lediglich SSID und
Passwort, so wie es bei Systemen mit grafischem Desktop normalerweise
der NetworkManager macht. Eine denkbare Ursache wäre, dass dein AP den
Verbindungsaufbau verweigert hat. Ich hatte das mal sporadisch mit
einigen (aber nicht allen) Smartphones und allen ESP8266 Modulen. Ein
neuer Router für 16 Euro hat das Problem behoben.
Wenn er sich nicht automatisch verbindet, hat das irgendeinen Grund,
nach dem würde ich forschen. Heiße Kandidaten sind die Logfiles in
/var/log, der dmesg Befehl und die Befehle "journalctl -b" und
"journalctl -xe".
Hallo Stefanus,
Danke...ich bin noch basolut neu im Linux Umfeld, aber das ist mein bis
her letztes großes Rätsel zu dem man im Inet auch nichts findet (außer
ähnliche Probleme). Kennst du einen Befehl für den Zwangs-Reconnect? Wie
gesagt, er sieht meine SSID, aber...
dmesg bei erfolgreichem connect - vll warte ich einfach nicht lange
genug mit dem start meiner scripte, 42s bis "link ready" ist lang:
[ 21.965820] usb 1-1.2: r8712u: CustomerID = 0x0000
[ 21.965848] usb 1-1.2: r8712u: MAC Address from efuse =
00:1f:1f:d8:4a:e9
[ 21.965863] usb 1-1.2: r8712u: Loading firmware from
"rtlwifi/rtl8712u.bin"
[ 21.990171] usbcore: registered new interface driver r8712u
[ 24.263713] r8712u 1-1.2:1.0 wlan0: 1 RCR=0x153f00e
[ 24.264506] r8712u 1-1.2:1.0 wlan0: 2 RCR=0x553f00e
[ 26.523870] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 28.863877] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 31.753696] fuse init (API version 7.26)
[ 31.754051] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 42.215911] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
journalctl:
Jul 22 01:50:29 oneplus_PI Autostart[215]: wlan0: Fehler beim Auslesen
der Schnittstelleninformation: Gerät nicht gefunden
...
Jul 22 01:50:37 oneplus_PI systemd[1]: Found device RTL8191SU 802.11n
WLAN Adapter.
Jul 22 01:50:37 oneplus_PI systemd[1]: Started ifup for wlan0.
Jul 22 01:50:37 oneplus_PI ntpd[343]: error resolving pool
3.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jul 22 01:50:37 oneplus_PI dhcpcd-run-hooks[398]: wlan0: starting
wpa_supplicant
Jul 22 01:50:37 oneplus_PI wpa_supplicant[403]: Successfully initialized
wpa_supplicant
Jul 22 01:50:37 oneplus_PI wpa_supplicant[403]: nl80211: Driver does not
support authentication/association or connect commands
Jul 22 01:50:38 oneplus_PI wpa_supplicant[403]: nl80211: deinit
ifname=wlan0 disabled_11b_rates=0
...
Grmpg...also muss ich mich doch mit Tastatur & Monitor anschließen und
nochmal genauer sehen, was im Fehlerfall passiert. Oder RemDesktop per
LAN, das wäre besser...
Klaus.
> Kennst du einen Befehl für den Zwangs-Reconnect?
Nein, tut mir leid.
Google mal nach der Fehlermeldung "raspberry nl80211: Driver does not
support authentication/association or connect commands". Das wurde wohl
schon öfters diskutiert.
Klaus R. schrieb:> Kennst du einen Befehl für den Zwangs-Reconnect?
Es gibt keinen "Zwangs-Reconnect". Wenn man das Netzwerk ordentlich
konfiguriert hat, dann braucht man das auch nicht. Du kannst aber das
gesamte Interface töten und neu aufbauen:
1
$ ifdown wlan0 && ifup wlan0
Damit das funktioniert, musst du das Netzwerk ordentlich konfiguriert
haben. Das machst du auf Debian-artigen Systemen (ich zähle Raspbian
dazu) über die Datei /etc/network/interfaces.
Trage da für deinen WLAN-Adapter einen Block wie folgt ein:
1
allow-hotplug wlan0
2
iface wlan0 inet dhcp
3
wpa-ssid hier_deine_ssid
4
wpa-psk hier_dein_passwort
Beachte, dass da schon irgendwas stehen könnte. Und es kann sein, dass
irgendein anderes Programm (ifplugd, NetworkManager oder so) in deinem
Netzwerk rummacht und die Verbindung kaputtmacht. Der Raspi nutzt ein
etwas spezielles Setup.
...sich DIREKT über eth mit dem RasPi zu verbinden ist ja ein einziger
Krampf. OMG. Da das nicht erfolgreich war, lasse ich nun im wlan
Fehlerfall dmesg in eine log Datei mit Datum umleiten...mal sehn.
Klaus.
SSH geht ja einwandfrei, WENN sich wlan0 sauber connceted...aber das tut
es nicht. Direkt über eth0 geht es dann auch nicht, laut google muss man
da zml tricksen...der rechner findet den raspi nicht über lan, sogar
WENN er sauber gebootet hat (und SSH über wlan möglich ist). Wenn der
Link Recht hat
(http://www.circuitbasics.com/how-to-connect-to-a-raspberry-pi-directly-with-an-ethernet-cable/)
ist das halt schon seeehr umständlich.
Ich logge jetzt mal über: dmesg >
/home/pi/Schreibtisch/Backup/dmesg_"$time"...im Moment geht es aber, vll
weil ich mal das komplette Netzwerkzeug gelöscht und neu
aufgesetzt/konfiguriert habe.
Klaus.
Meiner hat auf Anhienb getan was er sollte. Für mich war die größte
"Hürde", herauszufinden wie man ssh ohne Tastaur aktiviert.
Vielleicht musst du dein Gerät einfach noch mal neu installieren. Für
ganz bequeme Leute gibt es fertige sets mit vorinstallierter
Speicherkarte, Gehäuse und einem gut geeignetem Netzteil. Ist erwas
teurer als Einzelteile aber ich kann es aufgrund tadelloser Erfahrung
nur empfehlen.
...hm, so dachte ich mir das ja auch. Wie gesagt, über WLAN habe ich
null Probleme mit Remote_Desktop, aber stöpsel ich das NB direkt an den
Raspi...finde ich den nicht. Und das erschließt sich mir erstmal nicht,
vermutete aber das liegt am fehlenden AccesPoint der ja sonst dazwischen
hängt. Aber mir fehlt die Erfahrung, klar.
Da nach der Neu-Konfig des WLANs jedoch erstmal alles besser geht und
ich im Zweifelsfall über "dmesg >
/home/pi/Schreibtisch/Backup/dmesg_"$time"" einen log haben würde, ist
das erstmal wieder sekundär...
Danke & guten Wochenstart!
Schließ dich doch einfach mal lokal an das Teil an. Also mit
Fernseher+Tastatur oder serieller Schnittstelle. Da kannst du das Log
drauf werfen und live zugucken.
Bedenke, dass irgendwelche Hintergrundprogramme an deinen
Netzwerkeinstellungen rumspielen, wenn du ein LAN-Kabel reinsteckst,
rausziehst, drin hast oder nicht drin hast. Das macht das
Experimentieren nicht gerade einfacher.
Zwischen zwei Computer gehört normalerweise ein Switch.
Wenn eines der beiden betroffenen Geräte die Option Auto-MDI/MDIX
unterstützt, geht es auch ohne Switch. Der Raspberry Pi kann das und
viele Laptops auch. Wenn beide Geräte diese Option unterstützen, kommt
es bei der Direkt-Verbindung wiederum manchmal zu Kompatibilitäts
Probleme.
Das Problem ist: Beide Geräte merken "Huch, ein Kurzschluss am Netzwerk
Anschluss". Dann vertauschen sie Eingang mit Ausgang. Wenn das beide
Geräte gleichzeitig tun, hast du deswegen danach wieder einen
Kurzschluss.
https://de.wikipedia.org/wiki/Medium_Dependent_Interface
Stefanus F. schrieb:> Zwischen zwei Computer gehört normalerweise ein Switch.
Reicht nicht!
Einen DHCP-Server braucht man auch noch (zummindest mit der
default-Konfiguration)
...und genau da greift dann wieder der von mir gepostete Link und dessen
Inhalte bezeichne ich im Vergleich zu einer Verbindung mit Wlan durchaus
als "komplex" :)
Klaus.
Klaus R. schrieb:> bezeichne ich im Vergleich zu einer Verbindung mit Wlan durchaus> als "komplex" :)
Wenn dir das schon zu komplex ist, laß besser die Finger von Netzwerken
oder lern erstmal ein paar Grundlagen!
Daran ist gar nix komplex!
Wenn man grundlegend verstanden hat, wie TCP/IP funktioniert ist das
lachhaft trivial.
> Einen DHCP-Server braucht man auch noch
Ach ja, richtig. Hatte ich vergessen. Windows gibt sich notfalls selbst
eine Standard-Adresse, aber Linux macht das normalerweise nicht.
> bezeichne ich im Vergleich zu einer Verbindung mit Wlan> durchaus als "komplex"
Bei WLAN benötigst du statt Switch einen Access Point, der DHCP Server
ist auch bei WLAN nötig.
Man kann ohne DHCP auskommen, wenn man dem Interface ein feste
IP-Adresse gibt. Bei WLAN verweigern dann allerdings mache Access Points
jegliche Datenübertragung.
Stefanus F. schrieb:> Man kann ohne DHCP auskommen, wenn man dem Interface ein feste> IP-Adresse gibt. Bei WLAN verweigern dann allerdings mache Access Points> jegliche Datenübertragung.
Sicher nicht, wenn die feste Address-Zuordnung korrekt ist.
Es gibt überhaupt keinen Grund, warum das nicht funktionieren sollte.
> Es gibt überhaupt keinen Grund, warum das nicht funktionieren sollte.
Glaube mir, es gibt WLAN Router, die Routen nur auf mobile Geräte,
welche zuvor ihre Adresse via DHCP angefordert haben. Du kannst gerne
vorbei kommen und Dir den Router angucken, der liegt noch im Keller. Er
hat noch ein paar andere Überraschungen im Petto.
Stefanus F. schrieb:>> Es gibt überhaupt keinen Grund, warum das nicht funktionieren sollte.>> Glaube mir, es gibt WLAN Router, die Routen nur auf mobile Geräte,> welche zuvor ihre Adresse via DHCP angefordert haben. Du kannst gerne> vorbei kommen und Dir den Router angucken, der liegt noch im Keller. Er> hat noch ein paar andere Überraschungen im Petto.
Das wäre nicht RFC-Konform, und hat auch mit "routen" nichts zu tun.
Wenn dem so wäre, wären dafür explizite Firewall-Regeln erforderlich.
Sowas hab ich noch bei keinem Access-Point gesehen.
Klaus R. schrieb:> stöpsel ich das NB direkt an den Raspi...
Musst du vorher feste IP Adressen und Subnetzmaske bei deinem PI
einstellen. (beiden Rechnern eventuell, es sei denn wie erwähnt windows
verhält sich erwartungsgemäß und gibt sich selbst eine ip usw...)
Aber, am einfachsten wird es sein den PI über den heimischen Router
laufen zu lassen. Die ip steht dan im webinterface und du kannst die
problemlos für SSH/Remote nutzen.
Egal ob WLAN oder Kabel.
Stefanus F. schrieb:> Google mal nach der Fehlermeldung "raspberry nl80211: Driver does not> support authentication/association or connect commands".
Abhilfe nennt sich wext:
https://blog.wronnay.net/raspberry-pi-wlan-geht-nicht-driver-does-not-support/
Manche WLAN-Sticks machen ein bisschen zicken. Aber häufig gibt eine
Möglichkeit es trotz allem gangbar zu machen.
Stefanus F. schrieb:> Ich bin inzwischen bei einer Fritzbox angelangt, die tut was sie soll.
Dito, für die gibts sogar (Früher Tomato?!... erinnere mich da an was)
https://www.freetz.org/
Die sind durchaus nützlich, ich mag die auch. ;-)
