Guten Tag, Ich habe ein STM32F429-Discovery Board, an dem über SPI ein LIS3DH Beschleunigungssensor von ST angeschlossen ist. Mittels einem Timer Interrupt, der alle 200µs auslöst, wird der aktuelle Beschleunigungswert für alle drei Achsen periodisch abgefragt und in ein 3*2048Byte Array gespeichert. Da 200µs eine recht knappe Zeitspanne ist, ist der Prozessor dementsprechend auch ausgelastet. Nun muss der Prozessor noch das Display auf dem Board ansteuern, die gemessenen Daten verarbeiten und in Zukunft noch Werte von am besten 2-3 weiteren Sensoren einlesen können. Jetzt zu meiner Frage: Wäre es in dem Fall bezüglich der Prozessorauslastung von Vorteil, wenn man den SPI über DMA laufen lässt oder bringt das in diesem Fall nichts, weil anstatt großer Datenmengen immer nur 16Bit auf einmal hin- und her geschickt werden?
Gianluca P. schrieb: > Da 200µs eine recht knappe Zeitspanne ist, ist der Prozessor > dementsprechend auch ausgelastet. Dann machst du irgendwas falsch wenn der bei so ner Lappalie bereits ausgelastet ist. 200us sind ne halbe Ewigkeit für das Ding. Wie hoch ist der SPI-Takt? DMA bringt sicher etwas - du musst nicht warten bis die Übertragung abgeschlossen ist.
Das "ausgelastet" war auch eher relativ gemeint mit dem Hinblick, dass das Teil in Zukunft mehrere Sensoren abtasten soll und der Prozessor nebenbei auch noch zu schaffen hat. Ich hatte mal gelesen, dass der erst dann DMA von Vorteil ist, wenn große Datenmengen auf einmal übertragen werden, bsp. beim Speichern auf SD-Karte o.ä., deswegen die Frage. Der APB1 Takt müsste bei 42MHz liegen, mit einem Prescaler von 8 wäre ich dann bei 5,25MHz...
>Ich hatte mal gelesen, dass der erst dann DMA von Vorteil ist, wenn >große Datenmengen auf einmal übertragen werden, bsp. beim Speichern auf >SD-Karte o.ä., deswegen die Frage. Du solltest den Aufwand, einen DMA-Transfer aufzusetzen mit dem Aufwand, einen Wert vom/zum SPI zu transferieren vergleichen. Wenn Du beispielsweise zur Programmierung pro Transfer 20 Bytes in den DMA Controller schreiben musst im Vergleich zu einem oder mehreren Bytes aus dem SPI Datenregister zu lesen, ist das ein Minusgeschäft. Aber wie immer kommt es auf den Einzelfall an... Man kann das mit dem DMA mehr oder weniger geschickt machen.
Gianluca P. schrieb: > Guten Tag, > Ich habe ein STM32F429-Discovery Board, an dem über SPI ein LIS3DH > Beschleunigungssensor von ST angeschlossen ist. > Mittels einem Timer Interrupt, der alle 200µs auslöst, wird der aktuelle > Beschleunigungswert für alle drei Achsen periodisch abgefragt und in ein > 3*2048Byte Array gespeichert. > Da 200µs eine recht knappe Zeitspanne ist, ist der Prozessor > dementsprechend auch ausgelastet. Nun muss der Prozessor noch das > Display auf dem Board ansteuern, die gemessenen Daten verarbeiten und in > Zukunft noch Werte von am besten 2-3 weiteren Sensoren einlesen können. > > Jetzt zu meiner Frage: Wäre es in dem Fall bezüglich der > Prozessorauslastung von Vorteil, wenn man den SPI über DMA laufen lässt > oder bringt das in diesem Fall nichts, weil anstatt großer Datenmengen > immer nur 16Bit auf einmal hin- und her geschickt werden? Für dich ist es ganz klar die DMA muss sein. Du hast ja keine 2 bis 3 bytes sondern 3*2048Byte array. Die DMA auch am besten triggern oder manuell starten, da sonst der BUS zu ist. Ich benutze am µC immer die DMA, solange die errata es zulässt! Auch wenn ich, z.B am i2c bus immer warten muss. Beim stm32 kann man sogar die GPIO´s mit DMA befeuern. Leider aber nur die komplette Bank (GPIOx). 200µs erscheinen mir etwas zu schnell abgetastet zu sein. Fast bei allen instabilen Strecken, die ich jetzt geregelt habe, reichen 1-20ms dicke aus. Ich kenne jetzt dein Projekt nicht genau. Aber du musst versuchen den µC "Echtzeit" beizubrigen. Dabei gehst du alle TASK durch die du hast z.B: -0,2ms für LIS3DH -3ms LCD -0,2ms weitere Aufgaben macht zusammen ca. 5ms. Erstellst einen sysTick timer interrupt, der jede ms eine volatile var summiert und bei 5ms eine volatile bool var = true setzt... mfg
dofgih schrieb: > Aber wie immer kommt es auf den Einzelfall an... > Man kann das mit dem DMA mehr oder weniger geschickt machen. Ganz genau so seh ich das auch. Ich führe mir auch immer vor Augen, ob die CPU im Einzelfall warten muss. Ist dies der Fall, nehme ich den DMA.
aSma>> schrieb: > Für dich ist es ganz klar die DMA muss sein. Du hast ja keine 2 bis 3 > bytes sondern 3*2048Byte array. Die DMA auch am besten triggern oder > manuell starten, da sonst der BUS zu ist. Hm, ich frage die 3*2048Byte ja nicht auf einmal ab, sondern es werden alle 200µs 3 Register über den SPI ausgelesen, wo dann jedes mal 1 Byte zurück kommt. Sprich 3 mal hintereinander das:
1 | while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_TXE) == RESET); |
2 | SPI_I2S_SendData(SPI2, wert); |
3 | while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET); |
4 | ret_wert=SPI_I2S_ReceiveData(SPI2); |
So wie ich das jetzt verstanden habe, kann man bei der Verwendung des DMA auf das
1 | while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET); |
verzichten und währenddessen das restliche Programm laufen lassen. Richtig? Kann man auch alle 3 Register-Adressen, die abgefragt werden in den DMA-TX-Buffer schreiben und bekommt dann die 3 gewünschten Werte im RX-Buffer zurück? Oder um es mal anders zu formulieren: Ich verstehe das Prinzip dahinter noch nicht zu 100%. Werden zuerst alle Bytes vom TX-Buffer direkt hintereinander gesendet und dann alle Bytes für den RX-Buffer empfangen oder wird zuerst das erste Byte vom TX-Buffer versendet, daraufhin das erste Byte empfangen, danach das zweite Byte versendet und das zweite empfangen usw.? > 200µs erscheinen mir etwas zu schnell abgetastet zu sein. Fast bei allen > instabilen Strecken, die ich jetzt geregelt habe, reichen 1-20ms dicke > aus. 200µs, also 5kHz muss es nicht sein, 2kHz würden theoretisch schon genügen. Es geht darum, Vibrationen zu messen. Clemens L. schrieb: > Benutzt du überhaupt den SPI-Interrupt? Nein, ich arbeite (noch) ohne SPI-Interrupt.
Hi, Also beim SPI den Interrupt verwenden wäre schon einmal von Vorteil, dann brauchst Du die (busy-) Warteschleife nicht mehr und kannst Dein Programm darüber informieren lassen wenn die Daten da sind. Zum anderen: Der DMA wird bei Dir wahrscheinlich Sinn machen, da Du den SPI nur mit 5.25MHz betreibst. Den DMA Kontroller für einen Transfer aufsetzen (Adressen setzen, Bytes setzen, go) kannst Du aber mit "fullspeed". Zum dritten, für die Speed Fans (wobei das bei dieser Geschwindigkeit keinen Sinn mehr macht) hat der STM32 verschiedene Speicherbereiche, so dass man DMA Puffer für die Blockweise Übertragung auch so legen kann, dass kein Konflikt beim Speicherzugriff mit der CPU mehr auftritt. Gruß Martin
Gianluca P. schrieb: > und währenddessen das restliche Programm laufen lassen. > Richtig? Wie soll bitte "das restliche Programm" weiterlaufen wenn DMA läuft? Haben die STMs zwei unabhängige Busse? Für meine Begriffe steht der Prozessor solange DMA läuft da der Datenaustausch vom Speicher mit der SPI Maschine stattfindet. Allerhöchstens könnte Code im Flash abgearbeitet werden der keinen Zugriff auf das RAM erfordert. Der zeitliche Gewinn mit DMA gegenüber programmierten I/O ist nur dass weniger Register Handshake ausgeübt wird (was natürlich bei grösseren Datenmengen immer mehr ins Gewicht fällt).
@ Gianluca P. (gpnt) >Hm, ich frage die 3*2048Byte ja nicht auf einmal ab, sondern es werden >alle 200µs 3 Register über den SPI ausgelesen, wo dann jedes mal 1 Byte >zurück kommt. Sprich 3 mal hintereinander das: Schon klar. >while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_TXE) == RESET); >SPI_I2S_SendData(SPI2, wert); >while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET); >ret_wert=SPI_I2S_ReceiveData(SPI2); Das dauert gerade mal so lange, wie deine SPI die Daten transportiert. Bei 8 MHz sind gerade mal 6us. >So wie ich das jetzt verstanden habe, kann man bei der Verwendung des >DMA auf das >while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET); >verzichten und währenddessen das restliche Programm laufen lassen. >Richtig? Ja. Kann man machen, lohnt sich aber kaum. Ausserdem kannst du die Ergebnisse erst im nächsten Timerinterrupt weiterverarbeiten. >Kann man auch alle 3 Register-Adressen, die abgefragt werden in den >DMA-TX-Buffer schreiben und bekommt dann die 3 gewünschten Werte im >RX-Buffer zurück? Nein, sooo einfach ist es nicht. DMA ist relativ dumm, dass kann nur Blöcke von Daten von A nach B kopieren. DU musst aber für deinen Tranfer von einem Byte zuerst ein Steuerbyte senden und dann ein Dummy-Byte, wobei der dabei empfangene Wert deine gesuchten Daten sind. OK, das ist noch einfach, das kann DMA auch, WENN man zwischendurch nicht das CS-Signal deines SPI-Baustein umschalten muss. >Ich verstehe das Prinzip dahinter noch nicht zu 100%. Werden zuerst alle >Bytes vom TX-Buffer direkt hintereinander gesendet und dann alle Bytes >für den RX-Buffer empfangen Nein, das passier bei SPI immer parallel! >oder wird zuerst das erste Byte vom >TX-Buffer versendet, daraufhin das erste Byte empfangen, danach das >zweite Byte versendet und das zweite empfangen usw.? Fast. Mit jedem Takt der SPI wird ein Bit gesendet und gleichzeitig eins empfangen. Nach 8 Takten ist das erste Byte gesendet und auch das 1. Byte empfangen worden. >> Benutzt du überhaupt den SPI-Interrupt? >Nein, ich arbeite (noch) ohne SPI-Interrupt. SPI wird in den meisten Fällen relativ schnell getaktet, sodaß es sich kaum lohnt, dort mit Intrrupts zu arbeiten. Nur wenn das Verhältnis von CPU-Takt zu SPI-Takt sehr hoch wird, lohnt sich das wieder. Ich sag mal wenn deine CPU nicht 10x schneller als den SPI getaktet ist, lohnt sich ein Interrupt nicht. Denn der braucht auch Zeit zum Anspringen und Rückspringen und Register sichern. Je größer die CPU (dicker 32 Bitter), umso mehr Takte werden dafür benötigt.
@Frickelfritze (Gast) >> und währenddessen das restliche Programm laufen lassen. >> Richtig? >Wie soll bitte "das restliche Programm" weiterlaufen wenn >DMA läuft? Ganz normal. >Haben die STMs zwei unabhängige Busse? Haben sie. Und eine schöne Schaltmatrix für alle Busteilnehmer. > Für meine >Begriffe steht der Prozessor solange DMA läuft da der >Datenaustausch vom Speicher mit der SPI Maschine stattfindet. Irrtum. Das würde das ganze Konzept von DMA (<- anclicken!) ad absurdum führen. >Allerhöchstens könnte Code im Flash abgearbeitet werden der >keinen Zugriff auf das RAM erfordert. Nö. Schau mal in ein Datenblatt eines STM32, der F0 reicht, selbst der hat die Busmatrix und 5 DMS-Kanäle. >Der zeitliche Gewinn mit DMA gegenüber programmierten I/O >ist nur dass weniger Register Handshake ausgeübt wird (was >natürlich bei grösseren Datenmengen immer mehr ins Gewicht >fällt). Falsch.
Frickelfritze schrieb: > Wie soll bitte "das restliche Programm" weiterlaufen wenn > DMA läuft? Haben die STMs zwei unabhängige Busse? Ja genau DAS weiß ich ja nicht. Falk B. schrieb: > Das dauert gerade mal so lange, wie deine SPI die Daten transportiert. > Bei 8 MHz sind gerade mal 6us. Okay, ich glaube nach deinem Post habe ich das mit dem SPI wirklich verstanden. Danke. Wenn das wirklich nur 6µs sind, dann lohnt sich das mit dem DMA oder SPI-Interrupt wahrscheinlich eher weniger
Falk B. schrieb: > Irrtum. Das würde das ganze Konzept von DMA (<- anclicken!) ad > absurdum führen. Dann erklär mal bitte wie die DMA Maschine lesend auf das RAM zugreifen kann während der Prozessor schreibend auf das gleiche RAM zugreift. Da hilft keine Busmatrix. Vielleicht noch ein Cache wenn gerade die richtigen Daten an der richtigen Stelle "gepuffert" werden.
Gianluca P. schrieb: > Kann man auch alle 3 Register-Adressen, die abgefragt werden in den > DMA-TX-Buffer schreiben und bekommt dann die 3 gewünschten Werte im > RX-Buffer zurück? > Oder um es mal anders zu formulieren: > Ich verstehe das Prinzip dahinter noch nicht zu 100%. Werden zuerst alle > Bytes vom TX-Buffer direkt hintereinander gesendet und dann alle Bytes > für den RX-Buffer empfangen oder wird zuerst das erste Byte vom > TX-Buffer versendet, daraufhin das erste Byte empfangen, danach das > zweite Byte versendet und das zweite empfangen usw.? Ja, du willst also das wir für dich die Datenblätter lesen... Du musst dein Bussystem verstehen. Wie man es anspricht usw. Normalerweise ist es gewünscht so vorzugehen. >Es geht darum, Vibrationen zu messen. Gut zu wissen, was du vorhast. Jetzt kann man dir Helfen. Mit einen Beschleunigungsmesser (LIS3DH)? Dazu brauchst du ein Mikrofon. Habe ich auch schon mal mittels FFT (Fourier-Reihe) gemacht. Du musst nur bedenken, wenn man 20Hz misst, das sind dann 50ms. Und wie du schon sagst 1khz und drüber sind kaum Vibrationen wahrnehmbar. Du brauchst halt das Nyquist Theorem. Jetzt verstehe ich auch warum du so ein großes Array brauchst. Aufjedenfall kannst du mittels einen Timerinterupt die SPI starten (DMA_TX). In der Interupt routine triggerst du dein ADC Modul oder halt die den SPI Bus. Wenn dein DMA Array voll ist, dann startet ein DMA_RX Intrupt. Natürlich kann man auch die DMA Daten in ein anderes Array kopieren. Ich kenne die Datenblätter nicht von LIS3DH. Diese Methode hat den riesen Vorteil, dass du kaum auf die Daten warten musst, sondern in der Interupt Routine alles schnell erledigt wird. Die Abtastzeit von dir wird immer eingehalten!!! Nichtsdestotrotz, du musst ein wenig Kopfrechnen: 5Mhz und 6000bytes macht 1.2ms, lcd ansprechen macht ca. 3ms (k.A. nur angenommen). Wenn es dir ausreichend erscheint, dann lasse die DMA weg und mache das mit normalen Interrupt. Nicht zu vergesen ist, dass während du den Bildschirm anspricht, dann wird nicht gemessen und ausgewertet. Denke drüber nach. Wie gesagt: >Aber du musst versuchen den µC "Echtzeit" beizubrigen. Versuche das zu verstehen und umzuseten!!! Wenn du sagst 2khz ist deine Abtastzeit, dann versuche das umzusetzten. Leider braucht: printf oder lcd Ausgabe immer am meisten Zeit. Du musst alles durch interrupts hinkriegen. Deinen SPI Bus takt musst du erhöhen. Oder du versuchst es erstmal mit 500hz usw. mfg
@ Frickelfritze (Gast) >> Irrtum. Das würde das ganze Konzept von DMA (<- anclicken!) ad >> absurdum führen. >Dann erklär mal bitte wie die DMA Maschine lesend auf das RAM >zugreifen kann während der Prozessor schreibend auf das gleiche >RAM zugreift. Da hilft keine Busmatrix. Aber sicher. Die beiden Zugriffe werden zeitlich versetzt ausgeführt. In welcher Reihenfolge und Priorität ist eine andere Frage, da gibt es verschiedene Lösungen. Die CPU wird sicher NICHT dauerhaft ohne Pause auf den RAM zugreifen und diesen blockieren. Zumal CPU-Zugriffe meist die niedrigste Priorität haben ;-) > Vielleicht noch ein >Cache wenn gerade die richtigen Daten an der richtigen Stelle >"gepuffert" werden. Schon mal richtig. Die DMA hat auch einen Cache, mal größer, mal kleiner, um Zugriffe bzw. Wartezeiten der Busmatrix ausgleichen zu können.
Sry, Schwachsinn. Bei 20Hz Frequenz hast man 50ms und bei 10Hz 0,1 ms. Das ist deine Echtzeit Periode: nämlich z.B. 0,1ms. In dieser Zeit musst du alle z.B. 1khz werde Abtasten, verarbeiten, ausgeben (EVA Prinzip). mfg
Falk B. schrieb: > Die CPU wird sicher NICHT dauerhaft ohne Pause auf den RAM zugreifen und > diesen blockieren. Zumal CPU-Zugriffe meist die niedrigste Priorität > haben ;-) Da hätte ich mal geschätzt dass die DMA Maschine - wenn SPI bedient werden soll - eb bloc das RAM sperrt bzw für freien Zugriff behindert solange bis der SPI Transfer beendet ist. Das meine ich mit nicht gleichzeitig. Dass ein gewisses Interleaving stattfinden mag das kann sein, ist aber dann effektiv (vom Zeitgewinn/verlust) das Gleiche als wenn ich DMA und Prozessorzugriff blockweise nacheinander ausführe. Das bedeuted für mich dass ein "Gleichzeitig" im Sinne von Zeitgewinn und Performance-Verbesserung nicht stattfindet da eben doch nicht zwei "Leute" wirklich gleichzeitig an einer Datenquelle arbeiten könen.
Angehängte Dateien:
-
i2c.png
510 KB -
i2c_DMA_interupt.png
480 KB
Servus, hier sieht man die Vorteile von DMA+Interupt: http://letanphuc.net/2014/06/stm32-mpu6050-dma-i2c/ mfg
aSma>> schrieb: > Ja, du willst also das wir für dich die Datenblätter lesen... > Du musst dein Bussystem verstehen. Wie man es anspricht usw. > Normalerweise ist es gewünscht so vorzugehen. Nö, hat sich nur angeboten kurz nachzufragen, da ich eh schon nen Thread eröffnet habe. Muss ja keiner Antworten ;) > Mit einen Beschleunigungsmesser (LIS3DH)? Dazu brauchst du ein Mikrofon. Bitte keine Diskussion über das Wie und Warum. Das hat schon seine Richtigkeit mit dem Sensor. Man muss auch hier immer den Einzelfall betrachten und das wurde alles bereits getan.
@ Frickelfritze (Gast) >> Die CPU wird sicher NICHT dauerhaft ohne Pause auf den RAM zugreifen und >> diesen blockieren. Zumal CPU-Zugriffe meist die niedrigste Priorität >> haben ;-) >Da hätte ich mal geschätzt dass die DMA Maschine - wenn SPI bedient >werden soll - eb bloc das RAM sperrt bzw für freien Zugriff behindert >solange bis der SPI Transfer beendet ist. Das tut sie nicht. DMA holt sich ein-N Bytes (Burstlänge) und schaufelt die dann je nach Geschwindigkeit des Ziels raus. Also wird der RAM nur für N Takte/Zugriffe blockiert. > Das meine ich mit nicht >gleichzeitig. Dass ein gewisses Interleaving stattfinden mag das kann >sein, ist aber dann effektiv (vom Zeitgewinn/verlust) das Gleiche >als wenn ich DMA und Prozessorzugriff blockweise nacheinander ausführe. Nö, es gibt einen deutlichen Zeitgewinn, vor allem bei hohen Datenvolumen. >Das bedeuted für mich dass ein "Gleichzeitig" im Sinne von Zeitgewinn >und Performance-Verbesserung nicht stattfindet da eben doch nicht >zwei "Leute" wirklich gleichzeitig an einer Datenquelle arbeiten könen. Doch, das tun sie. Eben weil der Bus zum Speicher effektiv mehr Bandbreite hat als sie die CPU im Normalfall benötigt. Und selbst wenn es nicht so wäre, kann DMA Daten schneller kopieren als die meisten einfachen/mittleren CPUs, die keinen Cache haben. Das war schon zu seeligen Amiga-Zeiten so (der Blitter läßt grüßen).
Frickelfritze schrieb: > Dann erklär mal bitte wie die DMA Maschine lesend auf das RAM > zugreifen kann während der Prozessor schreibend auf das gleiche > RAM zugreift. Wenn so etwas passiert, dann ist das ein Software-Design-Error. Denn das Ergebnis ist undefiniert, je nachdem, wer von beiden der erste ist. Natürlich spart ein DMA-Zugriff CPU-Zeit, denn die Alternativen sind Polling oder ein Interrupt nach jedem Datentransfer. Beim DMA fällt dagegen nur CPU-Zeit für das Starten des DMA und das Notify an, der Zeitgewinn wird dabei mit wachsenden DMA-Datenblöcken größer. Der DAM-Speicherzugriff bremst dagegen wie von Falk bereits gesagt die CPU in der Regel nicht aus, da die CPU den Datenbus i.d.R. nie 100%ig auslastet. Gruß, Stefan
@ aSma>> (Gast) >hier sieht man die Vorteile von DMA+Interupt: >http://letanphuc.net/2014/06/stm32-mpu6050-dma-i2c/ Naja, I2C ist ja nun recht lahm, da fällt der Gewinn leicht ;-) Im Prinzip kann man sich DMA wie einen größeren FIFO am UART vorstellen. Man schaufelt einmal alle Daten mit maximaler CPU-Geschwindigkeit rein (Daten erzeugen per CPU) und die DMA + Zielmodul, hier SPI, schaufeln die Daten je nach Geschwindigkeit raus. Beim Normalen UART hat man meist nur 1-2 Bytes FIFO in Hardware, durch DMA kann man quasi den gesamten RAM als FIFO nutzen. Und der Datentransfer läuft ohne CPU Arbeit und je nach Prozessor und DMA-Anwendung wird die CPU dadurch nicht nennenswert verlangsamt.
aSma>> schrieb: > Mit einen Beschleunigungsmesser (LIS3DH)? Dazu brauchst du ein Mikrofon. Und falls du Sänger bist, brauchst du einen Beschleunigungssensor!
Reginald L. schrieb: > aSma>> schrieb: >> Mit einen Beschleunigungsmesser (LIS3DH)? Dazu brauchst du ein Mikrofon. > Und falls du Sänger bist, brauchst du einen Beschleunigungssensor! Lasse mich gerne Aufklären mit den Beschleunigungssensor. Wie man damit singen kann. Gianluca P. schrieb: > Bitte keine Diskussion über das Wie und Warum. Das hat schon seine > Richtigkeit mit dem Sensor. Man muss auch hier immer den Einzelfall > betrachten und das wurde alles bereits getan. Aber der TE will ja keine Diskussionen. Deshalb bin ich hier raus.
Angehängte Dateien:
-
94-4_47_0.jpg
61 KB
aSma>> schrieb: > Lasse mich gerne Aufklären mit den Beschleunigungssensor. Wie man damit > singen kann. Ja nee, du hast schon recht.
@Reginald Leonczuk Mit einen Mikrofon kann man super Vibrationen messen. Vielleicht geht es mit einen Beschleunigungssensor auch noch besser. K.A. ABER ich erkenne nicht aus deinen Komentar, ob du überhaupt Wissen dazu hast. Vielleicht bist du nur so ne in der Mülltone singende Kakerlake. Der TE kann machen, wie er will. Ich habe nur ein Tipp gegeben wie ich das mal erfolgreich gemacht habe. Dabei sollten bei mir nur niederfrequente Frequenzen bestimmt werden. Hohe Frequenzen sahen noch besser aus.
aSma>> schrieb: > Mit einen Mikrofon kann man super Vibrationen messen. Vielleicht geht es > mit einen Beschleunigungssensor auch noch besser. K.A. Na dann mist mal weiter mit deinen Mikrofonen. aSma>> schrieb: > ABER ich erkenne nicht aus deinen Komentar, ob du überhaupt Wissen dazu > hast. Ich hab schon so ziemlich mit allem Vibrationen gemessen. Mit Lautsprechern, Piezopiepsern, billigen und teuren Mems-Sensoren und Industrie-Beschleunigungsaufnehmern. aSma>> schrieb: > Vielleicht bist du nur so ne in der Mülltone singende Kakerlake. ...Mülltonne schreibt man mit zwei n's.
Reginald L. schrieb: >> Vielleicht bist du nur so ne in der Mülltone singende Kakerlake. > ...Mülltonne schreibt man mit zwei n's. Aber Kakerlake habe ich richtig geschrieben?! :D
Bei DMA-Betrieb ist es norm. so, dass (wegen mögl. Buskonflikt) die CPU einige Takte (durchgängig oder in Intervallen (bsp Cycle-Stealing)) aussetzt. Nur wenn der betr. Speicherbereich Mehrere Busse hat (bsp X- u Y-Bus bei DSPs oder versch. Controllern), ist (fast) völlig paralleles Arbeiten möglich.
>Im Prinzip kann man sich DMA wie einen größeren FIFO am UART vorstellen.
Nein. DMA u. CPU benötigen zur Funktion einen Bus, FIFO nicht.
@MCUA (Gast) >>Im Prinzip kann man sich DMA wie einen größeren FIFO am UART vorstellen. >Nein. DMA u. CPU benötigen zur Funktion einen Bus, FIFO nicht. [ ] Du hast die Bedeutung des Wortes "Prinzip" verstanden.
>Du hast die Bedeutung des Wortes "Prinzip" verstanden.
Eben.
DMA u. FIFO arbeiten 'prinzipiell' anders.
Schau mal ins Datenblatt des MCs, ob das SPI nicht schon selber einen Puffer hat. Manche SPI haben bis zu 16 Byte/Word Puffer. Dann kann man einfach im Timerinterrupt den Puffer lesen und das nächste Lesen starten.
Ich würde die Verwendung des DMAs davon abhängig machen wie oft die Auswertung der Daten erfolgt oder anders gesagt, in welchem Frequenzbereich sich die Vibrationen bewegen. Nur wenn man nicht alle 5kHz messen muss heißt das noch lange nicht, dass man es nicht kann. Wozu die zusätzliche Information verschenken? Wegschmeißen kann man sie notfalls immer noch, wenns mal im Speicher liegt...
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.