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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.