Hi, für eine Motorensteuerung (14 motoren) die ich programmieren will, frag ich mich gerade ob der STM32 F4 mit 168mhz genügend power hat. Die motoren sollen nicht geregelt werden sondern einfach nach betriebsstunden ein oder ausgeschaltet werden (viele viele vergleiche) die daten und motortemperaturen sollen erfasst und gespeichert werden bis zu 12 pt100's und vielleicht noch ein webserver um die zu visualiseren dann noch: + RS485/Modbus/Can + ethernet + USB Was meint ihr ? Gruß Sven
dann bin ich ja beruhigt :) Ich hab da momentan das FreeRTOS mit der MPU + FPU drauf laufen. War schon arbeit das zusammen laufen zu lassen. Frage ist wann merke ich eigentlich das er überlastet ist? Wenn der Systick-1ms auf einmal 2ms brauch ? ^^
Sven S. schrieb: > Frage ist wann merke ich eigentlich das er überlastet ist? Wenn Dir die Motoren um die Ohren fliegen.
Mit reichlich Warteschleifen kann man jede CPU in die Knie zwingen :-) Das FreeRTOS hat ja eine Statistikfunktion eingebaut die dir die Auslastung je Task anzeigt.
Ich berechne dauerhaft auf dem guten Stueck jeweils komplexe floating point FFTs mit 1024 Punkten von zwei Analogsignalen und ein wenig Auswertung hinten dran. Da ist er schon ein wenig mit beschaeftigt. Ich schaetze etwa 2/3 seiner Rechenzeit bei 168Mhz. Jemand aehnliche Erfahrungen/Vergleichswerte? Interessiert mich auch was da so alles geht. Von einem Projekt auf anere Anwendungen zu schliessen faellt mir bei der Komplexitaet der Hardware nicht leicht.
FFT wollt ich auch mal machen auf dem Teil. Benutzt du auch schön die DSP Library?
Ja, die von ARM. Habe testweise mal kissfft ausprobiert. Macht einen deutlich messbaren Unterschied. Habe aber keine Messwerte mehr im Kopf. BTW: die DSP Lib von ARM, zumindest die Teile die ich davon verwende, lassen sich auch auf dem Desktop kompilieren und somit fuer Unit Tests und Experimente ohne Hardware aber mit identischer Software nutzen. Fand ich klasse! ;-)
>Ich schaetze etwa 2/3 seiner Rechenzeit bei 168Mhz.
Nicht schätzen, messen! Setz vor deiner FFT einen Ausgangspin
auf 1. Wenn du fertig bist auf 0. Osci dran und du weisst
wie lange es dauert. Woher soll hier jemand wissen wie lange
deine FFT dauert?
holger schrieb: >>Ich schaetze etwa 2/3 seiner Rechenzeit bei 168Mhz. > > Nicht schätzen, messen! Setz vor deiner FFT einen Ausgangspin > auf 1. Wenn du fertig bist auf 0. Osci dran und du weisst > wie lange es dauert. Woher soll hier jemand wissen wie lange > deine FFT dauert? So hab ich das auch gemacht. Aber ich habe hier im Moment weder Hardware, Software noch die Aufzeichnungen dazu vorliegen.
>So hab ich das auch gemacht. Aber ich habe hier im Moment weder >Hardware, Software noch die Aufzeichnungen dazu vorliegen. Ja, und jetzt was? Äpfel mit Birnen vergleichen?
holger schrieb: >>So hab ich das auch gemacht. Aber ich habe hier im Moment weder >>Hardware, Software noch die Aufzeichnungen dazu vorliegen. > > Ja, und jetzt was? Äpfel mit Birnen vergleichen? Mir glauben das es bei mir ungefaehr in dem Bereich lag oder selbst ausprobieren. Ich kann es Momentan einfach nicht nachmessen. Faende ich als Leser auch unbefriedigend aber so ist leider.
>Mir glauben das es bei mir ungefaehr in dem Bereich lag oder selbst >ausprobieren. Fein. Wie lange dauert denn das sampeln der Werte? Wenn ich ohne sampeln eine FFT dauernd berechne sind 100% CPU Zeit mit der FFT belegt.
((1s) / 20000) * 1024 = 51.2 ms Das ganze dann abwechselnd in zwei Puffer damit ohne Luecken im Signalverlauf analysiert werden kann.
>>Ich schaetze etwa 2/3 seiner Rechenzeit bei 168Mhz. >Nicht schätzen, messen! Und die etlich möglichen Waitstates (auch wenn er "Accelerator" hat) nicht vergessen!
Ich habe gerade ein paar Tests durchgeführt. Unter FreeRTOS macht mein STM32F4 eine 2048 Punkte FFT mit Betrgsbildung in etwa 7ms. Für eine 512 Punkte Real-FFT mit 512 komplexen Ausgangswerten braucht er noch nicht mal 2ms. Gar nicht so übel!
>Was macht Ihr so mit dem CCM ?
Gute Frage. DMA tauglich ist es jedenfalls nicht.
Ausführbarer Code funktioniert auch nicht. Bis jetzt nehm ichs nur als Heap für FreeRTOS und als Stack. Ich dacht ihr hättest da noch Ideen.
Der CCM ist am Instruction Bus angebunden, wenn du also Datenintensive Berechnungn durchführst kannst du die Verarbeitung der Daten beschleunigen indem du sie in den CCM legst. Der Kern muss dann beim Zugriff nicht auf eine DMA oder andere Peripherie warten. Code im CCM geht nicht, ich dachte das wäre einer der großen Vorteile des CCM-RAM.
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.