Hallo, ich habe jetzt doch einen ganz überraschenden Test mit dem neuen Controller von ST gemacht. Da ich den Angegebenen Werten, die aus den Marketing Abteilungen der Hersteller kommen nie ganz traue, muss man selber testen. Die Aufgabe war eine Hilberttransformation für die Aufbereitung der I und Q Signale bei einer Samplingfrequenz von 32KHz und einer Signalbreite von 32 Bit. Der Code reinrassig optimiert für beide Controller in Assembler geschrieben. FIR-Filter mit 127 Taps. ARM9 = AT91SAM9G10 mit 264MHz Clock und 132MHz SDRAM. CM4 = STM32F429 mit standard 168MHz Clock. Das Testergebniss war für mich zwar nicht ganz unerwartet, hat mich aber dennoch sehr erfreut. Der CM4 schafte die Berechnung 6,41 mal pro Sekunde zu durchlaufen. Also 6.41 mal schneller als Echtzeit. Der ARM9 mit allen seinen eingeschalteten Turboladern I-Cache, D-Cache und MMU mit 6,944 mal pro Sekunde. Dabei ist es beim D-Cache unintressant aus welchem RAM. Mit abgeschaltetem D-Cache aus dem internen RAM waren es nur noch 3.3 mal pro Sekunde. Hopla macht der Cache nur die Sache schnell. Aber der CM4 glänzt hier ganz gut würde ich mal behaupten, denn Cache ist hier eher Fehlanzeige. Es muss aber noch gesagt sein, das auf dem ARM9 noch ein TFT-Display angesteuert wurde mit 480x272 mit einem Datendurchsatz von ca.7,8 MByte pro Sekunde. Das fällt aber auch kaum ins Gewicht da ja der D-Cache und I-Cache aktiv ist. Wenn der Speed des CM4 auch bei Random Access auf das interne SRAM so hoch bleibt, finde ich, dass er dem ARM9 überlegen ist. Der FIR-Filter wurde übrigens hauptsächlich mit dem SMLAL Befehl aufgebaut. Also 32 Bit mal 32 Bit = 64 Bit + 64 Bit Summing Register. D.h.alle Filter koeffizienten sind mit einer Genauigkeit von 32 Bit angegeben. Die Audio Daten von der Soundkarte mit 24 Bit. Hat jemand andere Erfahrungen mit dem STM32F429 gemacht? Gruß Sascha
Sascha schrieb: >> Also 6.41 mal schneller als Echtzeit Ah ja... harte oder weiche Echtzeit? Was Echtzeit (unabhängig von hart oder weich) ist und was nicht, wird durch die Anforderungen festgelegt. Echtzeit kann 100ms, 1 Tag oder 1 Jahr sein, je nach Anforderung.
Sascha schrieb: > Wenn der Speed des CM4 auch bei Random Access auf das interne SRAM so > hoch bleibt, finde ich, dass er dem ARM9 überlegen ist. Das interne RAM des CM4 arbeitet ohne Waitstates, ein Cache ist dafür also nicht erforderlich. Sequentieller Codezugriff aus dem Flash kann aber bei hohem Anteil von Befehlen mit 32-Bit Codierung etwas ausgebremst werden.
Kaj schrieb: > Was Echtzeit (unabhängig von hart oder weich) ist und was nicht, wird > durch die Anforderungen festgelegt. In diesem Zusammenhang dürfte "Echtzeit" für die Datenrate stehen, in der Daten anfallen.
Also ich hab LUA auf einem AT91SAM9G20/400MHz installiert und auf einem STM32F407 mit 168MHz. Im LUA habe ich dann ein kleines Mandelbrotprogramm geschrieben und die Zeiten gemessen. Der AT91SAM9G20 hat ja keine FPU und der STM32F407 hat eine. Beide haben mit 32 Bit floats gerechnet. Der STM32 war dabei fast so schnell wie der AT91SAM9G20. Das fand ich schon erstaunlich, da ja ziemlich viel Rechenzeit im LUA Interpreter verbraucht wird, wo die FPU keine Rolle spielt.
Hallo ..., ist bei deinem Test mit LUA der STM32F407 mit externem SDRAM gelaufen? Ich habe keine Ahnung wie schnell das SDRAM am STM32F4xx ist, deshalb interessiert mich das. Vor allem wie hoch kann der ST das SDRAM takten. Ja eine Hardware Floating Point a la CM4F ist eine ganz feine Sache, lässt sich sogar super einfach auf Assemblerebene ansprechen. Werde die Tage mal meinen Test auch mit der FPU machen. Vermute aber es wird langsamer ausfallen wenn man die Zykluszahlen der Befehle betrachtet. Die Genauigkeit ist ja auch nicht besser in Floating Point als mit 32 Bit Integer vor allem wenn man mit einem 64 Bit Zwischenwert rechnet. Aber die FPU ist halt für wissenschaftliche Rechnungen genial und vor allem sehr schnell anzuwenden. Gruß Sascha Mein Fazit, der CM4F lässt so manchen DSP Prozessor in Vergessenheit geraten.
Sascha schrieb: > STM32F407 mit externem SDRAM Hähhh gibts leider nicht.. Oder meinst du den STM32F42/37?
Hallo, O.k. SDRAM gibts nicht, habe ich übersehen. Aber ich habe jetzt den Test mit der FPU gemacht. Die Hilbert Transformation braucht mit der FPU schon etwas mehr Zeit. Liegt aber hauptsächlich daran, dass beim FPU Befehl um 32 Bit aus dem Speicher zu laden kein Adress Increment geht. Deshalb braucht man halt ein paar Befehle mehr. Der Faktor liegt dann bei 4.3 mal pro Sekunde. Gie Genauigkeit ist auch etwas schlechter, aber das ist ja klar, sind ja auch nur 23 Bit in der Mantisse. Gruß Sascha
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.