Lowlevel
OffZone => Offtopic => Thema gestartet von: Svenska am 10. January 2012, 01:20
-
Hallo,
nachdem hier verstreut schon einige Dinge in Bezug auf ARM umhergeflogen sind, würde ich das gerne mal an einer Stelle sammeln wollen, statt jeden Thread damit zu töten. :-P
Grund: Phoronix hat ein ARM-System mit Ubuntu mal auf Performance getestet (hier (http://www.phoronix.com/scan.php?page=article&item=compulab_trimslice)). Es handelt sich um ein CompuLab Trim-Slice (Mini-Desktop) mit Dual Cortex-A9 (1 GHz Tegra2) mit GBit-Ethernet und SATA - und ist nicht zugenagelt.
Aufs Raspberry Pi (http://www.raspberrypi.org) müssen wir wohl noch länger warten. :-(
Gruß,
Svenska
-
Ich weiß zwar nicht so ganz genau was das Ziel dieses Threads ist, aber da du bereits zwei System vorgestellt hast erzähle ich mal über meine derzeitigen Aktivitäten für meine Bachelor Thesis :)
Ich schreibe einen Kernel der auf einem STM32 F103 (http://www.st.com/internet/mcu/subclass/1169.jsp?WT.ac=p2_bn_sep11_stm32f1series) - Controller mit einem ARM Cortex-m3 Prozessor läuft. Evaluationsboard mit diesem Controller kann man bei Olimex (http://www.olimex.com) bekommen.
Die von STM bereitgestellte Firmware ist allerdings nicht zu empfehlen, man sollte dann wirklich schon von Grund auf alles selber implementiere, aber genau darum geht es hier ja :D
Zum beschreiben des Flashs und als GDB-Server zum debuggen wird die Software openOCD (http://openocd.sourceforge.net/) verwendet.
Jetzt noch ein paar Weisheiten und Erfahrungen :D
- Finger weg von Windows. Wer wirklich Spaß haben möchte ARMs sollte unter Linux programmieren. Grund ist die schlechte Qualität der Windows-SW für ARMs die mehr Ärger macht als hilft.
- Auf IDEs verzichten. Man muss relativ oft (öfters als bei AVRs oder x86er) in den build und flash-Prozess eingreifen. Nicht zuletzt weil ARMs verschiedene Befehlssätze haben (Thumb,Thumb2) und teilweise grundlegende Unterschiede zwischen verschiedene ARM-Prozessoren sind (cortex-m3 haben beispielsweise keine FPU). Auch das beschreiben der µCs ist alles andere als einheitlich.
- Auf die STM-Firmware verzichten. Ich weiß nicht wie es bei anderen Herstellern aussieht, aber die Firmware von STM hat eine umständliche API und ist teilweise von echt mieser Qualität. Ich empfehle vor gebrach sich den Quellcode anzusehen - ist aber auch sonst sehr unterhaltsam :D
- openOCD ist noch weit weg von fertig und fehlerfrei. Bei Version 0.6 kann man sich mit GDB nicht auf den openOCD-Server verbinden wenn man die symbols aus der elf geladen hat. OpenOCD schickt den Registerdump dann nämlich doppelt und GDB bricht die Verbindung ab weil das Antwortpaket unerwartet groß ist :D
So, mehr fällt mir nicht ein :)
Ist zwar jetzt eher alles für den Embedded-Bereich, aber vielleicht Hilft es ja jemanden und vieles lässt sich bestimmt auch auf die "größere" ARMs anwenden.
Einem Anfänger kann ich ARMs nicht empfehlen, aber wer schon etwas lowlevel-Erfahrung hat wird sich schnell mit ihnen anfreunden :)
PS.: Der Befehlssatz macht Spaß und ist, auch wenn das R für RISC steht, bei weitem nicht so langweilig wie der AVR-Befehlssatz. Man kann sie also durchaus auch in Assembly programmieren ohne verrückt ohne verrückt zu werden :D
PPS.: Raspberry Pi <3
-
Hallo,
ich hab im Rahmen meines Forschungsprojekts auch mit einem STM32 (aber F107) arbeiten dürfen. Das ist auch ein Cortex-M3, mit 72 MHz und 64 KB RAM sowie Host-USB und Ethernetschnittstelle. Die STM32-Firmware-Lib habe ich benutzt und mich größtenteils an AppNotes festgehalten. Am Ende kam da eine Wetterstation ran (USB-HID-Gerät mit proprietärem, aber rückentwickelten Protokoll) und die Daten waren über Ethernet (HTML und XML) erreichbar.
Wenn man die benötigte Zeit reduzieren und gegen Geld eintauschen möchte, dann kann man das tun. Ich habe von der Uni eine Keil IDE benutzt, mit eigenem Compiler, Debugger und Echtzeitkernel ("Keil RTX") und das ging ganz gut. Dumm war nur, dass ich innerhalb einer VM auf einem verdammt lahmen Hostrechner arbeiten musste. Ist eine ganz andere Welt als die Opensource-Toolchains, aber dafür legt man halt vier- oder fünfstellige Geldbeträge auf den Tisch.
Meine Bachelorarbeit habe ich für ein BeagleBoard xM (TI OMAP) entwickelt. Allerdings war das nicht lowlevelig, sondern ein mitgelieferter Linux-Kernel mit Debian Userland.
Ansonsten wollte ich mit dem Thread mal ausloten, was es so an developerfreundlichen ARM-Geräten jenseits der Evaluationsboards gibt.
Gruß,
Svenska
-
Hallo,
Ansonsten wollte ich mit dem Thread mal ausloten, was es so an developerfreundlichen ARM-Geräten jenseits der Evaluationsboards gibt.
Also da wird wohl nicht viel bei raus kommen.
So wie ich das sehe gibt es da 2 Kategorien an interessanten ARM-Chips: einmal die typischen Microkontroller (Cortex-M[0..4], von etlichen Firmen wie NXP,STM,Freescale u.v.m.) und zum anderen die richtigen SoCs (wie den Tegra von NVidia, den Exynos von Samsung, den Snapdragon von Qualcomm, den OMAP von TI und etwas weniger bekannt die ARMADA von Marvell (wurde aus dem PXA entwickelt der von Intel übernommen wurde welche von den StrongARM abstammen, mit den PXA hab ich selber schon gearbeitet)).
Die Vertreter der Microkontroller-Klasse haben alle gewisse Gemeinsamkeiten wie das nur sehr kleine Mengen an RAM/Flash verfügbar sind und oft auch eine MMU fehlt (was beides den Einsatz von Linux wirksam verhindert) dafür gibt es da eine sehr große Fülle an Varianten und man bekommt eigentlich bei allen Hersteller anständige Datenblätter usw. An Pehripherie wird oft Ethernet (meist nur 100MBit ganz selten auch mal 1GBit), USB (meistens maximal Full-Speed (1.1) als Device und/oder Host aber manchmal auch High-Speed (2.0) als Device und ganz selten sogar als Host mit einem EHCI-kompatiblen Interface) und all den anderen Kram den man so gewöhnt ist wie UART/SPI/I²C/CAN/LIN/.... Auch gute Development-Board bekommt man in allen möglichen Varianten für fast jede Familie der ARM-Microkontroller von etlichen Herstellern (nicht nur vom Chip-Hersteller selber), meistens liegt auch ein vollständer Schaltplan/Stückliste/... bei um auf Basis dessen ein eigenes Produkt zu entwickeln.
In der SoC-Klasse bekommt man oft keine vollständigen Datenblätter und auch nur selten frei käufliche Development-Boards. An Peripherie steckt meistens ein richtiger DRAM-Controller, Flash-Controller (meistens mit irgendeiner Boot-Fähigkeit), USB (meistens Host und Device mit High-Speed), ein paar UARTs, Bluetooth, Touch-Controller und ne GPU drin. Oft sind auch noch irgendwelche Funk-Module für WLAN, GPS oder auch GSM/EDGE/UMTS drin da ja Handys/Tablet-PCs das primäre Marktsegment sind das die Hersteller bedienen wollen. Leider fehlen oft ein paar Schnittstellen die benötigt werden um daraus einen normalen PC zu bauen, wie z.B. LAN und SATA. In dem Trim-Slice ist SATA z.B. über einen zusätzlichen USB-SATA-Chip angebunden was natürlich keine berauschenden Performance-Werte beim Umgang mit HDDs ermöglicht, LAN ist dort mit einem Realtek-Chip per PCI-Express angebunden. Immerhin hat der Tegra 2 von NVidia eine einzelne PCI-Express-Lane als Root-Port, die meisten anderen ARM-SoCs haben sowas überhaupt nicht so das es kaum möglich ist irgendein vermisstes Interface nach zurüsten, diese SoCs sind also so wie sie sind und fertig. Als ich im Februar 2011 auf der Embedded-World war habe ich an vielen Ständen sehr interessante Embedded-Boards mit dem Tegra 2 gesehen und man hat mir auch oft gesagt das NVidia den Embedded-Markt bedienen will und demzufolge auch Datenblätter usw. veröffentlichen wird, nur leider ist das bis heute nicht passiert und die Auswahl an tatsächlich käuflichen Tegra 2 Boards ist auch eher kleiner als größer geworden. Die Hoffnung das tatsächlich mal einer der ARM-SoC-Hersteller sich diesen, sicher lukrativen, Markt erschließen will war also vergebens.
Es gibt zwar mit älteren ARM-SoCs durchaus interessante frei käufliche Boards aber einen echten PC kann man aus diesen auch nur selten bauen da keine echte Erweiterungsschnittstelle (wie eben PCI-Express) verfügbar ist und selbst einige Basics wie SATA konsequent fehlen. Dazu kommt das der RAM-Ausbau oft sehr bescheiden ist. Der Exynox unterstützt zwar 2 GB aber es gibt keine freien Boards damit. Der Tegra 2 untersützt auch nur maximal 1 GB RAM, so wie alle übrigen ARM-SoCs auch, aber der Tegra 3 soll immerhin schon 2 GB unterstützen.
Wer sich überlegt aus einem ARM-SoC einen halbwegs brauchbaren General-Purpose-PC zu bauen wird leider auf ganzer Linie enttäuscht. Das einzigste was zumindest auf dem Papier einen guten Eindruck macht ist der ECX-1000 von Calxeda (http://www.calxeda.com/products/energycore/ecx1000), der kann echte 4GB RAM und die nicht nur mit lahmen 32Bit Datenbus-Breite und maximal 800MT/s sondern mit vollen 64Bit Datenbus-Breite (eigentlich 72 Bit für ECC) und bis zu 1333 MT/s DDR3. SATA (mit AHCI-kompatiblen Host-Controller) und LAN sind auch schon drin, neben einem SD-Card-Controller und jeweils mehreren UART/SPI/I²C-Schnittstellen. Es fehlen ihm zwar 2 sehr wichtige Dinge, eine GPU und USB-Anschlüsse, aber da er mehrere PCI-Express-Root-Ports hat kann man beides extern nachrüsten. Von TI gibt es einen USB 3.0 Host-Controller mit xHCI-Interface für PCI-Express, sogar mit Datenblättern, und ne taugliche PCI-Express-GPU bekommt man gleich mit Platine in jedem Computer-Laden (sogar Versionen wo man auch freie Treiber für bekommt) so das dem eigentlich nichts im Wege steht um aus einem ECX-1000 einen echten vollwertigen PC zu bauen. Ob der Chip auch wirklich was taugt versuche ich gerade raus zu finden, ich hab bei Calxeda einfach mal Datenblätter angefordert.
Wenn irgendjemand noch andere interessante ARM-SoCs kennt so wäre es toll hier etwas darüber zu lesen.
An dem Performance-Vergleich, den Svenska verlinkt hat, finde ich besonders interessant das die beiden ARM-SoCs den beiden Atom-CPUs durchaus dicht auf den Fersen sind bzw. sogar oft überholen, auch der Pentium-M ist in einigen Disziplinen gar nicht mehr weit entfernt. Trotzdem benötigen die ARM-SoCs nur einen Bruchteil an elektrischer Energie, selbst gegenüber den Atom-Systemen. Ich denke (und hoffe) spätestens wenn erste ARMv8-Systeme verfügbar sind dürfte sowas gegenüber einem klassischen x86-PC eine ernstzunehmende Alternative darstellen und dann wird hoffentlich auch der Markt nach anständigen Datenblättern verlangen.
Grüße
Erik
-
Puh... also mein Wille war es nicht, den Thread durch viel Text umzubringen. :-)
Du hast sehr viele SoCs erwähnt, aber ich suche ja nach einem Evaluationsboard mit Gehäuse außen rum, und - bis auf den Preis - ist das Trim-Slice schonmal nicht allzuweit weg. Für das Raspberry Pi soll es ja auch später Gehäuse geben.
Beide Systeme sind wohl insoweit offen, dass alle benötigten Sourcen vorhanden sind (bis auf die GPU) und sie durchaus genug Rechenleistung für Haus und Hof liefern. Mein Entwicklungs-PC für die Bachelorarbeit war auch nur ein Atömchen (mit 4 Threads).
-
Hi,
interessanter Thread - und vorallem: Danke für den Rapsberry Pi Link :-o
Ich glaube das werde ich mir kaufen wenn es so weit ist. Produktion ist ja angelaufen :)
Grüße,
LittleFox
-
Hm… Das von Svenska erwähnte BeagleBoard, aber vor allem der BeagleBone (http://beagleboard.org/bone) sehen ja auch recht interessant aus.
~90$ und ein ARM Cortex-A8 von TI
-
Hi,
ich merk schon: ich brauch einen Digitalmonitor :D
Sind diese ARM Board eigentlich wenigstens ein bisschen kompatibel zueinander?
Grüße,
LittleFox
-
Sind diese ARM Board eigentlich wenigstens ein bisschen kompatibel zueinander?
Mit relativ hoher Wahrscheinlichkeit nicht. ARM liefert seine Prozessoren quasi nur im "Sourcecode" aus, jeder Hersteller packt dann noch eigenes Zeug auf den Chip und Produziert ihn dann. Dadurch unterscheiden sich die CPUs bereits, Von der Peripherie mal ganz abgesehen. Es gibt halt keine Standards oder Leitschemen wie der IBM-PC, zumindest sind mir keine bekannt.
Leider hat kaum ein Hersteller, oder gar keiner, das Interesse mehr ein Heimcomputer herzustellen der Offen ist. :cry:
-
Sind diese ARM Board eigentlich wenigstens ein bisschen kompatibel zueinander?
Innerhalb eines Herstellers vielleicht teilweise, sonst nein. Auf der CPU befindet sich meist eine Menge Onchip-Peripherie zusätzlich zur externen Peripherie. Teilweise wird auch mit Bussystemen hantiert, die kein Probing unterstützen (z.B. SPI).
Dazu kommt, dass es meist Linux dafür gibt, es aber sehr umständlich ist, sich einen eigenen Kernel dafür zu bauen. Wenn man den vorgefertigten Kernel nimmt und das Userland austauscht, bekommt man ein gutes Linux - oder man investiert viel Zeit.
Gruß,
Svenska
-
Hi,
das ist doch blöd das es da keine Standards gibt ...
Gibt es andere Prozessorarchitekturen für die es eine ausreichend standardisierte Plattform gibt?
Hab jetzt noch ein interessantes ARM Board gefunden:
http://pandaboard.org/
Da ist sogar WLAN, Bluetooth, etc. schon mit drauf.
Gäbe eigentlich schon einen guten PC ab - wenn man das Teil selber aufrüsten könnte ... (PCIe, ...)
Edit: könnte man ein Mainboard für ARM Prozessoren bauen? Wie es momentan bei PCs gemacht wird, also Speicher rein, CPU rein, Graka drauf und fertig? Bei PCs muss es ja nun wirklich kein SoC sein ... Platz hab ich unterm Schreibtisch genug
Grüße,
LittleFox
-
Wenn ARM auch im Desktop/Notebook-System wird sich da sicher irgend etwas festsetstellen. Und da ich nicht glaube das die Intel-Architektur ewig lebt, muss irgendjemand die Nachfolgerschaft antreten. Wobei ARM natürlich trotzdem er Low End bleiben wird. Vielleicht stirbt auch irgendwann der PC in seine heutigen Gestalt einfach aus oder es setzt sich am Ende eine x86-ähnliche Architektur durch.
-
Hallo,
die mangelnden Standards haben Nachteile, aber auch Vorteile: Die Geräte können auf ihre zu lösende Problematik zugeschnitten werden. Und auch wenn Microsoft für Win8 ein ARM-UEFI vorschreibt, wird sich das nicht überall durchsetzen, sondern hauptsächlich auf den Geräten, die groß genug für Windows sind.
Im Serverbereich ist ARM noch nicht einsatzfähig, da es eine reine 32-Bit-Architektur ist. Für 2013 werden erste 64-Bit-Implementationen angekündigt, aber vor 2014 werden die sich meiner Meinung nach nicht durchsetzen.
Das Thema (ordentliches) PCIe + SATA + USB 2.0 + GBit in einem ARM hatten wir schon: Gibt es nicht. :-(
Edit: könnte man ein Mainboard für ARM Prozessoren bauen? Wie es momentan bei PCs gemacht wird, also Speicher rein, CPU rein, Graka drauf und fertig? Bei PCs muss es ja nun wirklich kein SoC sein ... Platz hab ich unterm Schreibtisch genug
Theoretisch ja, praktisch eher nicht: der Speicher ist meist festgelötet, PCIe 16x gibt es eigentlich nicht und für ARM gibt es keine standardisierte Sockel. Im Embedded-Bereich gibt es sowas durchaus, das sind meist auf Backplanes aufbauende Geräte, aber nur zu Apothekerpreisen - und oft nur dann, wenn du viele auf einmal kaufst, wenn es für dich überhaupt verkauft wird. (TI bietet z.B. gewisse CPU-Reihen nur für Telekommunikationsunternehmen an, auf dem freien Markt gibt es dann nur die kleinere Version mit weniger Features.)
Gruß,
Svenska
-
Hi,
das es die ganzen Schnittstellen nicht gibt, hab ich schon gelesen.
Wo liegt das Problem für PCIe16? Nicht möglich oder baut nur keiner? Die Sockelproblematik kann ja ziemlich einfach gelöst werden, von BGA auf PGA/LGA geht ja ziemlich Simpel - wird nur eben etwas größer.
Wie ist PCIe eigentlich bei x86/IBM-PC angebunden (Hardware)? Könnte man auf die gleiche Art auch an ARM Prozessoren PCIe nachrüsten? Weitere Geräte kann man ja über PCIe anbinden (SATA/USB/etc.).
Man kann auch wenn es ein Standard gibt die Geräte noch genau an die bedürfnisse zuschneiden. Dann wird der Standard eben nicht eingehalten - eine standardisierte Plattform sagt ja nicht das alle Geräte die den in der Plattform verwendeten Prozessor benutzen auch zum Plattformstandard kompatibel sein müssen.
Grüße,
LittleFox
-
Das Thema (ordentliches) PCIe + SATA + USB 2.0 + GBit in einem ARM hatten wir schon: Gibt es nicht. :-(
Doch gibt es, müsste eigentlich irgendwo in meinem viel zu langen Beitrag drin sein, wimre.
-
Hi,
ich denke eher das er meinte das nicht mehr als eine PCIe Lane verfügbar ist. Das ist ja kein ordentliches PCIe ;)
Ich denke das Problem ist einfach das momentan einfach alles unbedingt in SoCs gegossen werden muss - aber wozu? Bei Handys, Tablets und Embedded Geräten macht das ja vielleicht sinn - evt. auch noch bei Laptops. Aber bei Rechnern? Warum stellt keine Firma einfach reine ARM Prozessoren her?
Grüße,
LittleFox
-
Wo liegt das Problem für PCIe16? Nicht möglich oder baut nur keiner?
Entweder baut nur keiner oder verkauft nur keiner.
Wie ist PCIe eigentlich bei x86/IBM-PC angebunden (Hardware)?
Über einen Controller. Im Gegensatz zu ISA sind PCI/PCIe nicht an die CPU-Architektur gebunden und lassen sich so relativ einfach an ARM anbinden. Das Problem ist die Bandbreite, für die ARM historisch nicht entwickelt wurde und wo halt einige Reifen zum Durchspringen existieren. :-)
Man kann auch wenn es ein Standard gibt die Geräte noch genau an die bedürfnisse zuschneiden. Dann wird der Standard eben nicht eingehalten - eine standardisierte Plattform sagt ja nicht das alle Geräte die den in der Plattform verwendeten Prozessor benutzen auch zum Plattformstandard kompatibel sein müssen.
Stimmt. Aber ein Standard gibt eine Grundmenge an Geräten vor, die in kompatibler [evtl. zertifizierter] Implementation vorliegen müssen, um den Standard einzuhalten. Daran scheitert's. Guck dir PCI und die Kompatiblitätsmechanismen für VGA an, dann weißt du, wohin das führen kann.
ich denke eher das er meinte das nicht mehr als eine PCIe Lane verfügbar ist. Das ist ja kein ordentliches PCIe ;)
Zumindest nicht für Grafikkarten, genau.
Warum stellt keine Firma einfach reine ARM Prozessoren her?
Entweder, weil es sich nicht rechnet, weil der Markt nicht existiert oder weil die Unternehmen der Meinung sind, der Markt existiere nicht. (Alles, wo kein Windows drauf läuft, ist für Endkunden als PC-Ersatz nicht relevant.) Außerdem ist ARM eine Architektur, die es an sich nur in Software zum selber synthetisieren gibt. Warum sollte ich teuer Lizenzgebühren für etwas bezahlen, was ich dann 1:1 implementiert wieder verkaufe? Jedes Unternehmen will seinen eigenen Stempel drauf drücken.
Ich kann die Unternehmen verstehen - gut finden tue ich es trotzdem nicht.
Gruß,
Svenska
-
Hi,
Man kann auch wenn es ein Standard gibt die Geräte noch genau an die bedürfnisse zuschneiden. Dann wird der Standard eben nicht eingehalten - eine standardisierte Plattform sagt ja nicht das alle Geräte die den in der Plattform verwendeten Prozessor benutzen auch zum Plattformstandard kompatibel sein müssen.
Stimmt. Aber ein Standard gibt eine Grundmenge an Geräten vor, die in kompatibler [evtl. zertifizierter] Implementation vorliegen müssen, um den Standard einzuhalten. Daran scheitert's. Guck dir PCI und die Kompatiblitätsmechanismen für VGA an, dann weißt du, wohin das führen kann.
Ich meinte das eher so, dass es auch ARM Geräte geben kann die den Standard gar nicht erfüllen - so wie es ja auch x86 Prozessoren in Geräten gibt, die kein bisschen IBM-PC kompatibel sind (glaube ich zumindestens mal gelesen zu haben).
Warum stellt keine Firma einfach reine ARM Prozessoren her?
Entweder, weil es sich nicht rechnet, weil der Markt nicht existiert oder weil die Unternehmen der Meinung sind, der Markt existiere nicht. (Alles, wo kein Windows drauf läuft, ist für Endkunden als PC-Ersatz nicht relevant.) Außerdem ist ARM eine Architektur, die es an sich nur in Software zum selber synthetisieren gibt. Warum sollte ich teuer Lizenzgebühren für etwas bezahlen, was ich dann 1:1 implementiert wieder verkaufe? Jedes Unternehmen will seinen eigenen Stempel drauf drücken.
Ich kann die Unternehmen verstehen - gut finden tue ich es trotzdem nicht.
Gruß,
Svenska
Wenn ARM an der Strategie also nix ändert bleibt nur eine andere Prozessorarchitektur ...
@erik: wann ist deine CPU fertig? ;)
Grüße,
LittleFox
-
Ich meinte das eher so, dass es auch ARM Geräte geben kann die den Standard gar nicht erfüllen - so wie es ja auch x86 Prozessoren in Geräten gibt, die kein bisschen IBM-PC kompatibel sind (glaube ich zumindestens mal gelesen zu haben).
Ja, gab es. Nahezu alle diese Geräte sind aber mausetot. Das einzige halbwegs aktuelle, nicht PC-kompatible Geräte ist das Bifferboard, was aber auch für Linux spezielle Patches braucht (u.a. weil da ein 486SX-Kern ohne Floating Point drin ist). Sonst bedeutet außer bei Apple x86 == PC-kompatibel.
Wenn ARM an der Strategie also nix ändert bleibt nur eine andere Prozessorarchitektur ...
ARM hat damit nichts zu tun. Beschwere dich bei STMicroelectronics, Texas Instruments, Atmel, Samsung, Freescale oder den anderen Herstellern, die ARM-Kerne in ihre Chips einbauen. Halbwegs verbreitete Alternativen sind auch dünn gesät... MIPS kann bei Weitem nicht mithalten, weder in Bezug auf Rechenleistung noch auf Verbreitung. Leider.
Gruß,
Svenska
-
Wenn ARM an der Strategie also nix ändert bleibt nur eine andere Prozessorarchitektur ...
ARM hat damit nichts zu tun. Beschwere dich bei STMicroelectronics, Texas Instruments, Atmel, Samsung, Freescale oder den anderen Herstellern, die ARM-Kerne in ihre Chips einbauen. Halbwegs verbreitete Alternativen sind auch dünn gesät... MIPS kann bei Weitem nicht mithalten, weder in Bezug auf Rechenleistung noch auf Verbreitung. Leider.
Ich beschwere mich aber bei ARM dafür dass sie die Architektur NUR lizensieren. Können die nicht Lizenzen für SoC verlangen und reinen ARM Kerne selber bauen?
Grüße,
LittleFox
-
Hi,
gerade noch ein anderes ARM Gerät mit offener Plattform gefunden:
http://www.open-pandora.org/
Sieht zwar aus wie eine Spielkonsole, kann aber auch für andere Sachen verwendet werden :)
Ist nur leider etwas teuerer.
Grüße,
LittleFox
-
Oha, die ist sehr interessant. Aber 450 Taler sind übel...
-
Ich kenn noch eins:
http://wiki.openmoko.org/wiki/Main_Page
-
ach das openmoko - das hab ich ja komplett vergessen ....
-
Hi,
ein neuer Stern am Tablet-Himmel:
http://aseigo.blogspot.com/2012/01/reveal.html
http://aseigo.blogspot.com/2012/02/spark-answers.html
Endlich ein offenes Tablet :) Ab Mai soll es verfügbar sein.
Grüße,
LittleFox
-
Ich habe seit zwei Tagen ein FriendlyARM mini6410 (http://www.friendlyarm.net/products/mini6410) - Das Gerät macht auch einen sehr guten Eindruck. Alles offen und viele Möglichkeiten zum Spielen :)