Posts by PInguin

    Hallo reraspi!


    So ein Bash-Script ist klasse!


    Leider funktioniert es nicht mit dem LCD-Modul, das ich einsetzen möchte. Ich benutze das gleiche Modul (inkl. dem "Rucksack"), das auf dieser Seite verwendet wird:


    http://www.raspberrypi-spy.co.…en-with-the-raspberry-pi/


    Mit dem dort bereitgestellten Python-Programm läuft mein Modul, es ist also in Ordnung und ich habe alles richtig verdrahtet. Ich würde aber viel lieber Dein Bash-Skript benutzen, um das Modul anzusteuern, da ich das viel einfacher von eigenen Skripten aufrufen kann.


    Ich schätze, es müssen einige Parameter in Deinem Skript an dieses Modul angepasst werden. Kannst Du mir sagen, welche das sind? Danke im Voraus!


    doch ginge


    du willst ja nur 56 Tasten!


    Ne, das mit den 56 Tasten ist jemand anders. :)


    Ich will "nur" 5 Taster und 5 dreifarbige LED als Zustandsanzeige anschließen.


    Quote


    also wären 8 Ports frei aber das wird eine Knobelei


    Knobelei in Form von Programmierarbeit oder von Lötarbeit?

    Danke für die Erklärung! Das bringt mich schon weiter. :)


    Wenn ich das richtig verstanden habe, kann ich mit einem dieser Bausteine nicht gleichzeitig Taster abfragen und LEDs schalten, sondern ich benötige zwei dieser Portexpander, einen für die Taster und einen für die LEDs. Richtig?


    und dann gibt es noch Portextender z.B. 8x I2C PCF8574(a) für je 8 Taster oder als out also 64 (8x8) Ports, der MCP kann mehr I2C, SPI bis zu 16 Ports muss man mal ausrechnen.


    Das klingt gut, denn das hätte auf alle Fälle den Vorteil, daß mir noch GPIO-Kontakte für später übrigbleiben, wenn ich noch mehr basteln will. Dann muss ich jetzt nur noch nach Anschlussbeispiele bzw Anleitungen für diesen Extender Ausschau halten. Falls Du einen Link hast: Danke! :)


    Was ich so ganz spontan nicht verstehe: wieso kann das Ding als Eingang nur 8 Taster, aber als Ausgang 64 Schalter? Ist das ein digitaler Ausgang, an dem ein Binärwert von 1 bis 64 angelegt wird, oder hat der wirklich 64 Anschlüsse, an denen ich direkt Relais oder LED anschließen kann?

    Du meinst also, es wäre besser, wenn die Pins immer "high" wären, und nur durch die Taster auf "low" gesetzt werden? Warum wäre das besser?


    Und noch eine Frage: es gibt laut Schaltplan 12 Pins mit der Bezeichnung "GPIO-0" bis "GPIO-11", die für solche Zwecke beliebig für das Auslesen von Tasters und/oder das Setzen von Schaltern benutzt werden können. Wenn ich für diese Zwecke mehr als 12 Anschlüsse benötige, gibt es dann noch einen anderen Weg als so einen "Expander" wie weiter oben beschrieben? Was ist mit den restlichen Pins, die nicht V+ oder GND sind, können davon welche verfügbar gemacht werden, wenn ich z.B. keine serielle Schnittstelle benötige?


    Ich brauch 15 Anschlüsse, die ich beliebig "betasten" und beschalten kann. Es fehlen mir also 3 Anschlüsse. Woher kann ich die bekommen?


    wo willst du genau Dioden hinsetzen?


    Ich dachte an Dioden zur Vermeidung der Verbindung der einzelnen GPIO-Pins. Wie auf dem Schaltplan ersichtlich, ist jeder Pin mit jedem anderen über 2xR verbunden. Aber das geht anscheinend, das ist in jedem Schaltplan, den ich im Netz gefunden habe und der mehr als 1 Taste beinhaltet, genau so.

    Moin!


    Ich habe auch eine Frage bzgl mehrerer Taster. Ich möchte gerne 4 Taster anschließen, und nach dem, was ich bisher gelesen habe, sollte man die GPIO-Anschlüsse mit Widerständen auf Masse ziehen, um einen definierten Pegel von Null zu erhalten. Also würde das nach meiner Logik auf die Schaltung unten hinauslaufen. Die Widerstände sollen 27kOhm betragen.


    Dabei sind aber die einzelnen GPIO-Anschlüsse jeweils über zwei Widerstände miteinander verbunden. Müssen da noch Dioden zwischen die einzelnen Anschlüsse?

    Hi!


    Ich bin gerade über diese Bastelanleitung gestolpert. Einen dritten USB-Anschluss könnte ich an meinem Pi auch gebrauchen. Ich habe den Pi zusammen mit einem aktiven USB-Hub in ein altes Router-Gehäuse eingebaut. Das Problem dabei ist, daß ein USB-Anschluss des Pi verloren geht, weil der mit den Hub verbunden ist. Außerdem sieht das echt doof aus, wenn ein Kabel von außen wieder im Gehäuse verschwindet.


    Wenn ich den Hub direkt an den USB-Kontroller anlöten könnte, würde mich das echt helfen. Reicht es bei einem aktiven Hub, wenn ich die beiden Datenleitungen verbinde, oder muss dabei auch die Spannungsversorgung angeschlossen werden?

    Mir ist schon bewusst, daß der Pi und seine Verwandten als Experimentierplattformen und nicht als "Dauerläufer" konzipiert sind. Es ist aber auch nicht von der Hand zu weisen, daß sich diese Minirechner mit ein paar Einschränkungen in Sachen Leistung durchaus als sehr preiswerte Server für Dienste wie eben OwnCloud zum Synchronisieren von Terminen und Kontakten eignen. Es gibt zwar NAS-Modelle, auf denen auch Dienste wie OwnCloud laufen können, aber ich glaube, in Sachen Energieverbrauch schneidet diese Geräteklasse um Zehnerpotenzen schlechter ab als ein Pi.


    Ich kann sehr gut damit leben, daß Thunderbird per CalDAV ein paar Sekunden braucht, um einen Termin zu verschieben, denn ich erkaufe mir diese Wartezeit mit der Gewissheit, daß *meine* Daten in *meiner* Hand bleiben und nicht auf Umwegen auf einem Server der NSA landen. Und ich bezweifle, daß es sehr viel schneller ginge, wenn ich für meine OwnCloud-Instanz im Internet einen Server anmieten würde. Aus dem Internet, also z.B. von meinem Androiden aus, wenn ich unterwegs bin, dauert es zwar mitunter bis zu 30 Sekunden, bis ein Kalender *komplett* synchronisiert ist, aber das geht automatisch, während das Telefon in der Tasche ist. Das stört mich also nicht. Das Hochschieben neu eingetragener Termine geht dagegen in weniger als 5 Sekunden.


    Alles in allem bin ich mit der Leistung, die ich für die paar Euro bekomme, sehr zufrieden. Ich weiß, daß ich für mehr Geld auch mehr Leistung bekäme, aber mal ehrlich: warum sollen 8 Prozessorkerne und 4 Gigabyte Speicher in irgend einem Rechenzentrum ein eigenes Kraftwerk auslasten, nur um mit der Verwaltung meiner Terminkalender gelangweilt zu werden? ;)


    Nichtsdestotrotz habe ich aber auch durchaus den Ehrgeiz, zu versuchen, das Optimum aus "diesen paar Euros" und dieser Experimentier-Plattform namens Raspberry herauszuholen. Das Problem bei einem Dauerbetrieb ist auch nicht der Pi selber, sondern die verwendeten Datenspeicher, die nicht für dauerhafte und permanente Schreibvorgänge ausgelegt sind. Der Pi könnte wohl Jahrhunderte laufen, ohne einem Fehler zu erliegen, wenn er einen ebenso dauerhaften Datenträger benutzen könnte.


    Es gab früher, als Compaq-Flash-Karten noch häufig im Gebrauch waren, eine Mikrofestplatte in Form einer solchen CF-Karte. Schade, daß es keine Festplatte in Form einer SD-Karte gibt.


    Der BananaPi hat zwar einen SATA Anschluss, allerdings ist das dort ähnlich wie beim Raspberry: Netzwerk sowie USB wird zum SoC über zwei USB 2.0 Lanes angebunden. Also müssen sich sowohl Netzwerk als auch USB die Bandbreite teilen. Es ist also auch bei weitem kein vollwertiger Gbit Port.


    Gut zu wissen!


    Die nächste Frage ist jetzt etwas vom eigentlichen Thema weg, daher reicht auch eine kurze Antwort und vielleicht ein Link: gibt es überhaupt Minirechner in dieser Preis-, Leistungs- und vor allem Energieverbrauchsklasse, die einen *echten* SATA-Anschluss haben?

    Danke für die ausführliche Antwort.



    ...Noch Fragen? :D


    Ja. :)


    Ich frage mal konkreter: profitiert OwnCloud auf einem Pi mehr davon, wenn (Achtung: Wortspiel!) "alles auf eine Karte gesetzt wird", also Betriebssystem und Daten auf einer SD-Karte liegen, oder wenn das System auf SD-Karte liegt, während OwnCloud seine Daten auf einem USB-Stecker lagert?


    Ich habe einige Versuche mit beiden Konstellationen durchgeführt, und mit bloßem Blick auf die Systemuhr habe ich bei Variante A (wie "alles auf eine Karte") einen leichten Geschwindigkeitsvorteil beim Aufbau der Kalender-Seiten gemessen, wenn ich die GUI benutze. Wobei ich das aber nicht wirklich nachvollziehen kann, denn die PHP-Skripte von OwnCloud lagern immer auf der Karte unter /var/www/owncloud, und solange MySQL nicht entsprechend konfiguriert wurde (siehe weiter unten), liegen auf die Kalender-Datenbanken unter /var/lib/mysql auf der Karte. OC lagert diese Datenbanken nur aus, wenn man SQLite benutzt.


    Das Hin- und Herschieben von Dateien in und aus der Wolke wird eh durch das Netzwerk begrenzt, ist also nicht wirklich relevant. Dieser Geschwindigkeitsvorteil hält sich aber in sehr engen Grenzen, und ich muss gestehen, daß ich weder eine richtige Stoppuhr noch eine statistisch wirklich einwandfreie Versuchsreihe durchgeführt habe. So habe ich z.B. zwischendurch meinen Rechner nicht neu gestartet, so daß auch noch Daten im Cache stecken konnten. Dennoch habe ich den Eindruck, daß bei Betrieb mit nur der SD-Karte die Benutzung von OwnCloud etwas schneller von der Hand ging.


    Lasse ich OwnCloud nur die herauf- und heruntergeladenen Dateien auf USB-Speicher lagern, ist im direkten Vergleich zu der Variante "nur Karte" noch kein großer Unterschied in der Zugriffsgeschwindigkeit zu spüren. Sobald ich aber auch die Datenbanken von MySQL, also die Kalender-Datenbanken von OwnCloud, auf den USB-Stick verlege, dauerte das Anlegen und Verschieben von Terminen in Thunderbird wirklich spürbar und messbar länger, und OwnCloud wirkt insgesamt "zähflüssiger" in der Benutzung.


    Es geht mir bei meiner Frage aber nicht nur um die reine Zugriffsgeschwindigkeit, sondern auch um die Datensicherheit aufgrund der Lebensdauer der Speichermedien: eine SQL-Datenbank dürfte z.B. einiges mehr an Schreiboperationen verursachen, als das Herauf- und Herunterladen von Dateien in und aus der Wolke. Ich versuche, abzuwägen, ob ein schnelleres "Abnutzen" einer SD-Karte als Preis für ein paar Bruchteile von Sekunden beim Schreiben und Lesen der Daten sinnvoll ist, oder ob ein USB-Speicher oder eine SSD-Platte sich bei dieser Art der Benutzung ebenso schnell abnutzen würde wie eine SD-Karte. Auch, wenn eine rotierende Datenplatte die sicherste aller hier genannten Optionen wäre, würde ich das wegen des erhöhten Energiebedarfs nur sehr ungern realisieren. Es mögen im Jahr vielleicht nur 5 Euro mehr sein, die eine Notebookplatte verursacht, aber wenn es sich vermeiden lässt, wäre das schön. Außerdem müsse die Platte eh über einen USB-Adapter betrieben werden, würde als keinen Geschwindigkeitsvorteil bringen. Es sei denn, ich weiche auf den Banana Pi aus, der einen SATA-Anschluss hat. (Der dann hoffentlich nicht nur eine interne USB-SATA-Adaption auf der Platine darstellt!)


    Wichtig ist auf alle Fälle, daß nicht irgendwann meine Kalender- und Termin-Datenbanken zerschossen sind, weil der Datenträger das Zeitliche segnet. Ich wird zwar täglich eine Sicherung durchgeführt, sogar übers Netz auf zwei verschiedene externe Datenträger, aber den Ärger, wenn mir unterwegs ein defekter Kalender auf meinem Androiden synchronisiert wird, möchte ich mir trotzdem ersparen. Und da ich mich mit Dingen wie der "Abnutzung" von Speichermedien nur sehr oberflächlich auskenne, frage ich lieber einmal zu viel als zu wenig nach. ;)

    Mal eine Frage an die Zahlenakrobaten, die sich mit so etwas auskennen:


    Welches Speichermedium hat an einem Pi theoretisch die höhere Schreib- und Lesegeschwindigkeit: die SD-Karte oder ein USB-Stick?


    Das sind ja beides irgendwie unterschiedliche Speichersysteme, und dann kommen noch unterschiedliche Controller hinzu. Kann man die überhaupt miteinander vergleichen?

    Ja, Du hast schon Recht, was die Sache mit der Datenmanipulation angeht. Aber nach den ersten beiden Absätzen in dem Thema, auf das Du verwiesen hast, ging es um Netzwerkprobleme. Und da das Netzwerk bei mir lief, und mein Pi außerdem eine feste IP hat und somit also auch kein DHCP-Server sich über das falsche Datum aufregen musste, schien mir das dortige Problem eine andere Ursache als meines zu haben.


    Aber was Rechner angeht, habe ich schon Pferde direkt vor der Apotheke kotzen sehen! :-D


    Nun, jetzt läuft's, und somit bleibt jetzt eigentlich nur noch, den Grund für den falschen Eintrag in der Datei herauszufinden. Den kann ich mir noch nicht erklären, denn, wie gesagt, habe ich die SD-Karte zurvor kopiert, und zwar mit "dd", also Bit für Bit, und dadurch stand auch in der Kopie nachher das in der Datei, was im Original stand. Bleibt eigentlich nur ein Fehler während der Aktualisierung. Die einfachste Erklärung wäre, daß im neuen Paket "fake-hwclock" eine fehlerhafte Datei steckt und "apt" nicht nachgefragt hat, ob er die alte Datei überschreiben soll.


    Ein erster Blick auch das System sagt mir:


    Code
    1. dpkg -S /etc/fake-hwclock.data
    2. dpkg-query: Kein Pfad gefunden, der auf Muster /etc/fake-hwclock.data passt


    Also wird die Datei /etc/fake-hwclock.data während der Installation des Paketes fake-hwclock erzeugt, sie ist nicht Teil des Paketes, und das bedeutet, in dem entsprechenden Installationsskript könnte sich durchaus ein Fehler verstecken.


    Da muss ich also noch mal tiefer einsteigen zur Ursachenforschung.


    Aber nicht heute, das Wetter ist zu schön, um das Motorrad in der Garage zu lassen. :)

    Code
    1. pi@raspberrypi ~ $ date && diff -s /etc/localtime /usr/share/zoneinfo/`cat /etc/timezone`
    2. Sa 10. Okt 22:09:25 CEST 2015
    3. Dateien /etc/localtime und /usr/share/zoneinfo/Europe/Berlin sind identisch.
    4. pi@raspberrypi ~ $


    Ich glaube, ich beginne den Mechanismus von fake-hwclock zu verstehen: beim Herunterfahren wird die Systemzeit in /etc/fake-hwclock.data gespeichert und beim Starten wird von dort die letzte bekannte Zeit geladen und dann die Uhr nachgestellt.


    In dieser Datei stand bis eben aber das Datum vom 14.10.2015. (Habe es jetzt manuell geändert). Warum und woher, ist mir allerdings ein Rätsel, denn zum einen habe ich, wie gesagt, vor dem Update auf Jessie die SD-Karte mit Wheezy kopiert, damit ich im Notfall einfach wieder ein fehlerfreie System starten kann. Also wurde auch die Datei /etc/fake-hwclock.data kopiert, und darin steht auf Wheezy ein Datum, das wesentlich näher an der Wahrheit ist. Nach ein paar Neustarts mit Jessie kann ich jetzt sehen, daß unter Jessie diese Datei nicht aktualisiert wird, es steht immer noch meine manuelle eingetragene Uhrzeit darin.


    Könnte das ein Fehler in Jessie sein? Und wenn ja: woher kam der Eintrag mit Datum vom 14.10., also 4 Tage in der Zukunft? Mein Pi benötigt jedenfalls keine 1.21 Gigawatt... ;)

    Ich habe folgendes Problem:


    Ich habe auf Jessie aktualisiert, und dabei alle Konfigurationen behalten, durch Anpassung der source-list von apt. Das hat auch geklappt, bis auf die Tatsache, daß nach jedem Start von Jessie das Datum des Pi über 4 Tage in der Zukunft liegt und ntpdate sich weigert, die Systemzeit zu stellen.


    Ich benutze unter Wheezy nicht den Dämon, sondern der Einfachhalber einen Cronjob, um die Uhr zu korrigieren:

    Code
    1. */73 * * * * nice /usr/sbin/ntpdate ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de >/dev/null 2>&1


    Das kann aber nicht schuld daran sein, daß unter Jessie das Datum so sehr falsch ist. Sicherheitshalber habe ich die SD-Karte mit Wheezy zuvor kopiert, und stecke ich die Karte mit Wheezy wieder ein und starte das alte System, stimmt auch das Datum wieder. Starte ich Jessie, liegt das Datum wieder in der Zukunft, und ntpdate weigert sich, die Uhrzeit zu stellen.


    Ich habe schon nach einem Fehler gesucht, aber keinen gefunden. Hat noch jemand einen Tip für mich?


    Ich würde (wie die meisten LED Verbauer in der Industrie) ein Stück Plexiglas über den LEDs positionieren, die bis zum Gehäusedeckel reichen und dort befestigt sind.


    Daran hatte ich auch schon gedacht. Muss mal sehen, ob ich meine alte Laubsäge noch wiederfinde. Das wäre dann die Alternative zum Weihnachtsbasteln. :D


    Warum sollte man solche Infos wie Linkstatus o. Duplexmode in Echzeicht brauchen?


    Für die Power-LED muss das nicht sein, das stimmt. Ich dachte da eher an die Netzwerk-LED: leuchtet die nicht im Takt der Daten, so daß man sehen kann, ob gerade Daten fließen oder nicht?


    Wenn das nicht so ist, würde ich natürlich die externen LED über die GPIO anschließen, das ist dann natürlich wesentlich einfacher zu verdrahten.

    Das könnte man machen, dann mußt Du dir aber ein Script schreiben das die nötigen Infos im System einsammelt und die LED's ansteuert.


    Was dann aber wohl nicht in Echtzeit geht, d.h. die Informationen der externen LED wären jeweils schon hoffnungslos veraltet, wenn sie die LED erreichen. ;)


    Quote

    Einfacher und sicherer wäre es, die einzelnen LED Stati per LWL Kabel, zum Gehäuse zu übertragen.


    Ja, eine Glasfaser wäre eine elegante Lösung, das stimmt. Aber wie bekomme ich das Ding an den LED befestigt? Und brauche ich für jede LED eine einzelne Glasfaser? Gibt es für den Pi schon irgend etwas Fertiges für diesen Zweck?