mikrocontroller.net

Forum: PC Hard- und Software Linux-Tablet mit RasPi bauen - Display-Quelle


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: DC (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,


ich möchte gerne zum Raspberry-Pi-Einstieg eine Art Tablet für 
Akkubetrieb bauen.


Kurz gesagt soll das OS Linux sein und darauf laufen sollen unter 
anderem folgende Programme/Utilities:
-IPython
-Modzilla Firefox
-Video-Audio-Player (Media-Center)
-PDF-/E-Book-Reader

Bin bei der Hardware allerdings noch nicht sicher, was zum Einsatz 
kommen soll.
Ein RasPi 3 Mod. B sollte es wohl mindestens sein.


Die Hauptfrage ist aktuell, was für Displays in Frage kommen.

Am besten etwas passendes zwischen 7" und 14" mit halbwegs hoher 
Auflösung und Farbtiefe. Eventuell mit Touchscreen (bin da noch nicht 
ganz sicher).

Die erste Frage von meiner Seite wäre also, wo man in Frage kommende 
Displays halbwegs günstig finden kann (gebraucht?).


Wenn ansonsten jemand Anregungen zu dem Projekt hat, gerne posten!

Autor: KK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pollin.de hat u.a. 7" und 10" Displays mit und ohne Touch

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Vollständigkeit halber: Ein 10er Tablet mit Akku für den RasPi gibts 
fertig zu kaufen, von SunFounder. Kostet allerdings etwas und die 
Akku-Lebensdauer kann mit den üblichen Tablets nicht mithalten.

Autor: Frank K. (fchk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Einen PI willst Du nicht verwenden.

Die üblichen Displays in dieser Größenordnung haben entweder LVDS oder 
Embedded DisplayPort. Der Pi hat nichts davon. Du brauchst eine extra 
Platine für HDMI.
Kleine Displays gibts auch noch mit Parallel RGB. Das kann der Pi zwar 
prinzipiell, aber Du verlierst dadurch fast zwei Drittel der GPIOs.

Such Dir besser ein anderes ARM-Board aus. Gibt ja genug davon.

ansonsten schau mal her:

https://www.buydisplay.com/default/10-inch-raspberry-pi-touch-screen-with-small-hdmi-driver-board-1024x600

fchk

Autor: KK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Die üblichen Displays in dieser Größenordnung haben entweder LVDS oder
> Embedded DisplayPort. Der Pi hat nichts davon. Du brauchst eine extra
> Platine für HDMI.

Die Pollin-Displays haben HDMI, laufen hier super

Autor: DC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und Danke für die Antworten!

Die Idee mit Pollin ist gut!


A. K. schrieb:
> Ein 10er Tablet mit Akku für den RasPi gibts
> fertig zu kaufen, von SunFounder. Kostet allerdings etwas und die
> Akku-Lebensdauer kann mit den üblichen Tablets nicht mithalten.

Warum, sind dort zu kleine Akkus verbaut oder verbraucht das Gerät zu 
viel?


Frank K. schrieb:
> Die üblichen Displays in dieser Größenordnung haben entweder LVDS oder
> Embedded DisplayPort. Der Pi hat nichts davon. Du brauchst eine extra
> Platine für HDMI.
> Kleine Displays gibts auch noch mit Parallel RGB. Das kann der Pi zwar
> prinzipiell, aber Du verlierst dadurch fast zwei Drittel der GPIOs.

Die genannte Problematik habe ich schon bei Youtube gesehen. 
Grundsätzlich werden für das Projekt nicht so viele IO-Pins benötigt. 
Deshalb könnte man den Verlust von 2/3 der GPIOs wahrscheinlich 
verschmerzen.
Wäre so ein Display denn günstiger und stromsparender als ein Display 
mit HDMI-Platine (wenn es das überhaupt in Größen ab 7" gibt)? Und muss 
der ARM dann viele Resourcen extra für das Nicht-HDMI-Display 
bereitstellen?


Frank K. schrieb:
> Such Dir besser ein anderes ARM-Board aus. Gibt ja genug davon.

Eigentlich wollte ich mal was speziell mit RasPi machen, aber 
interessehalber gefragt, gibt es ein Board, das man für so ein Projekt 
besonders empfehlen kann? Und wäre das dann auch so gut supported wie 
der RasPi?


KK schrieb:
> Die Pollin-Displays haben HDMI, laufen hier super

Danke für die Info! Die benötigen alle so ca. 2A bei 5V, habe ich 
gesehen. Betreibst du die zufällig mit LiIon-Akkus?

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DC schrieb:

> Frank K. schrieb:
>> Die üblichen Displays in dieser Größenordnung haben entweder LVDS oder
>> Embedded DisplayPort. Der Pi hat nichts davon. Du brauchst eine extra
>> Platine für HDMI.
>> Kleine Displays gibts auch noch mit Parallel RGB. Das kann der Pi zwar
>> prinzipiell, aber Du verlierst dadurch fast zwei Drittel der GPIOs.
>
> Die genannte Problematik habe ich schon bei Youtube gesehen.
> Grundsätzlich werden für das Projekt nicht so viele IO-Pins benötigt.
> Deshalb könnte man den Verlust von 2/3 der GPIOs wahrscheinlich
> verschmerzen.
> Wäre so ein Display denn günstiger und stromsparender als ein Display
> mit HDMI-Platine (wenn es das überhaupt in Größen ab 7" gibt)? Und muss
> der ARM dann viele Resourcen extra für das Nicht-HDMI-Display
> bereitstellen?

Bei Parallel RGB ist spätenstens bei 1024*768 Schluss. Je höher der 
Pixeltakt, desto empfindlicher wird die Übertragung. Ich würde 
eigentlich schon ab 800*480 LVDS bevorzugen. Das ist wesentlich 
unempfindlicher und braucht weniger Leitungen, und das Kabel darf länger 
als ein paar cm sein.

Die HDMI-Konverter-Platine braucht Strom. Wieviel, das hängt vom 
Pixeltakt und damit von der Auflösung ab. Und wenn Du weißt, dass der 
Konverterchip bei 1024*600 Pixeln schon einen kleinen Kühlkörper 
braucht, dann weißt Du auch, dass da Strom in Wärme verbraten wird. Also 
genau das, was Du bei Akkubetrieb absolut nicht haben willst.

Der PI hat noch eine weitere Display-Schnittstelle, nämlich MIPI DSI. 
Die geht aber nur mit dem originalen Display von der Pi Foundation.

Der Pi hat eine beträchtliche Popularität, aber dennoch etliche 
ernsthafte Nachteile. Die unvollständige Hardwaredokumentation, die 
binären Blobs und die mangelnde Schnittstellenausstattung (der Prozessor 
ist für einfache Tablets und digitale Bilderrahmen entwickelt worden) 
sind nur einige davon.

Der größte Stromverbraucher ist jedoch immer noch die 
Hintergrundbeleuchtung des Displays. Ein halbes A bei 3.3V bei einem 7" 
Display ist so ungewöhnlich nicht. Mit steigenden Displaydiagonalen 
wirds natürlich entsprechend mehr.
Wenn Du wirklich stromsparend sein willst, nimm eInk/ePaper.

Der ARM-Kern selber hat mit dem Display eigentlich eher wenig zu tun, 
dafür gibts den Displaycontroller, ggf mit GPU und 2D/3D-Beschleunigung.

> Frank K. schrieb:
>> Such Dir besser ein anderes ARM-Board aus. Gibt ja genug davon.
>
> Eigentlich wollte ich mal was speziell mit RasPi machen, aber
> interessehalber gefragt, gibt es ein Board, das man für so ein Projekt
> besonders empfehlen kann? Und wäre das dann auch so gut supported wie
> der RasPi?

Keine Plattform ist so verbreitet wie der Pi. Aber seien wir mal 
ehrlich: Was brauchst Du? Ein Linux-System mit allein Treibern für die 
zugehörige Hardware. Ich gehe erstmal nicht davon aus, dass Du selber 
Hardwareentwicklung oder eine Linux-Portierung machen wirst - dafür 
stellst Du zu "einfache" Fragen. Bei jedem Board, das Du kaufst, gibts 
eine vorgefertigte Linux-Installation dafür, und dann benutzt Du nur die 
Linux-Treiber für SPI, I2C, für Grafik entweder Framebuffer oder 
OpenGL-ES, für Sound ALSA, für die GPIOs die Standard-Linux-APIs. Das 
wars.

Board-Empfehlungen?
Hmm. Firefox ist natürlich schon reichlich fett, da willst Du Leistung 
haben. Media-Center wollen natürlich auch Rechenleistung haben, oder 
zumindestens Hardware-Decoder und ggf Encoder. Da wäre schon sowas wie 
ein NVidia TK1 oder Jetson Nano angebracht, wenn es Spaß machen soll. 
Ist zwar auch nicht so besonders stromsparend (das TK1 geht noch, das 
Nano zieht aber bis zu 10W), aber irgend einen Tod wirst Du sterben 
müssen.

Wenn Du was sparsames haben willst, hol Dir halt irgendein billiges 
China-Android-Tablet. Was besseres mit einigermaßen langer Akkulaufzeit 
und guter Portabilität wirst Du selber definitiv nicht hinbekommen. Wenn 
Du hingegen basteln willst, wirst Du mit den NVidia-Boards Freude haben. 
Da darfst Du dann auch die 192 CUDA-Kerne (beim TK1, der Jetson Nano ist 
ein TX1 und hat deutlich mehr davon) rechnen lassen.

fchk

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DC schrieb:
> Warum, sind dort zu kleine Akkus verbaut

6000 mAh LiIon liegen im üblichen Rahmen.

> oder verbraucht das Gerät zu viel?

Ebendies. Die Tablets auf dem Markt sind dafür gebaut worden, die meiste 
Zeit so wenig wie irgend möglich Strom zu verbrauchen. In Hard- wie in 
Software. Der RasPi ist das nicht.

: Bearbeitet durch User
Autor: DC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Frank für die ausführliche Antwort mit den vielen Erklärungen und 
Vorschlägen!

Das Ganze ist ein Gemeinschaftsprojekt mit jemandem, der sich mit Linux 
auskennt, aber keine Ahnung von Elektronik hat.
Wir haben uns jetzt entschlossen, einen Raspi B+ zu organisieren und 
erst mal mit einem normalen HDMI-Monitor am Stromnetz zu arbeiten.
Dann wird sich zeigen, ob eine Verkleinerung auf ein portables Gerät 
sinnvoll ist.

Gibt es denn einen Browser, der für einen Raspi unter Linux gut geeignet 
ist?


Frank K. schrieb:
> Der ARM-Kern selber hat mit dem Display eigentlich eher wenig zu tun,
> dafür gibts den Displaycontroller, ggf mit GPU und 2D/3D-Beschleunigung.

Meinst du das so, dass man eine Art externe GPU installieren 
kann/soll???
(oder ist das auf den eingebauten VideoCore bezogen?)


Frank K. schrieb:
> Wenn Du wirklich stromsparend sein willst, nimm eInk/ePaper.

Das könnte man glatt überlegen, wobei das für Videos eher nichts sein 
dürfte, aber andere Vorteile hätte.

Jetson Nano ist notiert, wobei das eine andere Preisklasse ist, aber 
interessantes Teil!

Autor: DC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DC schrieb:
> Wir haben uns jetzt entschlossen, einen Raspi B+ zu organisieren

Also Version 3 Mod. B+

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DC schrieb:
> Gibt es denn einen Browser, der für einen Raspi unter Linux gut geeignet
> ist?

Chromium.

> Meinst du das so, dass man eine Art externe GPU installieren
> kann/soll???

Die Videocore-GPU ist gemeint. Die macht die Hauptarbeit fürs Display.

: Bearbeitet durch User
Autor: DC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Infos zum Browser und Video-Core! Chromium ist notiert, 
Danke!

Wir werden jetzt definitiv den Raspi 3B+ verwenden.
D.h., grade steht die Frage im Raum, welche Speicherkarte man 
verwenden kann (auch im Hinblick auf die Schreibgeschwindigkeit).
In dem Buch "Durchstarten mit Raspberry Pi" steht, dass nicht jede 
Speicherkarte funktioniert und dass es im Netz eine Liste gibt mit 
getesteten Karten (also schon auf Raspi-Systemen getestet).
Weiß jemand, wo man die finden kann (ich habe sie jedenfalls nicht bei 
google gefunden, dafür jede Menge Werbung).

Autor: DC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach einigem Rumgegurke habe ich immerhin schon mal diese Liste hier 
gefunden:

https://elinux.org/RPi_SD_cards

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DC schrieb:

> Wir werden jetzt definitiv den Raspi 3B+ verwenden.
> D.h., grade steht die Frage im Raum, welche Speicherkarte man
> verwenden kann (auch im Hinblick auf die Schreibgeschwindigkeit).

Das ist Glückssache. SD-Karten sind dafür nicht gedacht, weil sie 
üblicherweise kein gutes Wear-Levelling haben. Außerdem wird sehr oft 
Ausschussware an Flash-Chips verbaut, bei denen teilweise nur noch 30% 
der Blöcke funktionieren.

Ist auch noch ein Punkt, warum ich für ernsthafte Aufgaben keinen PI 
empfehle.

Für ernsthafte Aufgaben nimmt man EMMC. Das sind auflötbare Module, die 
das gleiche Protokoll wie SD-Karten (genauer: MMC-Karten) verwenden, 
minus dem Kopierschutz-Gedöns (das S in SD), aber mit 8 Datenleitungen 
statt 4 und doppelter Taktrate plus noch ein paar anderen Kleinigkeiten. 
Außerdem ist der Speicherchip dadrin von hoher Qualität.

Die Pi Compute-Modules gibt es mit EMMC, und auch viele andere 
Plattformen wie BeagleBone arbeiten damit.

fchk

: Bearbeitet durch User
Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
>
> Für ernsthafte Aufgaben nimmt man EMMC. Das sind auflötbare Module, die
> das gleiche Protokoll wie SD-Karten (genauer: MMC-Karten) verwenden,
> minus dem Kopierschutz-Gedöns (das S in SD), aber mit 8 Datenleitungen
> statt 4 und doppelter Taktrate plus noch ein paar anderen Kleinigkeiten.
> Außerdem ist der Speicherchip dadrin von hoher Qualität.

eMMC läuft problemlos mit 4 Datenleitungen. Ziemlich viele SoCs haben 
nur so viel.

Autor: DC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Ausführungen!

SoC = System-on-a-Chip (nehme ich an)
https://de.wikipedia.org/wiki/SOC


Frank K. schrieb:
> Die Pi Compute-Modules gibt es mit EMMC, und auch viele andere
> Plattformen wie BeagleBone arbeiten damit.

Was meinst du in dem Zusammenhang mit 'Pi Compute-Modules'?


Kann man so einen EMMC auch als Speicher an das B3+-Board anschließen?
(wenn ja wird es wahrscheinlich so etwas wie das hier sein:)
Ebay-Artikel Nr. 132987106298

Wenn ich das richtig verstehe, wird der EMMC-Chip häufig direkt auf das 
PCB gelötet.
https://de.wikipedia.org/wiki/Multimedia_Card#eMMC


Sehe grade, die gibt es auch bei Mouser.
https://www.mouser.de/ProductDetail/ISSI/IS21ES16G-JCLI?qs=sGAEpiMZZMve4%2FbfQkoj%252BCMezv1v4I4kzQ49NTV34rA%3D

Dort finde ich aber nur handverlötungs-unfreundliche BGA-Ball-Modelle.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DC schrieb:
> Frank K. schrieb:
>> Die Pi Compute-Modules gibt es mit EMMC, und auch viele andere
>> Plattformen wie BeagleBone arbeiten damit.
>
> Was meinst du in dem Zusammenhang mit 'Pi Compute-Modules'?

Das hier:
https://www.raspberrypi.org/products/compute-module-3-plus-32gb/

Gibts als 'lite' ohne EMMC, dafür mit µSD Slot oder mit EMMC in 
verschiedenen Größen.

> Kann man so einen EMMC auch als Speicher an das B3+-Board anschließen?
> (wenn ja wird es wahrscheinlich so etwas wie das hier sein:)
> 
Ebay-Artikel Nr. 132987106298

ja. Das Protokoll ist kompatibel, und EMMCs laufen mit einer Busbreite 
von 1, 4 und 8 Bit. Und die von Dir gefundenen Teile kannst Du nehmen.

> Wenn ich das richtig verstehe, wird der EMMC-Chip häufig direkt auf das
> PCB gelötet.

"häufig" ist untertrieben. "immer" ist richtig.

> Sehe grade, die gibt es auch bei Mouser.
> 
https://www.mouser.de/ProductDetail/ISSI/IS21ES16G-JCLI?qs=sGAEpiMZZMve4%2FbfQkoj%252BCMezv1v4I4kzQ49NTV34rA%3D
>
> Dort finde ich aber nur handverlötungs-unfreundliche BGA-Ball-Modelle.

Genau. Es gibt sie auch nur in dieser Bauform.

fchk

Autor: Andreas M. (amesser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt SD-Karten die mit hoher Lebensdauer beworben werden. Diese 
sollten besser für den Anwendungsfall geeignet sein. z.B.:

https://www.reichelt.de/microsdhc-speicherkarte-32gb-samsung-pro-endurance-sams-mb-mj32ga-p229370.html?&trstct=pol_6

Man kommt aber auch mit den (guten) normalen SD Karten weiter wenn man 
bestimmte Dinge beachtet:

Möglichst nur eine Partition verwenden. Diese sollte so groß wie möglich 
sein. Dadurch kann das Dateisystem die Schreibzugriffe besser auf die 
gesamte SD verteilen.

F2FS verwenden. Dieses wurde von Samsung speziell für SD/MMC Speicher 
entwickelt.

In den meisten Fällen kann man ein tmpfs über /tmp und /var/tmp mounten. 
(Letzteres nicht ganz konform aber normalerweise problemlos) Dadurch 
vermeidet man schon eine Menge Schreibzugriffe.

Syslog/systemd so konfigurieren das nicht unnötig Log-Dateien 
angelegt/geschrieben werden. Prüfen ob alle Programme so konfiguriert 
sind, dass nur notwendiges geloggt wird und nicht haufenweise 
Debug-Ausgaben mit auf der Platte landen.

Autor: DC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Module kanne ich noch gar nicht, Danke für die Info!


Frank K. schrieb:
>> Wenn ich das richtig verstehe, wird der EMMC-Chip häufig direkt auf das
>> PCB gelötet.
>
> "häufig" ist untertrieben. "immer" ist richtig.

Da kann man mit der Lupe und Cu-Lack-Draht definitiv was machen 
löttechnisch, ist aber frickel. Zum Glück müssen nicht alle Punkte 
angeschlossen werden.



@Andreas:
Danke für den Tip mit der 'SAMS MB-MJ32GA MicroSDHC-Speicherkarte 32GB - 
Samsung - PRO Endurance'!


Andreas M. schrieb:
> Möglichst nur eine Partition verwenden. Diese sollte so groß wie möglich
> sein. Dadurch kann das Dateisystem die Schreibzugriffe besser auf die
> gesamte SD verteilen.

Also in einer einzigen Partition den kompletten Speicher zu 100,000% 
nutzen (und kein einziges MB frei lassen)?


> F2FS verwenden. Dieses wurde von Samsung speziell für SD/MMC Speicher
> entwickelt.

Interessant, hier findet man mehr dazu:
https://de.wikipedia.org/wiki/F2FS
https://en.wikipedia.org/wiki/F2FS


Andreas M. schrieb:
> In den meisten Fällen kann man ein tmpfs über /tmp und /var/tmp mounten.
> (Letzteres nicht ganz konform aber normalerweise problemlos) Dadurch
> vermeidet man schon eine Menge Schreibzugriffe.
>
> Syslog/systemd so konfigurieren das nicht unnötig Log-Dateien
> angelegt/geschrieben werden. Prüfen ob alle Programme so konfiguriert
> sind, dass nur notwendiges geloggt wird und nicht haufenweise
> Debug-Ausgaben mit auf der Platte landen.

Das sagt mir leider nicht so viel. Sind das Linux- oder 
Raspi-spezifische Sachen?
(Eventuell kann mein linuxerfahrener Mitbastler mehr damit anfangen, 
wird sich am WE zeigen, wenn der Raspi dann da ist, DHL hat irgendwie 
grade einen logistischen Hänger)

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DC schrieb:
> Diese Module kanne ich noch gar nicht, Danke für die Info!
>
>
> Frank K. schrieb:
>>> Wenn ich das richtig verstehe, wird der EMMC-Chip häufig direkt auf das
>>> PCB gelötet.
>>
>> "häufig" ist untertrieben. "immer" ist richtig.
>
> Da kann man mit der Lupe und Cu-Lack-Draht definitiv was machen
> löttechnisch, ist aber frickel. Zum Glück müssen nicht alle Punkte
> angeschlossen werden.

DDR400 ist kein Pappenstiel.

Autor: Andreas M. (amesser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Andreas M. schrieb:
>> Möglichst nur eine Partition verwenden. Diese sollte so groß wie möglich
>> sein. Dadurch kann das Dateisystem die Schreibzugriffe besser auf die
>> gesamte SD verteilen.
>
> Also in einer einzigen Partition den kompletten Speicher zu 100,000%
> nutzen (und kein einziges MB frei lassen)?

Nein, du kannst schon Speicher frei lassen. Der Hintergrund ist ein 
anderer:

Unter Linux ist es üblich, das man mehrere Partitionen anlegt und so 
eine trennung zwischen Programmen und Daten bekommt. Z.b. legt man 
normalerweise eine kleinere Partition for das "root" nehmen und eine 
größere für die Nutzerdaten unter "/home". Dadurch kann man z.B. 
problemlos das gesamte System neu installieren (inklusive formattieren 
der "root" partition) ohne die Nutzerdaten zu verlieren.

Für SD-Karten ist das nicht unbedingt gut. Denn Schreibvorgänge auf dem 
"root" würden dann nur innhalb des Addressbereiches der "root" partition 
passieren, entsprechendes gilt für Schreibvorgänge innerhalb des "home".
Um die Lebensdauer zu erhöhen, muss eine SD-Karte die Schreibzugriffe 
intern jedoch auf den gesamten Flash verteilen. Das funktioniert dann 
nicht mehr so gut, wenn man die SD-Karte in mehrere Bereiche aufteilt.

Wenn man jedoch nur eine große Parition, die die gesamte SD-Karte nutzt 
verwendet, und am besten noch mit einem für Flash geeignetem 
Dateisystem, z.B. BTRFS oder F2FS  formatiert, dann ist es einfacher für 
die SD-Karte die Schreibvorgänge über den gesamten Flash Speicher zu 
verteilen und so die Flash-Zellen gleichmäßig auszulasten.

Es gibt inzwischen diverse Mechanismen zwischen Betriebssystem und Flash 
basierten Speichern um die Lebensdauer zu erhöhen. Man kann oder konnte 
sich z.B. auch bei einer SSD ins Knie schießen:

- Man legt auf einer SSD zunächst eine Partition/Laufwerk mit voller 
Größe an und schreibt diese sehr voll. (Bei manchen SSDs ist dieser 
Schritt nicht notwendig)
- Dann löscht man die Partition wieder und legt eine viel kleinere an.
- Nun wird auschließlich dieser kleine Bereich genutzt.

Das führt dazu, das die SSD für Schreibzugriffe nur den kleinen Teil des 
Flashspeichers nutzen kann, der der kleinen Partition zugeordnet ist. Da 
in dem restlichen, ungenutzen Bereich ja auch schon mal Daten 
geschrieben worden sind und die SSD nicht mitbekommt das diese Daten 
nicht mehr gebraucht werden kann sie diesen großen ungenutzen 
Flash-Bereich auch nicht für Schreibzugriffe nutzen -> die SSD geht 
schneller kaputt.

> Andreas M. schrieb:
>> In den meisten Fällen kann man ein tmpfs über /tmp und /var/tmp mounten.
>> (Letzteres nicht ganz konform aber normalerweise problemlos) Dadurch
>> vermeidet man schon eine Menge Schreibzugriffe.
>>
>> Syslog/systemd so konfigurieren das nicht unnötig Log-Dateien
>> angelegt/geschrieben werden. Prüfen ob alle Programme so konfiguriert
>> sind, dass nur notwendiges geloggt wird und nicht haufenweise
>> Debug-Ausgaben mit auf der Platte landen.
>
> Das sagt mir leider nicht so viel. Sind das Linux- oder
> Raspi-spezifische Sachen?

Das ist vorallendingen Linux. DDein Mitbastler weis sicher was ich damit 
meine.

Autor: M.M.M (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Andreas M. schrieb:
> Unter Linux ist es üblich, das man mehrere Partitionen anlegt und so
> eine trennung zwischen Programmen und Daten bekommt. Z.b. legt man
> normalerweise eine kleinere Partition for das "root" nehmen und eine
> größere für die Nutzerdaten unter "/home". Dadurch kann man z.B.

Unter alles unter /bin /sbin usw. sind was?

> Für SD-Karten ist das nicht unbedingt gut. Denn Schreibvorgänge auf dem
> "root" würden dann nur innhalb des Addressbereiches der "root" partition
> passieren, entsprechendes gilt für Schreibvorgänge innerhalb des "home".

Das ist Unsinn. Eine SD-Karte hat überhaupt keine Idee, was eine 
Partition ist. Die kennt primär mal nur Blöcke und ab SDXC sogar ein FS, 
nämlich exFAT.

> Um die Lebensdauer zu erhöhen, muss eine SD-Karte die Schreibzugriffe
> intern jedoch auf den gesamten Flash verteilen. Das funktioniert dann

Tut sie auch. Blöcke sind Hardware, Partitionen logisches Level.

> nicht mehr so gut, wenn man die SD-Karte in mehrere Bereiche aufteilt.

Das ist Festplattendenke mit rotierendem Blech, wo Partitionen mit 
Sektoren verknüpft wurden. Bei Flashspeicher sind die Sektoren, mit 
denen die Partitionen verbunden sind aber auch nur logisches Level und 
werden selbst erst auf Hardwareblöcke gemappt.

Andreas M. schrieb:
> Es gibt inzwischen diverse Mechanismen zwischen Betriebssystem und Flash
> basierten Speichern um die Lebensdauer zu erhöhen. Man kann oder konnte
> sich z.B. auch bei einer SSD ins Knie schießen:
>
> - Man legt auf einer SSD zunächst eine Partition/Laufwerk mit voller
> Größe an und schreibt diese sehr voll. (Bei manchen SSDs ist dieser
> Schritt nicht notwendig)
> - Dann löscht man die Partition wieder und legt eine viel kleinere an.
> - Nun wird auschließlich dieser kleine Bereich genutzt.

Ich mag's nur ungerne schreiben, aber auch das ist leider Unsinn, der 
allenfalls für SSD aus dem letzten Jahrtausend gelten mag. Was Du 
beschreibst, ist "Dynamic Wear Leveling". Das mögen heute USB-Sticks und 
SD-Karten verwenden. Damit wären aber die heute angebenen TBW bei SSD 
kaum erreichbar.

Andreas M. schrieb:
> Das führt dazu, das die SSD für Schreibzugriffe nur den kleinen Teil des
> Flashspeichers nutzen kann, der der kleinen Partition zugeordnet ist. Da
> in dem restlichen, ungenutzen Bereich ja auch schon mal Daten
> geschrieben worden sind und die SSD nicht mitbekommt das diese Daten
> nicht mehr gebraucht werden kann sie diesen großen ungenutzen
> Flash-Bereich auch nicht für Schreibzugriffe nutzen -> die SSD geht
> schneller kaputt.

Nö, SSD arbeiten mindestens mit "Static Wear Leveling". Micron schreibt 
dazu in 
www.micron.com/-/media/client/global/documents/products/technical-note/n 
and-flash/tn2942_nand_wear_leveling.pdf

"Static data is managed by maintaining all blocks within a certain
erase count threshold. Blocks that contain static data with erase counts 
that begin to lag
behind other blocks will be included in the wear-leveling block pool, 
with the static data
being moved to blocks with higher erase counts."

Statische Blöcke, also Daten, die sich nicht ändern, werden vom 
Controller bei Bedarf auf dynamische Blöcke (die schon oft beschrieben 
wurden) umkopiert und umgekehrt. So kann man eine einigermaßen 
gleichmäßige Nutzung aller Blöcke erreichen.

Die Technical Notes von Micron sind übrigens hervorragend geeignet, 
Wissen in dem Bereich abzurunden.

MfG

Autor: Andreas M. (amesser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M.M.M schrieb:
> Hallo
>
> Andreas M. schrieb:
>> Unter Linux ist es üblich, das man mehrere Partitionen anlegt und so
>> eine trennung zwischen Programmen und Daten bekommt. Z.b. legt man
>> normalerweise eine kleinere Partition for das "root" nehmen und eine
>> größere für die Nutzerdaten unter "/home". Dadurch kann man z.B.
>
> Unter alles unter /bin /sbin usw. sind was?

Frage bitte nochmal so stellen das ich verstehe was Du meinst.

>> Für SD-Karten ist das nicht unbedingt gut. Denn Schreibvorgänge auf dem
>> "root" würden dann nur innhalb des Addressbereiches der "root" partition
>> passieren, entsprechendes gilt für Schreibvorgänge innerhalb des "home".
>
> Das ist Unsinn. Eine SD-Karte hat überhaupt keine Idee, was eine
> Partition ist. Die kennt primär mal nur Blöcke und ab SDXC sogar ein FS,
> nämlich exFAT.

Nein ist es nicht, der in SD Karten eingebaute Controller hat sehr wohl 
eine gewisse Intelligenz. Gerade bei den älteren Karten haben die 
Controller versucht Partitionen und Dateissteme zu erkennen um mit dem 
Wissen daraus das Wear-Leveling zu optimieren. Der Hinweis aus vielen 
Beidenungsanleitungen, die vorformatierten Karten nicht neu zu 
formatieren kommt nicht von ungefähr.

> Das ist Festplattendenke mit rotierendem Blech, wo Partitionen mit
> Sektoren verknüpft wurden. Bei Flashspeicher sind die Sektoren, mit
> denen die Partitionen verbunden sind aber auch nur logisches Level und
> werden selbst erst auf Hardwareblöcke gemappt.

Intern in der MMC schon. Das Betriebssystem selbst mappt da gar nichts. 
Auch bei einer SSD mappt das Betriebssystem nichts. Addressierung einer 
SSD von außen geschieht exakt identisch zu der einer normalen HDD. Wenn 
das anders wäre könnte man in alte Rechner ja keine SSDs einbauen.

> Andreas M. schrieb:
>> Es gibt inzwischen diverse Mechanismen zwischen Betriebssystem und Flash
>> basierten Speichern um die Lebensdauer zu erhöhen. Man kann oder konnte
>> sich z.B. auch bei einer SSD ins Knie schießen:
>>
>> - Man legt auf einer SSD zunächst eine Partition/Laufwerk mit voller
>> Größe an und schreibt diese sehr voll. (Bei manchen SSDs ist dieser
>> Schritt nicht notwendig)
>> - Dann löscht man die Partition wieder und legt eine viel kleinere an.
>> - Nun wird auschließlich dieser kleine Bereich genutzt.
>
> Ich mag's nur ungerne schreiben, aber auch das ist leider Unsinn, der
> allenfalls für SSD aus dem letzten Jahrtausend gelten mag. Was Du
> beschreibst, ist "Dynamic Wear Leveling". Das mögen heute USB-Sticks und
> SD-Karten verwenden. Damit wären aber die heute angebenen TBW bei SSD
> kaum erreichbar.
>
> Andreas M. schrieb:
>> Das führt dazu, das die SSD für Schreibzugriffe nur den kleinen Teil des
>> Flashspeichers nutzen kann, der der kleinen Partition zugeordnet ist. Da
>> in dem restlichen, ungenutzen Bereich ja auch schon mal Daten
>> geschrieben worden sind und die SSD nicht mitbekommt das diese Daten
>> nicht mehr gebraucht werden kann sie diesen großen ungenutzen
>> Flash-Bereich auch nicht für Schreibzugriffe nutzen -> die SSD geht
>> schneller kaputt.
>
> Nö, SSD arbeiten mindestens mit "Static Wear Leveling". Micron schreibt
> dazu in
> www.micron.com/-/media/client/global/documents/products/technical-note/n 
and-flash/tn2942_nand_wear_leveling.pdf
>
> "Static data is managed by maintaining all blocks within a certain
> erase count threshold. Blocks that contain static data with erase counts
> that begin to lag
> behind other blocks will be included in the wear-leveling block pool,
> with the static data
> being moved to blocks with higher erase counts."
>
> Statische Blöcke, also Daten, die sich nicht ändern, werden vom
> Controller bei Bedarf auf dynamische Blöcke (die schon oft beschrieben
> wurden) umkopiert und umgekehrt. So kann man eine einigermaßen
> gleichmäßige Nutzung aller Blöcke erreichen.

Richtig, aber wenn eine SSD "weis", dass ein statischer Block deswegen 
statisch
ist, weil er garn nicht mehr benutzt wird, dem Betriebssystem der Inhalt 
also komplett egal ist, dann brauch dar gar nichts umkopiert werden. 
Diese Information bekommt die SSD aber nur dann wenn die betreffenden 
Blöcke weiterhin zu einem Dateisystem gehören, denn nur dann kann das 
Betriebssystem
diese Information an die SSD senden... Wenn ich aber die Platte komplett 
zuschreibe und dann nur noch einen kleinen Teil für das Dateisystem 
nehme, dann bekommt die SSD diese Information nicht, muss also davon 
ausgehen, das die Daten noch gebraucht werden und wird diese munter auf 
dem Flash hin und her schieben statt sie einfach zu verwerfen.

Gruß
Andreas

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.