Linux-Tablet mit RasPi bauen - Display-Quelle

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.

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

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

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.

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.

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

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.

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:)
> 
https://www.ebay.de/itm/ODROID-C2-eMMC-Modul-8-GB-mit-Linux/132987106298?epid=1166603925&hash=item1ef6a633fa:g:5KIAAOSwjZJaAeSR

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

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.

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.

> 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.

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