Ich verwende zur Zeit einen AT91SAM9G20. Das ist ein ARM9 der mit 400MHz
läuft. Gibt es eigentlich noch schnellere (höherer Takt, mehr
Rechenleistung allgemein, FPU) Mikrocontroller? (Also "richtige"
Mikrocontroller, die etwas internes RAM haben und z.B. von NAND Flash
direkt booten können, viele I/Os und Peripherie haben.) Oder ist die
nächste Stufe dann ein "richtiger" Prozessor? Ich weiß das ist alles
etwas schwammig. Ich denk da eben an sowas wie den AT91SAM9 nur eben mit
z.B. 800MHz Takt, ARM 11 Kern und FPU.
Das hängt ein bischen sehr davon ab, wo du die Grenze zwischen
Controller und Prozessor ziehst. Mancher hätte sie bereits unterhalb des
AT91SAM9G20 gezogen und diesen eher als Prozessor eingestuft. Andere
könnten sogar SoCs wie die OMAPs noch als Controller sehen, weil
praktisch alles ausser dem Speicher schon drin ist.
@A.K.
Ja du hast recht. Das geht fließend ineinander über. Für mich ist in dem
Fall noch alles irgendwie ein Mikrocontroller, das ich selbst
initialisieren kann und worauf ich noch FreeRTOS zum laufen bekomme. ;-)
Das war bei dem AT91SAM9 gar nicht so einfach, weil der
Speichercontroller, die MMU und die Takterzeugung doch recht komplex
sind. Ich hätte nun bedenken, dass das noch schwieriger wird, wenn man
einen "richtigen" Prozessor einsetzt, so dass man dort an z.B. U-Boot
nicht mehr vorbei kommt, welches aber natürlich auch speziell an das
Board angepasst werden muss.
Der Hintergrund der Frage ist, das ich für meine Anwendung LUA als
Skriptsprache verwende. Dadurch werden Programme doch erheblich
langsamer als wenn es reines C ist, so dass etwas mehr Rechenleistung
doch von Vorteil ist. Irgendwann dieses Jahr soll ja der LUA JIT
Compiler für ARM fertig werden, das ist vielleicht die bessere
Alternative.
... schrieb:> Ja du hast recht. Das geht fließend ineinander über. Für mich ist in dem> Fall noch alles irgendwie ein Mikrocontroller, das ich selbst> initialisieren kann und worauf ich noch FreeRTOS zum laufen bekomme. ;-)> Das war bei dem AT91SAM9 gar nicht so einfach, weil der> Speichercontroller, die MMU und die Takterzeugung doch recht komplex> sind. Ich hätte nun bedenken, dass das noch schwieriger wird, wenn man> einen "richtigen" Prozessor einsetzt, so dass man dort an z.B. U-Boot> nicht mehr vorbei kommt, welches aber natürlich auch speziell an das> Board angepasst werden muss.
Darf ich dir ein Linux als Unterbau für deine Applikation ans Herz
legen,
der AT91sam9G20 hat eine ausgezeichnete Unterstützung durch die
sam4linux Leute, Ich habe selbst damit schon einiges gestemmt. Denn wenn
ich mir dein Beitrag so durch lese habe ich ein wenig denn Verdacht das
du dich mit der Initialisierung des Prozessors und der MMU vielleicht
ein wenig galoppiert hast. Wie auch immer bei denn U-boot/ Linux Ansatz
wird das von dein Betriebssystem schon erledigt und so Kompliziert ist
das mit denn uboot an das Bord anpassen ist das auch nicht, es gibt
bereits eine Config
für das Ek-Board von Atmel die Kopierst du änderst die Board Id und
passt ggf. das Environment noch ein wenig an.
>> Der Hintergrund der Frage ist, das ich für meine Anwendung LUA als> Skriptsprache verwende. Dadurch werden Programme doch erheblich> langsamer als wenn es reines C ist, so dass etwas mehr Rechenleistung> doch von Vorteil ist.
lässt du das Skript parsen, oder nutzt du ein precompiliertes Binary.
Vielleicht ist es auch möglich die Lua Skripte während des Entwickeln
in C Code zu wandeln und sie so zu Optimieren bzw. langfristig zu
ersetzen.
Vielleicht reicht also nur eine geänderte Stratgie um dein Problem mit
den
langsamen lua in den griff zu bekommen.
Der Sinn einer Scriptsprache ist ja grad, dass nachträglich dem System
Funktionen hinzugefügt werden können. Den selben Code als C Code
schreiben ist natürlich die Triviallösung, die aber grad nicht gewünscht
ist. Mal davon abgesehen, das C für jeden Anwender und nicht
Programmierer, der nur sein Problem lösen will, eine Zumutung wäre.
Sinnvoller wäre der LUA JIT Compiler, der aber leider noch nicht fertig
ist, aber, wie schon gesagt, dieses Jahr noch fertig werden soll.
Linux als Betriebssystem ist auch eher kontraproduktiv. Dadurch wird ja
die Reaktionszeit und das ganze Zeitverhalten durch den Overhead noch
langsamer. Das FreeRTOS ist in der Hinsicht optimal. Was nützen mir die
zusätzlichen Features von Linux, wenn ich die gar nicht brauche?
Außerdem hat man bei FreeRTOS vollen Zugriff auf alle Resourcen des
Prozessors (Interrupts etc.), ohne Treiber schreiben zu müssen. Manchmal
muss es eben wirklich schnell und vor allem deterministisch sein. (Das
ist dann aber als Funktion in C programmiert, die von LUA aufgerufen
wird, falls da jetzt jemand nachdenklich wird, wie das zusammen passt.)
Vergalopiert hätte ich mich mit der Initialisierung der MMU, Speicher
etc. nur, wenn ich z.B. drei Monate dafür gebraucht hätte und das dann
vielleicht auch nur mittelmäßig funktioniert hätte. Mit "kompliziert"
meinte ich, das es eindeutig komplizierter ist den ARM9 mit MMU zu
initialisieren als einen ARM7. Trotzdem ist das in 1 oder 2 Tagen fertig
programmiert und debugged. Ich kann mir aber schon vorstellen, dass es
Prozessoren gibt, wo der Aufwand noch viel größer ist und wo es keinen
Sinn macht, das Rad neu zu erfinden. In dem Fall brauchte ich aber
sowieso einen eigenen Bootloader, weil U-Boot die speziellen
Anforderungen eh nicht erfüllen konnte.
