Thema: Auf Android entwickeln

[MasterLee]

Was spricht eigentlich gegen ein Wetab?

[LittleFox]

Hi,

Was spricht eigentlich gegen ein Wetab?

die zu kurze Akkulaufzeit. Bei Wikipedia steht bis zu 6h, also gehe ich von 3h aus (mein Laptop ist mit 4 angegeben und schafft 2). 3h sind 2 Unterrichtsstunden, da reicht der Akku dann nicht mehr für den Zug Ich wohne in Chemnitz und gehe in Leipzig in die Schule ...
Trotzdem Danke für den Vorschlag

Demnach werde ich warten müssen bis man auf Tablets jedes beliebige OS (ohne hacks, Garantieverlust, andere Probleme) installieren kann, oder ich bau mein Tablet selber (da lern' ich gleich mal SMD löten )

Grüße,
LittleFox

[Svenska]

Demnach werde ich warten müssen bis man auf Tablets jedes beliebige OS (ohne hacks, Garantieverlust, andere Probleme) installieren kann, oder ich bau mein Tablet selber (da lern' ich gleich mal SMD löten )

Einspruch.
Garantieverlust darfst du garantiert einkalkulieren und BGA lötet sich mit einem Lötkolben eher schlecht. SMD wird bei großen µCs nicht verbaut, wenn es überhaupt für dich als Endkunden kaufbar ist. Bei Späßen wie PoP (Package-on-Package), wo der RAM als BGA-Baustein oben auf den µC in BGA-Bauform gebondet wird, hilft nichtmal mehr ein Backofen.

[erik.vikinger]

Hallo,

Ja, und dafür haben die einerseits ohnehin knappen System-RAM genommen, andererseits braucht die CPU zum Funktionieren dann zusätzliche Speicherbandbreite.

Ja, die Idee ist gut aber die reale Umsetzung hatte durchaus noch so ihre Tücken. Es gab ja auch extra Transmeta-CPUs mit 2 Speichercontrollern, einer für den normalen RAM und einer für die Code-Morphing-SW und den Cache.

Die hätten meiner Meinung nach lieber mal die native Architektur öffnen sollen, meinetwegen auch zusätzlich zum x86-Befehlssatz.

Hatten die das nicht auch? Wenn nicht dann hätten sie es auf jeden Fall tun sollen, ich wette Linux wäre keine 6 Monate später drauf gelaufen und hätte vielleicht auch mal zeigen können was in der Transmeta-CPU wirklich drin steckt. Zumindest wäre es mal interessant zu sehen was passiert wenn sich ein fremdes CPU-Kuckucksei im x86-Nest breit macht.

Also willst du einfach einen dynamischen Compiler, der zur Laufzeit den Code so hinbiegt, dass er auf der gerade vorhandenen Architektur läuft und dafür Kompatiblität in Hardware opfern.

Ja, genau das meine ich. Aus meiner Sicht wäre 3D-Now bei den AMD-CPUs dafür ein guter Kandidat, das ist defacto ausgestorben und trotzdem muss AMD diese Befehle irgendwie noch unterstützen und ich wette AMD gibt sich keine besondere Mühe das sehr effizient zu tun (das würde ja Entwicklungszeit und Transistoren kosten) so das ich der Meinung bin das man 3D-Now lieber per Code-Morphing auf SSE abbilden sollte (so viel langsamer als mit schlecht gepflegter HW dürfte das auch nicht werden). Im Prinzip ist doch das was FlashBurn mit seiner Spezial-Page für den Syscall macht auch nur eine simple Vorstufe von Code-Morphing, warum dann nicht gleich das Executable nehmen und alle INT 0x80 Befehle gegen SYSCALL o.ä. austauschen? Und wenn das Code-Morphing aus Power-PC-Code welchen für x86 erzeugt ist das im Prinzip auch nicht so viel anders nur das eben eine Abstraktionsebene höher Disassembliert und danach wieder richtig neu Assembliert (mitsamt anständigen Optimierungen) werden muss. Genau das ist es auch was ich an ARMs Stelle machen würde wenn die Kompatibilität doch mal an einer Stelle nicht gewährleistet werden kann. Bei Micro-Controllern spielt sowas keine Rolle da der Code eh spezifisch kompiliert wird aber überall dort wo der Konsument vielleicht mal noch ältere SW (z.B. Apps die vor Jahren mal Geld gekostet haben und ihren Job noch immer gut machen) weiter nutzen möchte ist das IMHO ein guter Weg.

Nur, weil dein Hammer nicht passt, setzt du dich auch nicht mit der Feile hin und bastelst so lange dran rum, bis er geht.

Netter Vergleich, ich fürchte nur das Intel an x86 so lange feilen wird bis es doch irgendwie für Embedded taugt.
Ob das Ergebnis dann immer noch so viel mit x86 zu tun hat wie der Name suggeriert steht auf einem anderen Blatt, ich persönlich denke ja dass das gar nicht funktionieren kann und bin deswegen der Meinung das Intel die fehlende Kompatibilität dann lieber in SW mitliefern sollte.

Das ist aber genau das, was ich von einem PC-kompatiblen erwarte, im Gegensatz zu einem Tablet.

Also ich persönlich erwarte das auch von einem Tablet und wenn die Industrie mein Geld haben will das muss sie mir auch so ein Tablet bieten ansonsten treffe ich als mündiger Verbraucher meine Kaufentscheidung eben anders.

Zumal die aktuellen schnellen ARMs wesentlich mehr Energie pro Rechenleistung fressen als die kleineren und wenn du einen aktuellen Cortex mit 2-4 GHz takten wolltest, bist du garnicht mehr so weit weg vom Energiebedarf von x86ern.

Das ist durchaus richtig aber die Anzahl der benötigten Transistoren ist bei ARM immer noch deutlich kleiner und das schlägt sich spürbar im Kaufpreis nieder. Nebst dessen das ich noch keinen Quad-Core-ARM mit über 100W gesehen habe.

Wer sagt denn, dass die das nicht tun?

Niemand, ich vermute sie werden das auch irgendwann mal machen, ich bin ja auch der Meinung das es Intels einzigste echte Option ist um dieses Ziel zu erreichen.

Mikrocode gibt es jedenfalls schon

Also ich glaube Du überschätzt da die Möglichkeiten des Micro-Code ein ganz klein wenig.

... hilft nichtmal mehr ein Backofen.

Das hägt sehr von den Fähigkeiten dieses Backofens ab. Wenn der über eine schnelle und dynamische Temperaturregelung verfügt dürfte der noch im Geschäft sein.
Aber für mein Projekt hab ich mir auch schon mal überlegt ob ein selbst gebauter Reflow-Ofen nicht eine gute Option wäre.


Grüße
Erik

[Sannaj]

Kann man nicht so ne Hijektin-Option einbauen, die beim Start fragt, ob ein bestimmtes Kernelmodul geladen werden soll, das das System Hiject und ein neues Startet?

[LittleFox]

Hi,

Das ist aber genau das, was ich von einem PC-kompatiblen erwarte, im Gegensatz zu einem Tablet.

Also ich persönlich erwarte das auch von einem Tablet und wenn die Industrie mein Geld haben will das muss sie mir auch so ein Tablet bieten ansonsten treffe ich als mündiger Verbraucher meine Kaufentscheidung eben anders.

Full ACK! @Industrie: lesen und danach handeln!

Demnach werde ich warten müssen bis man auf Tablets jedes beliebige OS (ohne hacks, Garantieverlust, andere Probleme) installieren kann, oder ich bau mein Tablet selber (da lern' ich gleich mal SMD löten )

Einspruch.
Garantieverlust darfst du garantiert einkalkulieren und BGA lötet sich mit einem Lötkolben eher schlecht. SMD wird bei großen µCs nicht verbaut, wenn es überhaupt für dich als Endkunden kaufbar ist. Bei Späßen wie PoP (Package-on-Package), wo der RAM als BGA-Baustein oben auf den µC in BGA-Bauform gebondet wird, hilft nichtmal mehr ein Backofen.

Das man BGA nicht per Hand löten kann weiß ich. Von PoP hab ich allerdings noch nie etwas gehört 
Tablet selber bauen war sowieso mehr ironisch als ernst gemeint, auch wenn es nicht ganz ironisch war

Grüße,
LittleFox

[MasterLee]

Hi,

Was spricht eigentlich gegen ein Wetab?

die zu kurze Akkulaufzeit. Bei Wikipedia steht bis zu 6h, also gehe ich von 3h aus (mein Laptop ist mit 4 angegeben und schafft 2). 3h sind 2 Unterrichtsstunden, da reicht der Akku dann nicht mehr für den Zug Ich wohne in Chemnitz und gehe in Leipzig in die Schule ...
Trotzdem Danke für den Vorschlag

Demnach werde ich warten müssen bis man auf Tablets jedes beliebige OS (ohne hacks, Garantieverlust, andere Probleme) installieren kann, oder ich bau mein Tablet selber (da lern' ich gleich mal SMD löten )

Grüße,
LittleFox

Reichen 10Std mit HotSwap?
http://www.tabletpcworld.com/tablet-pc/10zoll-tabletpcs/tablet-pc-rml-10.html

[Svenska]

Reichen 10Std mit HotSwap?
http://www.tabletpcworld.com/tablet-pc/10zoll-tabletpcs/tablet-pc-rml-10.html

Da ist aber ein x86 drin, was ja ein Ausschlusskriterium ist.

Gruß,
Svenska

[LittleFox]

Hi,

@MasterLee danke für deine Vorschläge Leider hat Svenska recht, ich möchte einfach kein x86 mehr Ich bin der Meinung, wenn schon ein neuer Laptop/Tablet dann gleich ein ARM - x86 soll endlich sterben. Außerdem erwecken "Preisanfrage" und das Design sehr stark den Eindruck das das Teil sehr teuer ist  Die Akkulaufzeit würde allerdings reichen

Grüße,
LittleFox

[MasterLee]

Zur Zeit hab ich ein ähnliches Problem ich hab vor kurzen mein Notebook geschrottet (es ist während der Installation von Windows 98 verreckt). Nun verbleibt mir nur noch mein Hammerhead RT800 aber die Batterien sind schon älter und neue kosten 90 Euro pro Stück ausserdem hat das gute Stück nur 512MB RAM.
Was mir bei Handys aufgefallen ist die Batterien halten zwar lang aber nur wenn man nichts tut. Python mit WSGIref server zum testen lutscht die Batterien ziemlich schnell leer.
Vielleicht ist selbst bauen doch eine Lösung?
http://www.liquidware.com/shop/show/BB-BT/BeagleTouch
http://www.liquidware.com/shop/show/BB-BJC/BeagleJuice

[Sannaj]

Naja, so teuer ist die Abwärtskompatiblität dann doch nicht. Wenn man sich die Effekte mal anschaut fällt einen auf ....

Auf die Gefahr hin das man mir gleich Unhöflichkeit vorwerfen wird aber das ist eine recht naive Betrachtung, in Wirklichkeit ist das schon ein wenig komplexer. AMD hat damals bei den ersten 64Bit-Opterons was von 5% mehr Transistoren für den 64Bit-Modus erzählt und 5% sind bei einem Chip der schon einige Millionen Transistoren hat ne ganze Menge und dabei darf man nicht vergessen das ein Großteil der Transistoren für Cache usw. drauf gehen und da dürften die Änderungen eher marginal gewesen sein so das ich persönlich vermute wenn man nur den puren CPU-Kern betrachtet kommen da eher 15 bis 20% Zuwachs bei raus.

Du solltest aber auch die Leitungen betrachten. Eine Verdopplung der Wortbreite und 8 zusätzliche Register kosten einfach, auch wenn man keine Abwährtskompatibilität berücksichtigt. Dazu kommen noch die kosten für zusätzliche SIMI Befehle usw., die ebenfalls unabhängig von der Abwährtskompatiblität sind.

Gruß Sannaj

[Martin Erhardt]

Nun ja aber es gibt da ein paar User die rooten ihr Gerät und können dann Aftermarket-Firmware-Distribution wie CyanogenMod aufspielen(mit Tools wie einem bootmenu etc.Es gibt hierzu zwar ziemlich viel Dokumentation aber von schlechter Qualität. Auf XDA-Developers dem Hauptforum zum Thema bekommt man immer wieder haarsträubende Dinge zu hören, weil die meisten Leute dort nur 08/15 User sind die eben mal einen Artikel gelesen haben.  Ich habe damit nicht allzu gute Erfahrungen gemacht )

Bei CyanogenMod handelt es sich annscheinend um ein Betriebssystem mit Kernel.
Das lässt Wikipedia indirekt verlauten:
"CyanogenMod war auch das erste Betriebssystem für Mobilgeräte, das für die Prozessverwaltung den Brain Fuck Scheduler (BFS) einsetzt – eine Änderung, die in experimentelle Zweige des offiziellen Android-Codebaums übernommen wurde."(§2)
Der Scheduler gehört schließlich zum kernel.

ACHTUNG:
Lange Rede kurzer Sinn: Ich vermute das man mit diesen Tools auch seinen eigenen Kernel auf das Gerät spielen könnte.

PS: Echt viel los heute im Forum

[Svenska]

Außer dem halben Jahr Threadalter hat sich inzwischen ein bisschen was neues entwickelt, so dass die älteren Beiträge nicht mehr topaktuell sind.

Die Linuxleute stören sich an den gleichen Problemen wie wir. Da eine gemeinsame Plattform aber nicht überall in Frage kommt (wegen z.B. Router/Tablet/Netbook/Settopbox/Computer-Unterschieden), gibt es FTDs (Flattened Device Trees), die teilweise schon mandatory sind und zunehmend sein werden und sich meiner Meinung nach für Linux eher durchsetzen werden. Auch ACPI ist im Gespräch, um die Unterschiede zu abstrahieren.

Außerdem entsteht mit Windows 8 für ARM eine Plattform, trotz der ganzen Secure-Boot und EFI-Scherereien.

Zu sehen ist da bisher wenig, aber in 1-2 Jahren kommt da hoffentlich die richtige Richtung.

CyagenMod benutzt die Originalsourcen der Hersteller (GPL) und baut daraus einen verbesserten Kernel plus Userland zusammen. Es wird kein echtes Linux (nur Android), die Kernelversion bleibt und die Treibersituation bleibt ebenfalls: kaputte Treiber bleiben kaputt und proprietäre Treiber proprietär.

Gruß,
Svenska