Hallo Leute, momentan verwende ich einen STM32F4 (168MHz) für eine bestimmte Anwendung mit I2C, 2x USART, 5 PWMs,... (mit DMA unterstützung). Gleichzeitig muss ich relativ große Matrizen berechnen. Die Matrizen-Berechnungen laufen mit maximal 50Hz (ich benötige mehr als 150Hz) mittels Interrupt. Dabei ist die MCU schon ziemlich am Anschlag. Bin daher am Überlegen, ob ich die Berechnungen auf einen RaspberryPi auslagern soll und die MCUs über I2C kommunizieren lasse. Die Schnittstellen bleiben auf dem STM32F4. Lohnt sich der Aufwand, sich in ein RPI einzuarbeiten bzw. wie hoch ist der Aufwand um ein C Code (inkl. I2C Low-Level) zum Laufen zu bekommen? Kann ich die vorhandenen .c-Berechnungsfiles direkt auf den RPI übertragen? Ist der Geschwindigkeitsvorteil dementsprechend hoch (168MHz zu 700Mhz) (Floatingpoint unterstützung) auch bezüglich von komplexeren Berechnungen? Wie sieht das mit der Echtzeitfähigkeit aus, gibt es beim RPI auch Interrupts. Danke schon mal im voraus! Gruß, Toronto
Der pi ist natürlich echtzeitfähig und hat auch Interrupts. Aber nur Linux hört das schon wieder auf. Du brauchst ein Echtzeitbetriebssystem - keine Ahnung ob es das für das pi gibt. Aber wenn du schon solche fragen stellt, solltest du eher erst deinen code optimieren bevor du so einen Aufwand betreibst. Matrizenmultiplikationen lassen sich z.b. stark optimieren.
Die Matrizenberechnungen habe ich schon soweit vereinfacht und optimiert. Ich denke aber auch an zusätzliche Berechnungen (z.B. nichtlineare Regler,...), die ich später gerne implementieren möchte (mit Luft nach oben, sozusagen).
Toronto schrieb: > Hallo Leute, > > momentan verwende ich einen STM32F4 (168MHz) für eine bestimmte > Anwendung mit I2C, 2x USART, 5 PWMs,... (mit DMA unterstützung). > Gleichzeitig muss ich relativ große Matrizen berechnen. Die > Matrizen-Berechnungen laufen mit maximal 50Hz (ich benötige mehr als > 150Hz) mittels Interrupt. Dabei ist die MCU schon ziemlich am Anschlag. > Bin daher am Überlegen, ob ich die Berechnungen auf einen RaspberryPi > auslagern soll und die MCUs über I2C kommunizieren lasse. Die > Schnittstellen bleiben auf dem STM32F4. > > Lohnt sich der Aufwand, sich in ein RPI einzuarbeiten bzw. wie hoch ist > der Aufwand um ein C Code (inkl. I2C Low-Level) zum Laufen zu bekommen? Unter Linux nicht besonders schwer. http://www.mikrocontroller.net/articles/Raspberry_Pi#Der_I2C-Bus Sollten einige Beispiele zu finden sein. > Kann ich die vorhandenen .c-Berechnungsfiles direkt auf den RPI > übertragen? Wenn du sauberes C geschrieben hast sollte das kein Problem sein. > Ist der Geschwindigkeitsvorteil dementsprechend hoch (168MHz zu 700Mhz) > (Floatingpoint unterstützung) auch bezüglich von komplexeren > Berechnungen? Du wirst aufgrund des Betriebsystems einen Overhead haben, du kannst aber das Raspberry PI offiziell übertacketen (irgendwie bis 1 GHz, musst halt für die Kühlung sorgen) > Wie sieht das mit der Echtzeitfähigkeit aus, gibt es beim RPI auch > Interrupts. Im Normalfall lässt man da ein Linux laufen, da gibts Interrupt nur bei Treibern. Ansonsten musst du halt schauen was für ein OS du brauchen willst, gibt ja nicht nur Linux... Ich würds einfach mal probieren, wenn nichts läuft ausser deinem Prozess und du etwas Performancereserven hast sollte das klappen, wenn du an die grenzen gehtst ist Linux sicher das falsche, weil nicht realtime fähig. > > Danke schon mal im voraus! > > Gruß, > Toronto
Schau dir mal das sama5 xplain board von atmel an, dazu gibt es zu jeder peripherie einen treiber und bsp. Das ohne linux laeuft. Nuttx oder den cortexa8 freertos port kannst du 1:1 drauf laufen lassen. Arduino kompatible shields kannst drauf montieren, ggf. Sparst dir den f4
Andreas B. schrieb: >> Kann ich die vorhandenen .c-Berechnungsfiles direkt auf den RPI >> übertragen? > > Wenn du sauberes C geschrieben hast sollte das kein Problem sein. Bis auf den nicht zu unterschätzenden Aufwand die beiden Controller zu verbinden. >> Ist der Geschwindigkeitsvorteil dementsprechend hoch (168MHz zu 700Mhz) >> (Floatingpoint unterstützung) auch bezüglich von komplexeren >> Berechnungen? > > Du wirst aufgrund des Betriebsystems einen Overhead haben, du kannst > aber das Raspberry PI offiziell übertacketen (irgendwie bis 1 GHz, musst > halt für die Kühlung sorgen) Davon sollte man die Finger lassen. Das Raspberry Pi neigt bei Übertaktung (ohne ck) zu Beschädigungen des Dateisystems auf der SD-Karte. Ein anderes Board wäre vielleicht sinnvoller, schließlich gibt es inzwischen genug Konkurrenz - auch mit mehr Dampf (Cubieboard, BeaglBoard Black, OLinuXino; alle im gleichen Preissegment).
Toronto schrieb: > Bin daher am Überlegen, ob ich die Berechnungen auf einen RaspberryPi > auslagern soll und die MCUs über I2C kommunizieren lasse. Noch eine Anmerkung dazu: Der Raspi hat Hardwaremäßig einen Bug beim ClockStretching des I2C-Busses (d.h. er lässt das Stretching nur zu bestimmten Zeitpunkten zu). Wenn dein uC viel mit Interrupts beschäftigt ist kann er evtl. nicht immer schnell genug reagieren. Bei mir hat sich das darin geäußert, dass sich der Bus aufgehangen hat - hätte mich bald zur Weisglut getrieben.. Jetzt ist ein I2cTinyUsb (I2C <-> USB) dran, was zwar gut aber langsamer funktioniert.
wen der stm32f4 nicht ausreicht, bietet sich das Konkurenzmodell LPC4357 http://www.ebay.de/itm/NXP-LPC-LPC4357-Development-Board-LPC4357JET256-ARM-Cortex-M4-M0-Dual-Core-Kit-/251401150673?pt=LH_DefaultDomain_0&hash=item3a88ad20d1 mit 2CPUs an.
Ich denke, dass ich es mal mit einem RaspberryPi versuchen sollte. Das Preis/Leistubgsverhältnis ist einfach zu gut. Zudem gibts ja viele Dokus und Code-Schnipsel, die ich verwenden könnte (Falls nicht einer von euch so etwas schon mal geschreieben hat und mir netterweise zur Verfügung stellen würde :) )
avr schrieb: > Davon sollte man die Finger lassen. Das Raspberry Pi neigt bei > Übertaktung (ohne ck) zu Beschädigungen des Dateisystems auf der > SD-Karte. Diese Information ist längst veraltet. Mit aktueller Firmware kann mit jeder im RPi funktionierenden SD-Karte gearbeitet werden. Mein RasPi läuft seit über einem Jahr mit 950MHz. Quelle u.a.: http://elinux.org/RPiconfig#SD_card_usage_with_overclocking
So recht will mir noch nicht in den Schädel, dass es sinnvoll ist, wegen ein paar Matrizenrechnungen eine I2C Kommunikation einzuführen um die Berechnung auf einen anderen Compi auszulagern. Der ganze I2C Teil frisst dir die Performance doch wieder auf, die du durch die Auslagerung auf den Pi gewonnen hast. Ehe ich das endgültig einbaue, würde ich da mal ein paar rigorose Tests zum Thema I2C machen um abschätzen zu können, wieviel Zeit da für die Übertragung selbst drauf geht. Und dann darf man ja auch nicht vergessen, dass der Einbau der Kommunikationsroutinen ins Gesamtsystem ja auch nicht einfach nach dem Muster 'passt schon irgendwie' funktioniert. Für mich sieht die ganze Idee nach einer Variante von 'Oooch, da werfen wir einfach 2 Prozessoren auf das Problem, dann kriegen wir eine Halbierung der Rechenzeit und dann passt das schon'. Naiv gedacht und geht in der Praxis meistens schief, weil der ganze Themenkomplex 'Kommunikation und Synchronisierung' erst mal ignoriert wird und sich hinterher immer wieder als massiver Stolperstein entpuppt.
:
Bearbeitet durch User
Berechnungen in einem Interrupt ? Ist ein klares no-go. Ganz schlechter Stil.
Toronto schrieb: > momentan verwende ich einen STM32F4 (168MHz) für eine bestimmte > Anwendung mit I2C, 2x USART, 5 PWMs,... (mit DMA unterstützung). > Gleichzeitig muss ich relativ große Matrizen berechnen. Die > Matrizen-Berechnungen laufen mit maximal 50Hz (ich benötige mehr als > 150Hz) mittels Interrupt. Dabei ist die MCU schon ziemlich am Anschlag. > Bin daher am Überlegen, ob ich die Berechnungen auf einen RaspberryPi > auslagern soll und die MCUs über I2C kommunizieren lasse. Die > Schnittstellen bleiben auf dem STM32F4. Das Zauberwort dazu heißt DSP Genau für das sind DSPs gemacht. Also such dir einen vernünftigen DSP und mach keinen Schrott mit RPi oder sonst irgendwelchem Spielzeug.
132 schrieb: > Also such dir einen vernünftigen DSP > und mach keinen Schrott mit RPi oder sonst irgendwelchem Spielzeug. Als Mittelweg, lohnt aber nur für "größeres": Ti OMAP. Schneller Arm (Multicore) mit integriertem DSP, direkte Kommunikation über Shared-Memory IIRC. Problem: Bei den kleineren OMAP3 war noch ein DSP aus der TMS320 - Serie integriert, für den gab es Doku+Compiler. Bei den stärkeren OMAPs (4,5) gibts Details zum DSP nur gegen NDA...
Micha H. schrieb: > iese Information ist längst veraltet. Mit aktueller Firmware kann mit > jeder im RPi funktionierenden SD-Karte gearbeitet werden. > Mein RasPi läuft seit über einem Jahr mit 950MHz. > > Quelle u.a.: > http://elinux.org/RPiconfig#SD_card_usage_with_overclocking das wusste ich noch nicht. Meiner läuft bis auf einige Tests am Anfang und 700 Mhz. Beim Übertakten hat es damals nur wenige Tage gedauert bis man das OS neu aufsetzen durfte. Auf 900+ Mhz sollte man sich übrigens auch nicht verlassen. Bei mir wird das System schon zwischen 800 und 850 Mhz instabil. Auch mit erhöter Spannung.
>So recht will mir noch nicht in den Schädel, dass es sinnvoll ist, wegen >ein paar Matrizenrechnungen eine I2C Kommunikation einzuführen um die >Berechnung auf einen anderen Compi auszulagern Naja, das sind schon Matrizen in der Größenordnung von 23x23 (529 Elemente), wobei ich insgesamt 7 Stück davon habe, die verrechnet werden müssen. Das ist auch noch die vereinfachte Ausführung. Mit dem benötigten Berechnungszyklus (>150Hz) komme ich mit dem STM32 nicht mehr ganz hinterher, zudem müssen noch die Schnittstellen bedient werden. Außerdem hatte ich bei ein paar mehr Variablen einen Stackoverflow. Für zusätzliche Berechnungen sollte auch noch Platz sein. >Ehe ich das endgültig einbaue, würde ich da mal ein paar rigorose Tests >zum Thema I2C machen um abschätzen zu können, wieviel Zeit da für die >Übertragung selbst drauf geht Letztendlich muss ich nur ein paar wenige Bytes auf den STM32 bringen (Ergebnis der Berechnungen) und umgekehrt (Sensordaten). Auf dem STM32 läuft die I2C über den DMA Controller, da sollten keine Schwierigkeiten auftreten. >Berechnungen in einem Interrupt ? Ist ein klares no-go. Ganz schlechter >Stil. Tut mir leid, aber das ist doch totaler quatsch. Ich brauche eine konstante Abtastzeit für die Berechnungen, wo soll die denn sonst her kommen. >Das Zauberwort dazu heißt DSP Ich weiß, dass es durchaus leistungsfähigere und schnellere und sparsamere und kleinere... MCUs gibt, aber ich wollte ein weit verbreitetes Board verwenden, welches nicht meinen Kostenrahmen sprengt und reichlich Dokus und Beispiele vorhanden sind, sodass ich nicht mühsam alles von neu aufbauen muss. Bezüglich Interrupt auf dem RPI: Kann ich den RPI als I2C Slave definieren und mit dem STM32 dann zyklisch den RPI abfragen bzw. Daten senden?
avr schrieb: > Meiner läuft bis auf einige Tests am Anfang > und 700 Mhz. Beim Übertakten hat es damals nur wenige Tage gedauert bis > man das OS neu aufsetzen durfte. Auf 900+ Mhz sollte man sich übrigens > auch nicht verlassen. Bei mir wird das System schon zwischen 800 und 850 > Mhz instabil. Mach aktuelle Firmware drauf: <rpi-update> Geht vollautomatisch und anschließend hat sich das mit den Problemen beim übertakten erledigt.
Toronto schrieb: > Naja, das sind schon Matrizen in der Größenordnung von 23x23 (529 > Elemente), wobei ich insgesamt 7 Stück davon habe, die verrechnet werden > müssen. Toronto schrieb: > Letztendlich muss ich nur ein paar wenige Bytes auf den STM32 bringen > (Ergebnis der Berechnungen) und umgekehrt (Sensordaten). Bist du dir sicher, dass du die Matrizen jedesmal vollständig neu berechnen musst?
Ich habe schon einzelne Matrizen-Elemente zu null gesetzt. Das führt aber zu einem schlechteren Systemverhalten.
Toronto schrieb: > Tut mir leid, aber das ist doch totaler quatsch. Ich brauche eine > konstante Abtastzeit für die Berechnungen, wo soll die denn sonst her > kommen. Abtasten und Rechnen sind Zweierlei. Im Interrupt kannst du ein Flag setzen und der Rest hat da nichts zu suchen.
Und durch einen neuen Sensordaten-Satz müssen jeweils alle Zeilen und Spalten aller Matrizen neu berechnet/verrechnet werden? Oder machst das nur, weil ein lustiges Formelwerk das so vorzusehen scheint? Zuweilen kann man sich durch Analyse der Abhängigkeiten Teile der Berechnung sparen.
@ Toronto (Gast) >Ich habe schon einzelne Matrizen-Elemente zu null gesetzt. Das führt >aber zu einem schlechteren Systemverhalten. Wie das? Eine Multiplikation ist eine Multiplikation und dauert unabhängig von den Eingangsgrößen immer gleich lang. Ich behaupte mal, mit der "Methode des scharfen Blicks" bekommt man die Anwendung auch auf dem F4 ausreichend schnell zum Laufen. Was für Sensordaten müssen den mit 150 Hz in 23x23 Matritzen gepresst werden? Ist die Hardware-FPU WIRKLICH in Benutzung? Nicht dass aus Versehen das in Software emuliert wird. Welche Messungen bezüglich der Leistung der aktuellen Funktionen hast du gemacht?
Die Matrizen müssen bei jedem Schritt neu berechnet werden (-> Kalmanfilter mit Zustandsregler). Wie geschrieben, ich habe viele Elemente schon zu null/eins gesetzt. >Abtasten und Rechnen sind Zweierlei. Im Interrupt kannst du ein Flag >setzen und der Rest hat da nichts zu suchen. Solange ich die maximale Rechenzeit für den Interrupt nicht verletze, kann ich doch alles in den Interrupt reinschreiben. Über die Prio kann ich zudem steuern, welches Interrupt (Berechnung, Schnittstellen, ...) Vorrang hat. Danke für eure Vorschläge und Anregungen, ich wollte mich allerdings über den RPI informieren, wie einfach dieser Hand zu haben und wie schnell dieser wirklich ist.
>Wie das? Eine Multiplikation ist eine Multiplikation und dauert >unabhängig von den Eingangsgrößen immer gleich lang. Dadurch, dass einige Elemente zu null gesetzt werden, entfallen bestimmte Rechenoperationen bzw. Terme. Wenn das Element etwas über null ist, wird der Term trotzdem berechnet und nimmt dadurch Zeit in Anspruch. >Was für Sensordaten müssen den mit 150 Hz in 23x23 Matritzen gepresst >werden? Ist die Hardware-FPU WIRKLICH in Benutzung? Nicht dass aus >Versehen das in Software emuliert wird. Die FPU (hard) ist tatsächlich aktiv, sonst hätte ich keine Chance bei ca. 50Hz. Die Sensordaten umfassen hauptsächlich Beschleunigungen, Drehraten, GPS-Daten, Magnometer-Daten, Barometer und Temperatur.
@Toronto (Gast) >Dadurch, dass einige Elemente zu null gesetzt werden, entfallen >bestimmte Rechenoperationen bzw. Terme. Wenn das Element etwas über null >ist, wird der Term trotzdem berechnet und nimmt dadurch Zeit in >Anspruch. Ja und? Warum bringt das dann "schlechteres Systemverhalten" ? Meinst du deinen Regler? Oder dein Timing der Funktionen? >Die Sensordaten umfassen hauptsächlich Beschleunigungen, Drehraten, >GPS-Daten, Magnometer-Daten, Barometer und Temperatur. Klingt nach Quadrocopter & Co. GPS, Magnetometer, barometer und Temperatur muss man sicher nicht mit 150 Hz lesen und verrechnen. Bleibt der Rest. Hmm.
Toronto schrieb: > ich wollte mich allerdings > über den RPI informieren, wie einfach dieser Hand zu haben und wie > schnell dieser wirklich ist. Mit einem Ein-Kern-Linux und Echtzeitverhalten ist das so eine Sache ... Bei einem Zweikerner kannst du einen Prozess in die Realtime-Priorität schieben und bekommst da die volle Rechenleistung ohne jede Unterbrechung und der Rest vom Linux funktioniert immer noch problemlos.
Toronto schrieb: >>Das Zauberwort dazu heißt DSP > Ich weiß, dass es durchaus leistungsfähigere und schnellere und > sparsamere und kleinere... MCUs gibt, aber ich wollte ein weit > verbreitetes Board verwenden, welches nicht meinen Kostenrahmen sprengt > und reichlich Dokus und Beispiele vorhanden sind, sodass ich nicht > mühsam alles von neu aufbauen muss. Dann nimm das: http://hardkernel.com/main/main.php + 4 Cores statt einem + Cortex A9 statt ARM11 + 1.7 GHz statt 700 MHz + 2GB RAM statt 256/512k Bekommst Du hier: http://www.pollin.de/shop/suchergebnis.html?S_TEXT=odroid&log=internal fchk
Toronto schrieb: > Hallo Leute, > > momentan verwende ich einen STM32F4 (168MHz) für eine bestimmte > Anwendung mit I2C, 2x USART, 5 PWMs,... (mit DMA unterstützung). > Gleichzeitig muss ich relativ große Matrizen berechnen. Die > Matrizen-Berechnungen laufen mit maximal 50Hz (ich benötige mehr als > 150Hz) mittels Interrupt. Dabei ist die MCU schon ziemlich am Anschlag. > Bin daher am Überlegen, ob ich die Berechnungen auf einen RaspberryPi > auslagern soll und die MCUs über I2C kommunizieren lasse. Die > Schnittstellen bleiben auf dem STM32F4. Beaglebone wäre noch eine Möglichkeit, schnelle FPU, PWM ist dabei, UART mehrfach und Pruss kann Echtzeit. Hängt aber von der Anwendung ab.
Dies sind doch nur 13 Mio Instructions je Sekunde, wobei diese 4 clock dauern, also 54 clocks, dies ist 1/3 der verfuegbaren Leistung.
da die board empfehlungen hier eh querbeet laufen werf ich mal noch n fpga in den raum: http://www.heise.de/hardware-hacks/meldung/Papilio-Duo-100-Dollar-Power-Arduino-mit-FPGA-2216018.html Alternativ noch: Riotboard, Wandboard, Cubietruck, Udoo, BeagleBoneBlack, Intel Galileo(http://www.exp-tech.de/Mainboards/Arduino/Intel-Galileo.html) oder was auch immer... Und warum überhaupt I²C? Solange du den I²C-Bus nicht mindestens mit 400kbit/s betreibst würde ich uart immer vorziehen. Toronto schrieb: > Das Preis/Leistubgsverhältnis ist einfach zu gut. Nö, das täuscht. Für das Geld was du für den RPi ausgibst würd ich mir lieber noch 2-3 STM32F4-Discovery-Boards kaufen und die Berechnungen darauf verteilen..
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.