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.
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.
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?
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.
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..
