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.
Du kannst Dir ja mal die i.MX RT von NXP angucken. Nächstes Jahr (vermutlich zur Embedded World?) kommt da ein 1GHz Cortex-M7: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i.mx-rt-series/i.mx-rt1170-crossover-mcu-family-first-ghz-mcu-with-arm-cortex-m7-and-cortex-m4-cores:i.MX-RT1170
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
Manuel schrieb: > Teuer wäre jetzt nicht so das Problem ;) > > Die TI Sitara-Reihe sieht recht vielversprechend aus Wenn Geld keine Rolle spielt, dann teste dieses Board mit RISC OS Betriebssystem und steuere die Caches manuell. Damit ist Bare-Metal Performance möglich. RISC OS läuft nur auf einem Kern: Der zweite Kern und die DSPs sind also noch frei und können asynchron laufen: http://www.ti.com/tool/ELESAR-3P-SITARA-SOMS https://www.riscosopen.org/wiki/documentation/show/OS_MMUControl%202
> 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.
Die
> - 2 C67xx-Kerne für DSP
haben aber deutlich mehr Bumms. Wenn man es braucht.
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.
> In welcher Maschinenregelung in ein Piepen von 10kHz zu regeln?
Ultrazentrifugen.
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 Cache Lothar 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.
Stefan F. schrieb: > 8051 und EFM8 sind nicht Cortex M4 War doch nur ein Beispiel. Bei den Cortex-M ist die Cache-Problematik noch größer, deswegen gibt es die ganzen Assembler-Befehle zum Cache-Handling z.B. http://www.keil.com/support/docs/3928.htm
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.