www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Schnellster ARM basierter Mikrocontroller


Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Imon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.