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.
Beitrag #5427188 wurde von einem Moderator gelöscht.
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.
Der Pi hat noch nicht einmal einen Startpinökel, geschweige denn einen Ausschalter - also, was soll der Geiz?
> dessen winziges Designzie
Sorry, es sollte heissen:
dessen einziges Designziel billig, billig, billig ist.
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 ???
Das muß ich mir mal anschauen. Danke. Tiefschlaf. ... auch wenn er sich verpisst hat ?
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!
Steckerleiste Pin 5 Signal-Name: SCL; das ist die i2C Schnittstelle. (mit der habe ich am Raspi noch nicht gearbeitet. (kommt noch).
warum freilassen ???? ... für vergessliche Entwickler zum nachbasteln.
Angehängte Dateien:
-
IMG_20180519_112427.jpg
240 KB
Hier meine Quelle: http://www.barryhubbard.com/raspberry-pi/howto-raspberry-pi-raspbian-power-on-off-gpio-button/ Im schlimmsten fall sieht das dann so aus wie hier.
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.
Geile Gehäuse Simulation. Raspi voll benutzt alles belegt. Außer der 40-poligen Buchsenleiste. Na, das würde dann noch alles viel schlimmer aussehen.
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.
der neueste Raspi 3B+ soll 2,5 Amp. max. ziehen. Wird das auch über diesen Stecker gejagt ?
nur zufällig hier schrieb: > Linux stürzt ja bekanntermaßen nicht ab ( ;-) ) Nur, wenn man die Katze nicht an die Tastatur lässt ... http://lkml.iu.edu/hypermail//linux/kernel/1111.0/01288.html
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
...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.
:
Bearbeitet durch User
...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: > wird beim power down vll die Stromversorgung einer > Peripherie beendet? UART? TX low > 5s -> Abschalten
>> UART? TX low > 5s -> Abschalten > externen Zeitverzögerung ... wäre aber ... zu vermeiden
Danke, Stefanus :) ...worst case muss das so, aber...bei einem AVR wäre das ja auch nicht nötig :) 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.
Klaus R. schrieb: > Läuft die noch, wenn der RasPi runterfährt? Ja, das ist ja der Witz dabei. Schau mal hier, Verzögerung nur per Kondensator: https://www.raspberrypi.org/forums/viewtopic.php?t=13268&f=44#p205664
Danke Alex, DANN habe ich deinen Beitrag verstanden und das bringt mich ein großes Stück weiter. An einen C dachte ich natürlich auch schon ;) 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Globale Variablen legt man am besten in der /etc/profile an: MeineVar = wasauchimmer export MeineVar
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
> 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.
....das hab ich auch alles schon durch. Ich forsche mal in den logs über eth0 RDP...so einfach ist das halt nicht ;) Klaus.
...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.
Dein Setup ist irgendwo kaputt. Es gibt wenig stabileres als sich per SSH irgendwo auf ne Konsole zu hängen.
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.
Klaus R. schrieb: > sich DIREKT über eth mit dem RasPi zu verbinden ist ja ein einziger > Krampf. Häh? Anstecken und geht. Wo ist das Problem?
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!
:
Bearbeitet durch User
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.
...bash, bash! Vielleicht beschäftige ich mich damit, wenn mich das interessiert. Tut es aber gerade nicht (mehr). Klaus.
> 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.
...und exakt letzters ist mir beim ersten Versuch passiert ;) Wlan geht nach dem dann nötigen wipe_out aber nun dtl zuverläsdiger. Klaus.
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.
Bei Geräten für 15€ ist nicht unmöglich. Ich bin inzwischen bei einer Fritzbox angelangt, die tut was sie soll.
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. ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.