Als Autoren bekommen wir natürlich regelmäßig Post von unseren Lesern, oft in der Form: »Das Buch gefällt mir einigermaßen/ziemlich/sehr gut, aber ich hätte da mal ’ne Frage.« Und natürlich bemühen wir uns zu antworten, so gut wir können.

Gestern habe ich eine recht lange E-Mail erhalten, die nicht ganz in dieses Schema passte: Die Mail berichtet sehr ausführlich über Praxiserfahrungen und Detailprobleme mit dem Raspberry Pi, und mir erschienen die so zusammengetragenen Informationen so wertvoll, dass ich den Verfasser um die Erlaubnis fragte, die E-Mail zu veröffentlichen. Das OK habe ich nun (vielen Dank dafür!), und natürlich respektiere ich den Wunsch, dass Name und E-Mail-Adresse nicht genannt werden sollen.

Im Folgenden also der Text der Mail. Wenn Sie dazu Anmerkungen oder Vorschläge haben, verwenden Sie bitte die Kommentarfunktion.

---

Ihr neues Buch »Raspberry Pi, das umfassende Handbuch, 2.Auflage 2015« ist sehr interessant und gut aufgebaut, trotzdem möchte ich einige gesammelte Anmerkungen, Infos und Fragen loswerden:

1.) Versorgung und USB, aktiver USB-Hub

Ihre Darstellung im Buch kann noch konkretisiert werden: Beim Raspberry 1 (ich habe aktuell einen Raspberry 1 B aus Ende 2012 in 24/7-Betrieb) sind die +5V an den USB-Buchsen nicht über Stromsense-Elemente geführt, sondern direkt mit dem 5V-Netz hinter der 700mA-Polyfuse verbunden.

Dies hat zur bekannten Folge, dass beim Einstecken eines USB-Gerätes durch das nicht strombegrenzte Umladen des unterdimensionierten Stützkondensators auf der Raspi-Platine in den leeren Stützkondensator des USB-Gerätes, ein Spannungseinbruch erfogt, welcher einen Reset des SOCs auslösen kann.

Wenn man das USB-Gerät vor der Versorgungsinbetriebnahme schon angesteckt hat, funktioniert das erste Hochfahren. Sollte später im Betrieb das USB-Gerät mehr als die ca. 100mA ziehen, dann spricht die unterdimensionierte Polyfuse an und reduziert die Spannung durch den erhöhten Widerstand, was wiederum zum Reset des SOCs führt.

Diese extrem störende „Funktionalität“ wurde ab dem Raspi 2 verbessert, indem die USB-Buchsen ihre Spannung über strombegrenzende Elemente bekommen und die Polyfuse geändert wurde.

Trotzdem kann man mit den Unzulänglichkeiten beim Raspi 1 mit folgender Methode gut leben: Verwendet man einen China-Noname-Billighub mit 5V-Anschluss z.B. via Hohlbuchse, dann ist meistens die 5V-Versorgungsleitung vom externen Netzteil auf alle 4 USB-Buchsen des Hubs und ebenfalls zum USB-Stecker des Hubs 1:1 ohne weitere Sicherungen/Shunts o.ä. verdrahtet. Das bedeutet, dass man über den USB-Hub (am besten mit einem guten 5,2V/2A Netzteil versorgt) auch den Raspberry 1 inkl. aller seiner restlichen Peripherie via Rückspeisung mitversorgen kann; allerdings hat der Raspi jetzt keine Sicherung mehr in seiner 5V-Versorgung, diese könnte man sich nachträglich im USB-Hub in Serie zum Stecker nachrüsten. Diese Methode spart das sonst nötige 2. Netzteil ein! Am Raspi 2 funktioniert dies nicht.

1b) Leistungsaufnahme

Der Raspi 1 besitzt LDO-Linearregler zur Spannungsversorgung 3,3V und 2,5V, der Raspi 2 hat hier Schaltregler. Bei meinem Raspi 1 kann ich keine besonderen EMV-Maßnahmen erkennen und ein schlecht gelayouteter Schaltregler kann einem die Masseleitung versauen und es könnten sich Abstrahlungen durch angeschlossene Kabel ergeben; dies hatte ich z.B. bei einem LAN-Switch durch ein schlechtes Netzteil. So gesehen sind mir die LDOs trotz 0,5W Mehraufnahme lieber.

2.) Kernel-Kompilierung

Da hatte ich schon vor dem Lesen diverse Foren recherchiert und eine Vorgangsweise nachvollzogen. Nach etlichen Iterationsschritten mit Cross-Compiling auf einem Ubuntu-PC und Tips eines Grazer Linux-Tag Experten, ist es mir tatsächlich gelungen ein leider am Raspi fehlendes Kernelmodul (i2c-tiny-usb.ko) zu kompilieren bzw. zu erstellen. Leider nimmt der Kernel dieses Kompilat per modprobe nicht an, eventuell falsche Source oder was auch immer.

pi@raspberrypi /lib/modules/3.12.22+ $ sudo modprobe i2c-tiny-usb
ERROR: could not insert 'i2c_tiny_usb': Exec format error

3.) Programmierung

Leider geht hier alles auf Python; ich kann mich damit leider gar nicht anfreunden, ich verwende lieber Perl, da C-ähnlich und ebenfalls leicht zu programmieren wenn man nur Konsolenprogramme ohne Grafik benötigt. Perl-Programme sind zwar beim Starten grottenlangsam, aber für mich wesentlich besser lesbar. Via CPAN gibt es Module für ziemlich alles.

Programmierung in C hat mich bisher eher abgeschreckt, hier vermisse ich einen guten Einstieg ähnlich dem Python-Kapitel. C hätte ja gegenüber Perl den Riesenvorteil der Ausführungsgeschwindigkeit. Auf µCs ohne RTOS ist C relativ simpel zu verwenden, am Raspi tue ich mir da schwer.

4.) USB-Sticks, Samba, etc.

24h-Betrieb ist mühsam, ich habe z.B. ein Temperaturlogging laufen, welches alle 10min Temperaturwerte in ein Logfile am USB-Stick schreibt, bzw. als Zeile einem Textfile anhängt. Visualisierung geht dann unabhängig über ein tail und Parsen des Outputs in PHP und Darstellung als Canvas in einer Webseite. Obwohl kein File dauerhaft offen ist und ich alle 24h per Cronjob die Buffer leeren lasse, hält das System nur ca. 30..50 Tage bis zum nächsten FAT-Fehler am Stick durch. Die SD-Karte ist davon nicht betroffen, obwohl hier mehrere Perl-Programme mit logging im Hintergrund via Screen laufen, ein Webserver+PHP läuft und etliches andere auch.

Ein Raspi in einem geschlossenen Gehäuse hat eine ca. 10K höhere SOC-Temperatur als ein Raspi ohne Gehäuse, dies hieße halbe Lebensdauer. Ich hatte im Sommer ca. 55°C trotz kleiner Kühlkörper auf den ICs und etlicher 5mm Luftlöcher im Gehäuse; jetzt betreibe ich einen kleinen 50x50mm 12V Lüfter an 5V -0,7V über den Luftlöchern außen am Gehäuse und habe jetzt ca. 41°C, dies hat aber keinen Unterschied in der Stabilität ergeben.

5.) Anregung für Kommunikationsprojekte

• Raspi 2 mit Linuxtreibern für DVB-T2 und DVB-S2 USB-Hardware zum Betrieb mit tvheadend als Sat>IP Server im Netzwerk oder mit optionalem Kodi als Mediaplayer.

• RTL-SDR Server mit multiplen Geräten. Der Raspi 1 läuft nur mit hoher Auslastung (top) als RTL-TCP Server, hier muß man geringe Bandbreite verwenden und es läuft trotzdem nicht dauerstabil. Als ACARS-Decoder läuft der Raspi 1 mit ca. 25% CPU Auslastung bei 3 Kanälen, allerdings nur ca. 2..7 Tage bis es zu einem FAT-Fehler am USB-Stick kommt (wenn man alle Daten loggt).

• i2c-tiny-usb.ko: wie schon unter 2) beschrieben: Der Raspi 1 hat einen Fehler in der internen I2C-Hardware, es wird die I2C-Clocksynchronisation (SCL Pulse stretching) der Slaves nicht unterstützt; man kann keine SMBUS-Smart-batteries (Notebook Akkupacks) damit sicher auslesen. i2c-tiny-usb unterstützt diese Methode in seiner Firmware für den Tiny45, in jedem PC-Kernel ist das Modul bereits enthalten, ausgerechnet beim Raspian haben sie es entfernt. Ich habe es nicht geschafft ein kompatibles Kompilat für den 3.12.22+ anzufertigen.

• Devicetree-Migration: Ich traue mich aktuell nicht, ein dist-upgrade zu machen, da ich alle HW noch unter <3.18 eingerichtet habe – dies ist i2c, spi, ds1307, gpios, uart, watchdog – und ich keinen Totalstillstand riskieren will.

6.) realistische Betrachtungsweise

Der Raspi ist als PC-Ersatz zum „Arbeiten“ völlig ungeeignet und viel zu teuer: Raspi + Gehäuse + Netzteil + SD-Karte + Maus + Tastatur + Monitor kosten wesentlich mehr als ein (gebrauchtes) Notebook, von der Qualität des Aufbaues und der Leistungsfähigkeit und Betriebstauglichkeit gar nicht zu reden.

Der Raspi hat meiner bescheidenen Meinung nach nur 2 Stärken im Preis/Leistungsverhältnis:

• (i) Headlessbetrieb via putty/RDP/VNC und als (Web)Server, der Webserver kann ja als „Kommandoempfänger“ genutzt werden

• (ii) Mediacenter am vorhandenen TV; TV-Linuxboxen sind ja auch nichts anderes.

Für die industrielle Anwendung ist der Raspi ebenfalls ungeeignet, hier wird er wohl keine Konkurrenz zum Beaglebone etc.

Falls Sie bis hierher durchgehalten haben bedanke ich mich für Ihre Zeit und Interesse an den Inputs eines nicht Linuxexperten als Anwender. Ich sehe den Raspi nicht aus der Sicht eines Linux-Sysadmins, sondern aus der Sicht eines Entwicklers, welcher eine auf hohem Level programmierbare Hardware mit Netzwerkfunktionalität vor sich hat.