mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Cortex M3 vs A8


Autor: Newbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum kann ein Cortex M3 nur 120 Mhz während ein Cortex A8 1 Ghz 
erreicht? Woran liegt das? Flash zu langsam?

Gruß
Newbie

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
* Flash zu langsam für Prozessor ohne Cache.
* Völlig anderer interner Aufbau, Pipelinetiefe M3:3, A8:13
* Herstellungsprozess M3: 130-180nm, A8: 45nm.

Ist ausserdem eine völlig andere Zielgruppe. Der M3 ist nicht auf hohe 
Performance optimiert, sondern auf geringen Aufwand bei für die 
Zielgruppe akzeptabler Performance.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwischen dieser Frage und einer tiefgreifenden Antwort liegen viele 
Stunden in Grundlagen und anderen Vorlesungen. A.K. hat schon ein paar 
wichtige Punkte genannt.
Generell haben hoehere Taktraten tiefere Pipelines zur Folge. d.h. die 
einzelnen Befehle werde in mehr kleine Haeppchen aufgeteilt. Das ist 
schoe und gut, hat aber bei jeder Verzweigung den NAchteil, dass die 
Pipeline weggeworfen werden muss, die hat "falsche" Folgebefehle 
reingeholt.
Flash ist eigentlich keine Option fuer einen A8 zur direkten 
Befehlsausfuehrung, er koennte im Endeffekt langsamer sein als ein M3, 
weil so viel von der Pipeline immer floeten geht bei Verzweigungen.
Befehle werden bei hohen Taktrate (>> 100 MHz) fast immer aus RAM-Zellen 
ausgefuehrt. Wenn es viele RAM Zellen sind, spricht man meistens von 
einem Cache. Viele MHz ohne Cache sind im Allgemeinen nicht viel wert. 
Cache und determinitisches Verhalten sind Erzfeinde. Im M3 Bereich wird 
aber sehr oft determinitisches Verhalten gefordert........
Es gaebe noch vieles, ich wuerde ein Grundlagenstudium Prozessortechnik 
dazu empfehlen :-)

Gruss, Robert

Autor: Fragensteller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Teufel schrieb:
> Cache und determinitisches Verhalten sind Erzfeinde

Hmmm... warum? Wenn ich sage dass die Reaktionszeit im Bereich von 
1-10us liegt, dann ist das auch deterministisch oder nicht? Ich muss 
dann in meiner Anwednung eben mit dem worst case rechnen und leben 
können.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fragensteller schrieb:
> Wenn ich sage dass die Reaktionszeit im Bereich von
> 1-10us liegt, dann ist das auch deterministisch oder nicht? Ich muss
> dann in meiner Anwednung eben mit dem worst case rechnen und leben
> können.

Manchmal ist es aber notwendig, dass die Reaktionszeit genau ist. Der 
Jitter zwischen best- und worst-case muss in diesen Fällen minimiert 
werden.

--
Marcus

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fragensteller schrieb:

> Hmmm... warum? Wenn ich sage dass die Reaktionszeit im Bereich von
> 1-10us liegt, dann ist das auch deterministisch oder nicht? Ich muss
> dann in meiner Anwednung eben mit dem worst case rechnen und leben
> können.

Wieder eine Frage der Zielgruppe, vereinfacht ausgedrückt. Wer mit Linux 
arbeitet (A8), dem sind exakte Reaktionszeiten im einstelligen 
Mikrosekundenbereich und genau reproduzierbares Laufzeitverhalten von 
I/O-Aktionen meist nicht allzu wichtig. Bei Controllern ohne 
Betriebssystem (M3) sind härtere Anforderungen jedoch häufiger 
anzutreffen.

Bei Controllern mit Cache ist es ziemlich schwer, den schlimmsten Fall 
auch nur herauszufinden, geschweige denn zu testen. So kann sich das 
Laufzeitverhalten von Caches drastisch ändern, wenn ein grosser selten 
voll genutzer Datenpuffer ab und zu mit ganz anderem Füllstand (anderer 
Speicheradresse) verwendet wird als sonst.

Die bei neueren CM3 auftrenden Variationen durch den dort vorhandenen 
Flash-Cache (LPC1700, 120MHz STM32) lassen sich einerseits einigermassen 
abschätzen und testen, andererseits durch Code im RAM reproduzierbar 
gestalten.

Mitunter kann man solche Probleme mit entsprechender manueller 
Cache-Konfiguration (festnageln bestimmter Bereiche) in den Griff 
kriegen, aber sowas ist wirklich kein Vergnügen.

Der Extremfall dieser Sichtweise sind Controller wie Propeller oder 
XMOS, bei denen Reaktionszeiten auf externe Ereignisse von 50ns bzw. 
10ns und exakte Ablaufzeiten gewährleistet werden können. In beiden 
Fällen laufen die Programme daher in internem verzögerungs- und 
kollisionsfreiem RAM.

Autor: Newbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es spezielle ARM CPUs für Echtzeitaufgaben?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja und nein, alle oder keiner, denn Echtzeit != Echtzeit. Da musst du 
bei den Anforderungen konkret werden. Eine garantierte Reaktionszeit von 
10s kriegst du mit allem zustande was Pins hat, eine von 10ns wird schon 
schwieriger.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Kleinigekti zur Nomenklatur:

Cortex-M = Mikrocontrolleranwendung (Kleine MSR Aufgaben)
Cortex-R = RealTime (zusätzlich DSP Befehle) für konplexere MSR Aufgaben
Cortex-A = Application (Betriebssystem, z.B. Linux. Hat eine MMU)

Cortex-M0 ist eine LowCost Ausführung vgl. mit M3.
Dann gab es noch eine für FPGA als Softcore. Glaub die M1 Variante.

Soweit mal zu dem ARM Controllern.

Autor: Newbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ja und nein, alle oder keiner, denn Echtzeit != Echtzeit. Da musst du
> bei den Anforderungen konkret werden. Eine garantierte Reaktionszeit von
> 10s kriegst du mit allem zustande was Pins hat, eine von 10ns wird schon
> schwieriger.

Andersherum: Gibt es spezielle ARM CPUs, für welche man die maximalen 
Ausführungszeit für jede Instruktion bestimmen kann?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das geht bei wohl jedem der üblichen ARM7er von NXP/ST/Atmel, wenn man 
Programm und Daten konsequent im RAM hält und auf DMA verzichtet. Denn 
dann kann man direkt nach dem Timing der Core-Doku vorgehen.

Ein alter Atmel ARM7 (AT91RM3400) war dementsprechend gebaut, mit 96KB 
RAM, ohne Flash, aber Urlader aus externem EEPROM.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Newbie schrieb:

> Gibt es spezielle ARM CPUs für Echtzeitaufgaben?

Sozusagen. Cortex-M1 als Softcore im FPGA. Das FPGA für die Echtzeit, 
den Prozessor für den Rest ;-).

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die maximale Ausführungszeit eines Befehls kann man für jede CPU 
bestimmen; bei Verwendung von DMA, Caches und Flash ist dieser Wert nur 
u.U. unerfreulich lang.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Die maximale Ausführungszeit eines Befehls kann man für jede CPU
> bestimmen; bei Verwendung von DMA, Caches und Flash ist dieser Wert nur
> u.U. unerfreulich lang.

Das Problem ist zunehmend autarke Peripherie. Führt der Prozessor einen 
Speicherzugriff aus, während beispielsweise ein DMA Controller gerade 
den Bus reserviert hat, dann kann man die Dauer dieses Befehls eben 
nicht genau angeben. Der Write Buffer ist ja auch irgendwann mal voll.

--
Marcus

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias schrieb:
> Eine Kleinigekti zur Nomenklatur:
>
> Cortex-M = Mikrocontrolleranwendung (Kleine MSR Aufgaben)
> Cortex-R = RealTime (zusätzlich DSP Befehle) für konplexere MSR Aufgaben
> Cortex-A = Application (Betriebssystem, z.B. Linux. Hat eine MMU)
>
> Cortex-M0 ist eine LowCost Ausführung vgl. mit M3.
> Dann gab es noch eine für FPGA als Softcore. Glaub die M1 Variante.
>
> Soweit mal zu dem ARM Controllern.

Versuchs doch mal so herum, ist mehr im Sinne der Erfinder

Cortex-A = Application
Cortex-R = RealTime
Cortex-M = Microcontroller

Faellt jetzt was auf mit der Nomenklatur? It's all about A R M :-)

Robert

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Zeit die der DMA-Controller den Bus belegen kann ist aber doch nach 
oben begrenzt, oder? Spätestens auf Applikationsebene weiß man ja auch 
wie man den DMA-Controller verwendet und welche maximalen Verzögerungen 
sich dadurch ergeben können.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Zeit die der DMA-Controller den Bus belegen kann ist aber doch nach
>oben begrenzt, oder? Spätestens auf Applikationsebene weiß man ja auch
>wie man den DMA-Controller verwendet und welche maximalen Verzögerungen
>sich dadurch ergeben können.

Dafür gibt es auch eine "Multi Level Busmatrix". Damit könenn sich 
mehrere Peripherien, oder Peripherie, RAM und CPU "gleichzeitig" 
unterhalten.
Deshalb hat Atmel auch in einigen Controllern zwei RAM Blöcke drin.
Dann kann sich eine Peripherie mit dem RAM unterhalten und gleichzeitig 
die CPU auf den anderen RAM Blo9ck zugreifen. Allerdings glaub ich, dass 
der Programmierer die verteilung des RAMs selber organisieren muss, dass 
dieses Feature auch wirklich so funktioniert, wie es gedacht ist ;-)

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Die Zeit die der DMA-Controller den Bus belegen kann ist aber doch nach
> oben begrenzt, oder? Spätestens auf Applikationsebene weiß man ja auch
> wie man den DMA-Controller verwendet und welche maximalen Verzögerungen
> sich dadurch ergeben können.

Meines Wissens nach liegt die Begrenzung der DMA-Zeit darin, dass es nur 
eine begrenzte Buffer-Groesse gibt. Wenn jetzt z.B. mem-mem Transfers 
stattfinden in ein sehr langsames Memory und die max. Buffergroesse 
genommen wurde, dann ist das zwar nicht sehr intelligent aber es bewegt 
sich in Richtung worst case. Es kommen einfach soviele Faktoren rein in 
eine Latenzzeit und beim Cahce wird es noch viel schwieriger den worst 
case zu berechnen.
Bei der Behauptung, dass Cache der Erzfeind der (harten) Echtzeit ist 
bleibe ich und DMA ist auch ein potentieller Verursacher extremen 
Jitters.
Bitte nicht falsch verstehen, DMA und Cache erhoehen die 
Durchschnittsleistung eines komplexeren Systems enorm, doch die 
Zyklenzaehlerei hoert da irgendwann auf.
(Fast) jeder Benchmark wird bessere Werte mit einem Cache liefern als 
ohne, doch worst case Betrachtungen von Antwortzeiten sind normalerweise 
ohne Cache deutlich besser.

Robert

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowohl DMA wie Caches verkomplizieren die Situation. Aber bei DMA ist 
das einigermassen kalkulierbar. Man kennt die Datenrate und die 
Übertragungscharakteristik und kann den dadurch erzeugten 
Bandbreitenverlust einrechnen.

Sehr kleinräumig betrachtet, d.h. auf wenige Befehle bezogen, tritt ein 
deutlicher Jitter auf, aber sobald man etwas mehr betrachtet kann man 
über die Bandbreitenrechnung gehen. Den Effekt von DMA kann man auch 
recht gut über künstlich hoch gehaltene DMA-Aktivität testen.

Bei Caches ist die Situation komplexer. Statistisch sind sie ein 
riesiger Gewinn, aber es ist sehr schwer, die worst cases der 
Nebeneffekte sinnvoll zu quantifizieren und zu testen. Sowohl 
kleinräumig wie grossräumig.

Testweises Abschalten von grösseren Caches ist keine Option, weil die 
damit ausgestatteten Prozessoren dann langsamer sind als die 
CM3/ARM7-Klasse. Und die Nebeneffekte können bereits bei einfachen 
Modifikationen eines Programms (oder der oben erwähnten ungewöhnlichen 
Pufferfüllrate) ganz anders ausfallen als bislang betrachtet, wenn man 
dadurch in Assoziativitätskonflikte gerät, die vorher aufgrund 
geringfügig unterschiedlicher Adresslage der Komponenten nicht 
auftraten.

Und so kann man das Verhalten von Caches zwar statistisch gut erfassen, 
aber Statistik sagt bekanntlich nichts über den Einzelfall aus. Wenn sie 
in 99,99% vorteilhaft sind, dann nützt das in harter Echtzeitsituation 
dennoch nichts, wenn diese 0,01% zum Versagen führen.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.
we violently agree :-)
Robert

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Aber bei DMA ist das einigermassen kalkulierbar. Man kennt die
> Datenrate und die Übertragungscharakteristik und kann den dadurch
> erzeugten Bandbreitenverlust einrechnen.

Aber es ging ja hier nicht um den Bandbreitenverlust, sondern um die
Frage, ob ich die maximale Ausführungszeit bestimmen kann. DMA, von
mir lediglich als hinreichend bekanntes Beispiel für einen weiteren
Busmaster angeführt, erhöht den worst-case der Ausführungszeit unter
Umständen nicht unerheblich.

Daneben kommt bei Applikationsprozessoren natürlich noch die Zeit für
die Adressübersetzung durch die MMU hinzu, die im schlimmsten Fall,
für den einen oder anderen durchaus überraschend, auch beim cache hit
auftreten kann.

--
Marcus

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:

> Aber es ging ja hier nicht um den Bandbreitenverlust, sondern um die
> Frage, ob ich die maximale Ausführungszeit bestimmen kann.

Wenn das DMA nicht in Bursts, sondern regelmässig als Einzelzyklen 
auftritt, dann kann man kalkulieren, dass beispielsweise alle 20 Takte 
ein solcher Zyklus auftritt und somit auf einen dadurch abgebremsten 
Befehl ~10 weitere ungebremste Befehle folgen. Auf diese Weise lässt 
sich eine Folge von Befehlen in einer kritischen Sequenz trotz 
DMA-Einflusses weit genauer kalkulieren, als sich aus der Summe der 
Einzelbefehle im worst case ergibt.

Dieser Ansatz ist letztlich schon eine Art Bandbreitenrechnung, 
zumindest kann man über die Bandbreitenrechnung die maximale Auswirkung 
auf nicht allzu kurze Sequenzen abschätzen.

> mir lediglich als hinreichend bekanntes Beispiel für einen weiteren
> Busmaster angeführt, erhöht den worst-case der Ausführungszeit unter
> Umständen nicht unerheblich.

Es kommt natürlich auf die Art des DMA an. Wenn das in längeren Bursts 
auftritt, dann ist die Situation ganz anders als wenn es beispielsweise 
ein SPI-Kanal ist, der alle Mikrosekunde je ein Byte loswerden will.

Wenn man mit Burst-DMA arbeitet und die Dauer des Bursts die gewünschte 
Echtzeiteigenschaft in Frage stellt, dann hat man sowieso schon verloren 
und muss nicht erst lange rechnen ;-).

> Daneben kommt bei Applikationsprozessoren natürlich noch die Zeit für
> die Adressübersetzung durch die MMU hinzu, die im schlimmsten Fall,
> für den einen oder anderen durchaus überraschend, auch beim cache hit
> auftreten kann.

Yep, das auch noch.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:

> Daneben kommt bei Applikationsprozessoren natürlich noch die Zeit für
> die Adressübersetzung durch die MMU hinzu, die im schlimmsten Fall,
> für den einen oder anderen durchaus überraschend, auch beim cache hit
> auftreten kann.

Handhaben diese Applikationsprozessoren den TLB miss eigentlich in 
Hardware oder als ganz klassische RISC per Exception?

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Handhaben diese Applikationsprozessoren den TLB miss eigentlich in
> Hardware oder als ganz klassische RISC per Exception?

Hardware. Zuviel RISC ist ja auch nicht gesund ;-)

--
Marcus

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.