Hallo Zusammen,
meine Frage richtet sich an alle ARM-Experten.
Zurzeit bin ich auf der Suche nach einer Ersatz-Lösung für einen DSP.
Anwendungsszenario ist eine Maschinenregelung, also harte Real-Time
Anforderungen.
Meine Idee war nun "einfach" die neuste Generation ARM (z.b. A53)
einzusetzen in der Hoffnung, dass dieser einfach dermaßen massiv mehr
Rechenleistung hat als der vorher eingesetzte DSP(AD ASP21489), dass
sich dadurch meine aktuellen Zeitprobleme (Berechnungszeit 100us besser
wären aber 10us) lösen.
Ist diese Performace-Steigerung realistisch und kann ich mit einem A53
meine Real-Time-Anforderung erfüllen?
Leider habe ich absolute keine Erfahrung mit den "Consumer"-ARM-Cores,
deswegen meine Frage: Geht das überhaupt so einfach wie ich mir das
vorstelle, oder habe ich etwas nicht bedacht?
Als eventuell passenden Typ hatte ich mal diesen Prozessor rausgesucht:
https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i.mx-applications-processors/i.mx-8-processors/i.mx-8m-nano-arm-cortex-a53-cortex-m7:i.MX8MNANO
Was meint ihr dazu?
Noch etwas Offtopic: Wenn ich einen Dual-Core nehme, kann ich dann auf
einem Kern meine Maschinenregelung laufen lassen und mit dem anderen
parallel Kommunikation über Ethernet machen oder gibt es auch da
irgendwelche Einschränkungen?
Vielen Dank für alle euren Antworten!
Schöne Grüße
Manuel
Du hast vergessen anzugeben, was deine Anwendung zeitkritisch zu
berechnen hat. Am besten stellst du die Quelltexte der kritischen
Funktionen hier bereit.
Moin,
Manuel schrieb:> Was meint ihr dazu?
Da wuerd' ich sagen: Kauf dir ein billiges Board mit dem entsprechenden
Prozessor drauf und probier's einfach aus.
> Noch etwas Offtopic: Wenn ich einen Dual-Core nehme, kann ich dann auf> einem Kern meine Maschinenregelung laufen lassen und mit dem anderen> parallel Kommunikation über Ethernet machen oder gibt es auch da> irgendwelche Einschränkungen?
Du brauchst erstmal einen Dualcore, der das unterstuetzt, d.h. wo dann
eben ein core nicht fuer's Betriebssystem hergenommen wird, sondern nur
fuer den Spezialkram. Und dann teilt sich der core ja z.b. das
Speicherinterface mit dem anderen Core und droelfzig weiteren Units, die
da alle ggf. auch mal am RAM rumschraddeln wollen. Damit ist dann nicht
so recht sichergestellt, wie lange dein core an deinem Algorithmus
rumhampelt...
Gruss
WK
Manuel schrieb:> Leider habe ich absolute keine Erfahrung mit den "Consumer"-ARM-Cores,> deswegen meine Frage: Geht das überhaupt so einfach wie ich mir das> vorstelle, oder habe ich etwas nicht bedacht?
Mit "Consumer"-Prozessoren ist das fast unmöglich. Diese Prozessoren
sind praktisch nur mit Linux zu benutzen - insbesondere auch mangels
Dokumentation und Zwangs-Treiber-Binary-Blobs - was nicht echtzeitfähig
(genug) ist.
Cortex-A ist nicht wirklich auf Echtzeitfähigkeit und Determinismus
ausgelegt - ein Durchlauf des Algorithmus kann schneller als der nächste
sein, bedingt durch Cache-Effekte. Damit ist eigentlich nur Soft
Realtime zu bewerkstelligen.
Die NXP Chips sind allerdings auch nicht wirklich "Consumer", man könnte
sie ohne Linux betreiben, den Cortex-M7 Kern sowieso. Als Alternative
kann man hier noch die TI Sitara Reihe nennen - diese haben extra für
solche Anwendungen zusätzliche DSP-Kerne und so eine Art
Mikrocontroller-Kerne ("PRU") integriert, welche echtzeitfähig sind.
Wenn man aber hier den Cortex-A-Kern für die Rechenleistung braucht, hat
man hier auch wieder das Echtzeit-Problem.
Ansonsten gibt es ja noch Cortex-R - explizit für
Rechenleistung+Echtzeitfähig ausgelegt, aber eher Nische+Teuer.
Für eine Aussage sind das einfach zu wenig Angaben.
Was verstehst Du unter "Maschinenregelung"?
Eine poplige Synchron-/Asynchronmaschine?
Dafür reicht bedeutend weniger, auch mit 3-4
Kommunikationsschnittstellen zusätzlich die bedient werden müssen.
Wenn der Anwendungsfall darin besteht einen Motor zu regeln und bischen
Ethernet/CAN/RS485 zu bedienen, würde ich persönlich eher auf einen M
anstatt auf einen A setzen.
Manuel schrieb:> Meine Idee war nun "einfach" die neuste Generation ARM (z.b. A53)> einzusetzen in der Hoffnung,
Die Geschwindigkeit der CPU hat nichts mit Realtime zu tun. Es geht bei
Realtime um eine Festlegung des Maximums an Pausen.
Ein 4 GHz Intel kann 1 sec brauchen um auf externe Peripherie
zuzugreifen. Ein 20MHz AVR kann alle uS einen Puls ausgeben und das
garantiert und immer.
D.h. du musst schon viel genauer definieren was du willst.
leo
Stefan F. schrieb:> Du hast vergessen anzugeben, was deine Anwendung zeitkritisch zu> berechnen hat. Am besten stellst du die Quelltexte der kritischen> Funktionen hier bereit.
Hallo,
erst einmal vielen Dank für eure Antworten!
Wie oben geschrieben geht es um Maschinenregelung, genauer um eine
Variante des Direct Torque Control.
Die meiste Rechenzeit wird vermutlich mit trigonometrischen Funktionen
also sin,cos,tan,asin,acos,atan2 verbraucht.
Die Echtzeitanforderung dabei ist, dass die neuen Regelparameter alle
z.B. 25us neu berechnet werden müssen.
Also auf einem STM32H7(M7-Core) hatte ich auch mal ein Benchmark
gemacht, der war aber nur minimal schneller im Vergleich zu dem oben
erwähnten DSP.
Jitter in der Berechnungszeit wäre kein Problem, solange man sicher
unter einem Wert bleiben könnte.
Hat denn hier jemand vielleicht ein Bauchgefühl in wie weit sich die
Berechnungen beschleunigen lassen würden? Also eher Faktor 2 oder Faktor
10 oder so?
Schöne Grüße
Manuel
Manuel schrieb:> Jitter in der Berechnungszeit wäre kein Problem, solange man sicher> unter einem Wert bleiben könnte.
Das "sicher" ist das Problem. Keiner kann dir garantieren, dass ein
Cache Fill nur soundso lange dauert. Auf den vollständig dokumentierten
Prozessoren könntest du theoretisch ohne SDRAM arbeiten, ein
Bare-Metal-System implementieren, alles im internen SRAM machen, Caches
& Branch Prediction abschalten usw. Damit könnte das in Etwa klappen,
aber "sicher" ist das nicht!
Manuel schrieb:> Die meiste Rechenzeit wird vermutlich mit trigonometrischen Funktionen> also sin,cos,tan,asin,acos,atan2 verbraucht.
Und da lässt sich nichts mit LUTs usw. mehr dran machen?
Manuel schrieb:> Also eher Faktor 2 oder Faktor> 10 oder so?
Eher Faktor 10-100, im Vergleich zum M7, bei bestimmten Berechnungen
(unter Nutzung von NEON & Co). Nur was bringt dir das, wenn die
Rechenzeit stark schwankt... Dazu kommt dass Peripherie-Zugriffe auf
Cortex-A auch ziemlich langsam sind. Da können pro Registerzugriff
locker 100 Takte draufgehen - da bringt eine schnelle Berechnung auch
nicht mehr so viel.
Hohe Rechenleistung und harte Echtzeitfähigkeit ist das
Informatik-Äquivalent zu "leistungsfähig und leicht" - teuer!
Niklas G. schrieb:> Hohe Rechenleistung und harte Echtzeitfähigkeit ist das> Informatik-Äquivalent zu "leistungsfähig und leicht" - teuer!
Teuer wäre jetzt nicht so das Problem ;)
Die TI Sitara-Reihe sieht recht vielversprechend aus, danke für diesen
Tipp!
Gibt es noch andere Typen die du als eventuell passend erachten würdest?
Der Regelalgorthmus ist schon wirklich stark auf Rechenzeit optimiert
worden. Also wo LUTs möglich sind, sind auch LUTs. Das ganze ist einfach
wirklich komplex :(
Schöne Grüße
Manuel
Manuel schrieb:> Die meiste Rechenzeit wird vermutlich mit trigonometrischen Funktionen> also sin,cos,tan,asin,acos,atan2 verbraucht.
Da wäre eher die frage wie gut deine bisher verwendete Mathe-Bibliothek
dafür und wie gut ist die neu zu verwendete daraufhin optimiert.
Was davon konnte der jetzige µC in Hardware ganz oder Teilweise
abfrühstücken und was kann der neue davon.
Und je nach dem welcher Datentyp tatsächlich verwendet wird kann das
Pendel mal in die eine oder die andere Ausschlagen.
Du siehst es gibt hier eine menge Abhängigkeiten, so das eine Pauschale
Aussage hier überhaupt nicht seriös wäre.
Selbst wenn der eine µC 10x so schnell ist wie der andere kann es gut
passieren das die Konkrete Software am ende um den Faktor 10x langsamer
ist weil es genau die Zeitkritische Funktion bei dir in Software mit zig
Tausenden Takten nachbilden muss was der "lahme" µC in wenigen Takten in
Hardware macht.
Der A53 hat z.B.
Wenn du hier was abschätzen willst müsstest du dir im Prinzip von beiden
Varianten den Code auf Assembler Ebene anschauen und in den
Datenblättern die Takte dafür raus suchen und zusammenrechnen...
Für mich ist der Sitara kein Echtzeitprozessor, sondern ein ganz
normaler Axx-Arm. Ich benutze gerade einen mit einem normalen Linux
drauf. Da ist nichts echtzeitmäßiges dabei. Jedenfalls bei den
Einstiegsmodellen.
Und Standalone mit TI-RTOS würde ich den nicht betreiben wollen.
Ich würde doch eher die M- oder R- Reihe dafür nehmen.
Versuche lieber die Berechnungszeiten durch Optimierungen in den Griff
zu bekommen und dann einen normalen M4 zu benutzen. Kostenmäßig sind die
sehr attraktiv. Da kann man evtl auch mehrere von nehmen.
PittyJ schrieb:> Für mich ist der Sitara kein Echtzeitprozessor, sondern ein ganz> normaler Axx-Arm. Ich benutze gerade einen mit einem normalen Linux> drauf. Da ist nichts echtzeitmäßiges dabei.
Wenn man ihn so nutzt, nicht. Aber die Modelle mit PRU sind genau
dafür gemacht.
PittyJ schrieb:> Jedenfalls bei den> Einstiegsmodellen.
Richtig, die ganz kleinen haben keine PRU. Die etwas größeren, wie z.B.
der AM3359 (welcher immer noch zur kleinsten Familie gehört), welcher
sich auch in sehr handlichem Format auf dem BeagleBone Black befindet,
aber schon.
PittyJ schrieb:> Und Standalone mit TI-RTOS würde ich den nicht betreiben wollen
Warum nicht? Das ist genau dafür gemacht. Dank der Doku kann man sich
sogar ein eigenes (RT)OS schreiben. Es gibt auch Bibliotheken extra für
Bare-Metal-Programmierung ohne (RT)OS; ist natürlich alles nicht so
straightforward wie bei einem STM32 oder so, aber durchaus machbar.
Die TI Sitara sind eigentlich genau für sowas wie anspruchsvolle
Maschinen/Roboter-Steuerung gemacht - die DSP-Kerne für, na, DSP, die
PRU's für Industrie-Protokolle wie EtherCAT und andere hart
echtzeitkritische Dinge, die ARM-Kerne für sehr rechenaufwendige Sachen,
Benutzeroberfläche, Daten-Ein/Ausgabe, Webserver und so. Der genannte
AM3359 ist quasi ein hybrider asymmetrischer 6-Kerner. Die einzelnen
Kerne sind über ein eigenes ziemlich komplexes FIFO-System vernetzt.
Heißt natürlich nicht dass es das von anderen Herstellern nicht auch so
gibt.
PittyJ schrieb:> Versuche lieber die Berechnungszeiten durch Optimierungen in den Griff> zu bekommen und dann einen normalen M4 zu benutzen.
Warum nicht M7?
Manuel schrieb:> Jitter in der Berechnungszeit wäre kein Problem,> solange man sicher unter einem Wert bleiben könnte.
Die verbleibende Frage ist: Wie schlimm ist es, wenn hin und wieder mal
eine Berechnung zu lange dauert? Wie schlimm ist es, wenn 0.1% aller
Berechnungen zu lange dauern? Wie schlimm ist es mit einmal jährlich?
Wie bereits gesagt wurde, kannst du einen modernen Consumer-ARM effektiv
nur mit Linux (oder sogar Android) füttern. Du kannst aber problemlos
einen Kern für deinen Kram freischaufeln (per cmdline).
Wenn du dann noch bestimmte Dinge im Linux festlegst, z.B. dass die
Systemlast nicht über xx% liegt (d.h. dein Linux-System nicht die
Speicherbandbreite wegfrisst) oder du anderweitig das System verstehst
(z.B. dass die gesamten Berechnungen im Cache stattfinden können und
der Cache für den betreffenden Kern exklusiv ist), dann kommst du
beliebig nah an deine Echtzeitanforderungen ran.
Du wirst sie aber nie erreichen können, weil es keine harten Garantien
gibt. Und damit landen wir wieder bei der ersten Frage: Wie schlimm ist
es, wenn die mal versagt?
Besser wäre ein Prozessor mit speziellen Echtzeitkernen, oder direkt ein
eigener Prozessor dafür.
Das größte Problem der A-Kerne ist, dass diese komplex anzusteuern sind,
lange Pipelines haben und meist noch noch alle möglichen Busse,
Interconnects und andere Busmaster im Gesamtsystem unterwegs sind. Die
schaffen zwar einen hohen Durchsatz aber es kann durchaus mal einen
kurzen "Schluckauf" im System geben. Du brauchst aber Determinismus,
laut deiner Aussage im 25µs Raster. Laut ARM sind die R's dafür gemacht.
(Haben halt eine wesentlich kürzerer Pipeline) Sie kann man am ehesten
mit den älteren Cores (ARM966) vergleichen. (Habe hier ein System mit
einem 400Mhz R7)
Beim Multi-Core Systemen kann man natürlichen in jedem anständigen OS
einen Core ausnehmen und komplett außerhalb des Betriebssystems nutzen.
Nur manchmal benutzen mehrere Cores die selben ALUs, dann wirds auch
wieder problematisch.
Ich würde es mit einem Cortex M4 oder M7 probieren der Bare-Metal
ausschließlich die Regelschleife bedient. (plus die ADC und die PWMs)
Die restlichen Regelparameter (Geschwindigkeit, Positionsvorgabe,
Steuersignale) Könnte man z.B. per SPI oder I2S (mit DMA) von außen in
den Controller reinschieben. Manche Microcontroller haben auch eine
eingebaute Cordic. (Für die Trigonometrie) z.B. STM32G4. Die könnte dann
sogar per DMA paraller zur CPU rechnen.
PittyJ schrieb:> Für mich ist der Sitara kein Echtzeitprozessor, sondern ein ganz> normaler Axx-Arm. Ich benutze gerade einen mit einem normalen Linux> drauf. Da ist nichts echtzeitmäßiges dabei. Jedenfalls bei den> Einstiegsmodellen.
Die nimmt man dann ja auch nicht.
Besorge Dir mal einen Beaglebone AI. Der 4000'er Sitara dadrauf hat:
- 2 A15-Kerne für Linux
- 2 C67xx-Kerne für DSP
- 2 Dual M4
- 2 PRUs
Die laufen alle unabhängig voneinander.
So ein Beaglebone AI ist nicht allzu teuer und wäre eine ideale
Testplattform.
Für den großen Hunger gibts dann z.B. Keystone II: 4* A15 plus 8* C67xx.
(66AK2H14)
fchk
> Die meiste Rechenzeit wird vermutlich mit trigonometrischen Funktionen> also sin,cos,tan,asin,acos,atan2 verbraucht.> Also auf einem STM32H7(M7-Core) hatte ich auch mal ein Benchmark> gemacht, der war aber nur minimal schneller im Vergleich zu dem oben> erwähnten DSP.
Da spricht voellige Ahnungslosigkeit.
Du hast CPUs mit einem Anforderungsprofil gebenchmarkt dass u.U.
ueberhaupt nichts mit den wirklichen Anforderungen zu tun hat.
Das ein DSP fuer eine Regelung seine Zeit mit Trigonometrie
vertroedelt, ist eine wohl nicht zutreffende Mutmassung.
Der guckt hoechstens in LookUp-Tables und interpoliert.
Und mit dem was ein ueblicher Kompiler so absondert, wird man
einen DSP leistungsmaessig auch nicht auslasten.
Einen ARM vllt schon. So gesehen sind deine Benchmarks auch
nichts wert.
Hallo zusammen,
erstmal vielen Dank für alle Antworten!
svedisk ficklampa schrieb:> Da spricht voellige Ahnungslosigkeit.>> Du hast CPUs mit einem Anforderungsprofil gebenchmarkt dass u.U.> ueberhaupt nichts mit den wirklichen Anforderungen zu tun hat.> Das ein DSP fuer eine Regelung seine Zeit mit Trigonometrie> vertroedelt, ist eine wohl nicht zutreffende Mutmassung.> Der guckt hoechstens in LookUp-Tables und interpoliert.>> Und mit dem was ein ueblicher Kompiler so absondert, wird man> einen DSP leistungsmaessig auch nicht auslasten.> Einen ARM vllt schon. So gesehen sind deine Benchmarks auch> nichts wert.
Wie oben schon erwähnt wir die Trigonometrie über LUTs gelöst.
Was würdest du denn empfehlen?
@All
Ich bin noch auf die C2000 Reihe von TI gestoßen, die scheinbar stark
für diesen Anwendungsfall optimiert ist, hat damit jemand Erfahrung?
Schöne Grüße
Manuel
> auf die C2000 Reihe von TI gestoßen
Ich kenne viele Designs die genau die fuer die zeitkritischen
Regelaufgaben benutzen. Gibt es auch mit Gleitkomma und diversen
Coprozessoren (z.B. CLA) etc.
Lothar schrieb:> steuere die Caches manuell. Damit ist Bare-Metal Performance möglich.
Ist das nicht ein Widerspruch? Ohne Caches mehr Determinismus und
weniger Performance. 100% manuell lassen sich die Caches auch nicht
steuern.
In einem Test von mir sank die Performance eines Test-Algorithmus auf
dem AM3359 um den Faktor 50, wenn man alle Caches und Branch Prediction
abschaltet.
Verzögerung durch Pipeline, Bus und SDRAM lassen sich sowieso nicht
steuern.
Niklas Gürtler schrieb:> Ist das nicht ein Widerspruch? Ohne Caches mehr Determinismus und> weniger Performance.
Ohne Caches kommst du aber nicht auf hohe Taktfrequenzen. Die Flash
Speicher haben nur zweistellige MHz Zugriffsrate.
Stefan F. schrieb:> Ohne Caches kommst du aber nicht auf hohe Taktfrequenzen.
Ja. Und mit Caches nicht auf Echtzeitfähigkeit, oder nur sehr
kompliziert.
Stefan F. schrieb:> Die Flash Speicher haben nur zweistellige MHz Zugriffsrate
Solche Anwendungsprozessoren wie die Sitara haben keinen Flash und
führen sowieso alles aus dem RAM aus. Man kann zwar externes Parallel
Flash in den Adress Raum einblenden, aber das macht's noch langsamer...
Niklas Gürtler schrieb:> Ja. Und mit Caches nicht auf Echtzeitfähigkeit, oder nur sehr> kompliziert.
Kommt drauf an, was man als "Echtzeitfähig" bezeichnet. Ich verstehe
darunter, dass bestimmte Aktionen innerhalb einer vorgegebenen Zeit
erledigt sein müssen. Das geht mit Cache auf jeden Fall besser, als
ohne.
Wenn man die Ausführungsgeschwindigkeit taktgenau voraus berechnen will,
dann sind Caches jedoch störend.
> Und mit Caches nicht auf Echtzeitfähigkeit
Wenn ein Stellglied alle 10 us bedient werden muss, und ein
dedizierter Prozessor/Core mit einem nicht konkurrierendem* Cache
fuer die Berechnung weniger als 10 us braucht, wo ist das Problem?
Warum sollte man da den Cache abschalten?
Damit es deterministisch laenger braucht? :-)
*) Also ohne das weitere Prozessoren/Cores die Hitrate beeinflussen.
Stefan F. schrieb:> Das geht mit Cache auf jeden Fall besser, als ohne.
Und was wenn der Zugriff auf eine bestimmte Instruktion in 0,001% der
Programmläufe einen Line Fill bewirkt der das Programm um genau 100
Takte zu langsam macht?
svedisk ficklampa schrieb:> wo ist das Problem?
Das Problem ist, festzustellen, ob der Prozessor das wirklich immer in
10us schafft, und nicht bloß in 99,999% der Fälle. Das wäre dann weiche
Echtzeit.
Niklas Gürtler schrieb:> Und was wenn der Zugriff auf eine bestimmte Instruktion in 0,001% der> Programmläufe einen Line Fill bewirkt der das Programm um genau 100> Takte zu langsam macht?
Ich weiß nicht, welche Cache-Optionen die großen ARM Serien bereit
stellen. Ein Cortex M4 wird mit aktiviertem Cache jedenfalls niemals
langsamer, als ohne Cache.
> und nicht bloß in 99,999% der Fälle
Jo mei, da greift dann halt der Prediktor 0. oder 1. Ordnung.
Den sollte man fuer solche Events natuerlich vorhalten.
Kein Grund sich ernsthaft Sorgen zu machen.
Ansonsten kann man sowas mit Monte-Carlo-Methoden auch testen.
Max. Forderung 10 us. Ich sage immer: Die harm. Schwingung, die geregelt
werden soll, muss 10 mal abgetastet werden. Damit sind wir bei 10 kHz.
In welcher Maschinenregelung in ein Piepen von 10kHz zu regeln? VG
Walter
P.S.: Hier fällt mir nur FPGA ein.
svedisk ficklampa schrieb:> Jo mei, da greift dann halt der Prediktor 0. oder 1. Ordnung.
Also im Zweifelsfall die Explosion der Anlage.
Gut, dass wir das mal geklärt hätten.
PS: Die Frage habe ich schon weiter oben gestellt.
Stefan F. schrieb:> Ohne Caches kommst du aber nicht auf hohe Taktfrequenzen. Die Flash> Speicher haben nur zweistellige MHz Zugriffsrate.
Man kann den Code der Regelschleife ja aus dem internen SRAM laufen
lassen - das geht ohne Cache und Waitstates mit voller Geschwindigkeit.
Wenn man den rechenintensiven Teil des Codes in Assembler programmiert
und möglichst alles in Registern hält, kämpfen Code und Daten nichtmal
um Buszugriffe. Ein paar DSP-Instruktionen hat der M4 ja, genau wie eine
FPU.
Bei 168 MHz und 25µs sind das 4200 Takte. Wieviele Operationen hat der
Regelalgorithmus pro Durchlauf denn als Hausnummer? Addition,
Subtraktion, Multiplikation, Division, trignonometrische Funktionen?
Hast Du mal über ein Zwei-Prozessor-System nachgedacht?
Also nix mit Dual-Core, sondern zwei "echte" Prozessoren?
Der Kommunikationsprozess(or) hat somit nichts mit dem normalen Programm
zutun und Dein fixer Grübler kann ordentlich reinhauen.
Meist ist auch das Datenvolumen zwischen den zwei Kerlen nicht
überwältigend groß.
Bei den heutigen Preisen in diesem Segment sollte das auch preislich
kein Beinbruch werden. Vor allem, wenn Du nicht jedem Teil auf
Teufel-komm-raus, Peripherie verpasst.
S. R. schrieb:> svedisk ficklampa schrieb:>> Jo mei, da greift dann halt der Prediktor 0. oder 1. Ordnung.>> Also im Zweifelsfall die Explosion der Anlage.> Gut, dass wir das mal geklärt hätten.
Da explodiert noch lange nichts.
Weil, zwar nicht ganz exakt:
> Die harm. Schwingung, die geregelt> werden soll, muss 10 mal abgetastet werden.
Da wird dann 1 von 10 Werten durch eine gute Schaetzung ersetzt.
In der Praxis waere das Verhaeltnis eher noch besser.
Kann man mit Audiosignalen vorzueglich ausprobieren, indem
man jedes N-te Sample durch ein linear geschaetztes Sample,
dass waere der Prediktor 1. Ordnung, ersetzt.
Solange N > 1000 und nicht periodisch ist.
Stefan F. schrieb:> Ein Cortex M4 wird mit aktiviertem Cache jedenfalls niemals> langsamer, als ohne Cache
Doch das wird er. Das war auch beim 8051 schon so. Im EFM8 Manual steht:
Bedingter Sprung ohne Cache 3 Zyklen und mit Cache 3-6 Zyklen. Das ist
auch logisch, weil abhängig davon, ob der Sprung ausgeführt wird oder
nicht, der Cache verworfen wird.
Stefan F. schrieb:
> Ein Cortex M4 wird mit aktiviertem Cache jedenfalls niemals> langsamer, als ohne CacheLothar schrieb:> Doch das wird er. Das war auch beim 8051 schon so. Im EFM8 Manual steht...8051 und EFM8 sind nicht Cortex M4.
Sebastian S. schrieb:> Hast Du mal über ein Zwei-Prozessor-System nachgedacht?>> Also nix mit Dual-Core, sondern zwei "echte" Prozessoren?>> Der Kommunikationsprozess(or) hat somit nichts mit dem normalen Programm> zutun und Dein fixer Grübler kann ordentlich reinhauen.> Meist ist auch das Datenvolumen zwischen den zwei Kerlen nicht> überwältigend groß.>> Bei den heutigen Preisen in diesem Segment sollte das auch preislich> kein Beinbruch werden. Vor allem, wenn Du nicht jedem Teil auf> Teufel-komm-raus, Peripherie verpasst.
Das mach ich aktuell auch: zu einem Arm-A mit Linux kommt ein Arm-M mit
FreeRtos für die Echtzeitsachen.
Eine harte Echtzeit Anforderung, (haben wir die mittlerweile ?) loest
man nicht einfach mit einem schnelleren Prozessor. Das waere ja viel zu
einfach. Und dualcore ist nicht dasselbe wie einfach & doppelt so
schnell.
Ich wuerd beim bestehenden Prozessor bleiben und den algorithmus
ueberarbeiten.
