Hallo zusammen, ich entwickele gerade eine SChaltung mit der ich Analogwerte zwischen 0 und 5V mit einer Maximalen Frequenz von 10Khz abtasten und über USB an den Computer senden möchte. Dazu verwende ich als ADC einen AD9071, als µC einen ATmega88 und als Pegelwandeler fürs USB eine FT232R. Soweit so gut und einfach. Nun würde ich mir alternativ zur Datenübertragung an den PC, die maximale Amplitude gemittelt über einige Perioden, auf einem LCD display ausgeben. Dazu wären neben der Bestimmung der Amplitude auch noch eine Rechnung a la y=x^2+bx+c notwendig. Die Abtastrate müsste laut Abtasttheorem ja mindestens 20kHz betragen. Nun stellt sich mir die Frage ob der µC mit den ganzen Aufgaben nicht leicht überfordert ist. Allein die Bestimmung der Amplitude dürfte ja einiges an Aufwand kosten und eh nach Umsetzung auch mehr oder weniger viel Speicher beanspruchen! Mir fällt schwer die benötigte Rechenleistung zu abzuschätzen. Kann mir da vllt jemand zur Seite springen und mir zumindest eine größenordnung nennen?
25kHz Abtastfrequenz, 20MHz Takt --> 800 Takte zwischen zwei Samples. Wenn man es klug anstellt (2**n Samples --> Division=Bitshift usw) sollte das imho klappen. Ein Versuch ist es auf jeden Fall wert.
Achso, mit wie vielen Bits pro Wert soll gerechnet werden? Wenn man float nimmt wird das garantiert nichts...
Das wird eng, du musst ja die Messwerte auch noch holen, du hast ja kein DMA. Also ich würde auf n STM32F4 gehen.
>Bestimung der Amplitude ....
Was soll'das denn ? Die kommt ja gleich so aus'm ADC raus.
Timo schrieb: > Die Abtastrate müsste laut Abtasttheorem ja mindestens 20kHz betragen. Aber nicht die Anzeigerate! Und deshalb kannst du ja schnell wandeln, aber schön langsam rechnen und anzeigen... > Allein die Bestimmung der Amplitude dürfte ja einiges an Aufwand kosten Du meinst das Umrechnen des AD-Werts auf eine Spannung? Das tut man auch gar nicht. Sondern man rechnet solange wie möglich in Ganzzahlen mit dem AD-Wert und skaliert erst zur Anzeige auf Volt um. > Analogwerte zwischen 0 und 5V > Dazu verwende ich als ADC einen AD9071, als µC einen ATmega88 und als > Pegelwandeler fürs USB eine FT232R. Wozu ein externer Wandler, wenn der ATmega schon viele davon hat, die den angegebenen Bereich super können?
Das sollte kein Problem für einen AVR darstellen. Aber was willst Du eigentlich? Zuerst schreibst Du, Du willst mit maximal 10 KHz abtasten und dann wiederum laut Abtasttheorem mit 20 KHz arbeiten. Oder willst du ein 10 KHz Signal mit 20 Kilosamples/Sekunde abtasten? 10 Kilosamples/Sekunde würde der Atmega selber schaffen, ohne externen ADC. Dann kommt die Art des Signals. Wie willst Du da die Amplituden mitteln? Wenn es etwas wie ein Sinus oder Sägezahn oder ähnlich ist, dann ist es leicht. Dann brauchst Du immer nur mit dem Vorgänger zu vergleichen (wenig Rechenleistung und wenig Speicherbedarf). Wenn das Signal aber so vor sich hinzittert, gilt dann jeder Richtungswechsel als Minimum/Maximum? Oder läuft das Signal zitternd zwischen den eigentlich gemeinten Minima und Maxima auf und ab. Das wäre dann etwas mehr Rechnerei, je nachdem was genau du suchst. Ein "Sinus" welcher nahe des Maximums zittert würde dort mit dem primitiven Vergleich haufenweise Minima und Maxima produzieren und somit deine Amplitudenmittelung völlig schrotten. Was soll das mit der Gleichung? y=x^2+bx+c Das sieht für mich nach einer Formel für Temperaturfühler aus. Willst Du die Amplitude der Messwerte Mitteln oder willst Du die Amplitude der Ergebnisse der Formel, angewand auf die Messwerte, ermitteln? Geht es nur um die genannte Amplitudenmittelung wäre im ersteren Fall die Berechnung nach Formel nicht nötig, allenfalls am Ende zur Übersetzung und Darstellung des Ergebnisses. Auch im zweiten Fall würde es reichen erst die Maxima und Minima zu bestimmen und dann die Formel nur auf die Maxima und Minima anzwenden und nicht auf alle Messwerte. Dann hinge der Aufwand von der Anzahl der Minima und Maxima ab, also der "Frequenz" des abzutastenden Signals, womit wir wieder bei Frage eins sind. Selbst wenn es am Ende Float werden soll, da der Wandler "nur" ein 10-Bit-Signal liefert, so reicht es zunächst nur mit Integer zu rechnen und dann erst am ende nach Float zu casten, es sei den Du hast noch anderes mit den Daten vor was eine sofortige Wandlung nach float erforderlich machen würde. Ein bisschen Nachdenken bei der Sortierung der Berechnungsreihenfolge im Code bewirkt oft Wunder und oftmals sogar wesentlich mehr als beispielsweise der Unterschied zwischen verschiedenen Sprachen oder der Sprung zum nächstgrößeren Mikrocontroller ausmachen würde. Umgekehrt bedeutet das aber auch: Solange Dein Algorithmus noch nicht steht, und erst recht nicht so lange noch nicht bekannt ist was Du eigentlich alles berechnen willst, läßt sich der Rechenaufwand für den Prozessor kaum bis gar nicht progostizieren. Echte Aufwandabschätzungen erfolgen erst anhand eines konkreten Algorithmus. Alles andere ist wirklich nur eine Schätzung. Gruß Carsten
Ingo schrieb: > du hast ja kein DMA. Also ich würde auf n STM32F4 gehen. Wieder mal die STM32F4 Fanboys... DMA würde bei diesem Projekt kaum Rechenzeitersparnis bringen.
Timo schrieb: > Hallo zusammen, > ich entwickele gerade eine SChaltung mit der ich Analogwerte zwischen 0 > und 5V mit einer Maximalen Frequenz von 10Khz abtasten und über USB an > den Computer senden möchte. > Dazu verwende ich als ADC einen AD9071, als µC einen ATmega88 und als > Pegelwandeler fürs USB eine FT232R. Wozu da einen 100000000 Samples/s ADC (100 MSps) einsetzen, der bei Vollast gut 3 Watt benötigt etc.?
Meine Güte, sind denn nur Lestighaniker hier zugange? Signalfrequenzen bis 10kHz, heißt abtasten mit mindestens 20kHz. Nehmen wir mal 25kHz an und einen 16-Bit-ADC, dann geht es letztendlich darum, 50KB/s vom ADC zum USB zu schaufeln. Gerechnet wird da gar nix, vielleicht noch ein bisschen Padding oder Timestamps in den Datenstrom streuen. Da grinst selbst ein 8-Bit AVR nur müde. Der USB sowieso. OK, ich hab jetzt weder den ADC gecheckt, ob der in Punkto Abtastrate und Auflösung paßt. Noch bin ich mir sicher, ob der FT232R einen geeigneten Übertragungsmodus beherrscht. Das sind Hausaufgaben, die der TE doch bitte selber machen soll. Aber wenn es einen virtuellen COM Port Modus mit 460,8 kBit/s geben sollte, dann reicht das schon. Sonst halt irgendein isochroner Transfermodus. Die Hälfte des Problems liegt ja ohnehin PC-seitig. XL
Der groessere Teil des Problems liegt im PC. Was macht man mit diesen Daten? Auch wenn man sie auf die Disk schreiben kann ... was dann?
Timo schrieb: > und 5V mit einer Maximalen Frequenz von 10Khz abtasten ... > die maximale Amplitude ... > Die Abtastrate müsste laut Abtasttheorem ja mindestens 20kHz betragen. Noch was: du kannst mit den theoretischen 20kHz nicht sicher die Amplitude eines 10kH Signals abtasten. Auf jeden Fall garantiert nicht in jeder Halbwelle. Hier einfach mal mit einem Dreiecksignal:
1 | Signal 10kHz: |
2 | 7 /\ /\ /\ /\ |
3 | / \ / \ / \ / \ |
4 | / \ / \ / \ / \ |
5 | / \ / \ / \ / \ |
6 | / \ / \ / \ / \ |
7 | / \ / \ / \ / \ |
8 | / \ / \ / \ / \ |
9 | 0/ \/ \/ \/ \ |
10 | |
11 | | | | | | | | | | |
12 | | | | | | | | | | |
13 | 2 5 1 7 0 6 2 3 3 |
14 | |
15 | Abtastung >20kHz |
Fazit: in 4 Zyklen gerade 1x die Amplitude erwischt...
Erst mal danke für die vielen Antworten! War gestern nach 10 Stunden am PC scheinbar etwas übermüdet und unaufmerksam! Daher erstmal einige klarstellungen: >Arc Net schrieb: >Wozu da einen 100000000 Samples/s ADC (100 MSps) einsetzen, der bei >Vollast gut 3 Watt benötigt etc.? Da hast du vollkommen recht, daher benutze ich auch den AD7091R! Zahlendreher;) Die hohe Abtastrate (Ich benötige nicht wirklich 1MSps, wäre sicher auch sehr schwer zu händelt, denke ich;)) um das Signal für die PC-Verarbeitung möglichst genau aufzunehmen, daher auch 12bit! >Axel Schwenke schrieb: >Meine Güte, sind denn nur Lestighaniker hier zugange? Signalfrequenzen >bis 10kHz, heißt abtasten mit mindestens 20kHz. Nehmen wir mal 25kHz an >und einen 16-Bit-ADC, dann geht es letztendlich darum, 50KB/s vom ADC >zum USB zu schaufeln. Gerechnet wird da gar nix, vielleicht noch ein >bisschen Padding oder Timestamps in den Datenstrom streuen. Da grinst >selbst ein 8-Bit AVR nur müde. Der USB sowieso. Da sehe ich auch gar kein Problem! Habe 12bit und würde eig. auch gern mit 50-100kHz abtasten und weiterleiten an USB! Das sollte laufen!! Ist aber auch nicht meine Frage gewesen, die Anzeige auf einem LCD ist hier die frage, dann muss ich auch nicht unbedingt was an den PC senden. >Lothar Miller schrieb: >Aber nicht die Anzeigerate! Und deshalb kannst du ja schnell wandeln, >aber schön langsam rechnen und anzeigen... Exakt! >Carsten R. schrieb: >Aber was willst Du eigentlich? >Zuerst schreibst Du, Du willst mit maximal 10 KHz abtasten und dann >wiederum laut Abtasttheorem mit 20 KHz arbeiten. Mein Fehler! Signalform: Sinus Frequenz max.: 10kHz Abtastrate: allermindesten 20kHz (wegen Amplitudenbestimmung eher deutlich mehr) Hatte das so geplant: Amplitude bestimmen nach Schema: Wenn nachfolgender Wert größer, diesen Speicher und mit dem nächsten vergleichen! Das solange durchführen bis der Wert fällt! Wenn meine Messung bzw. der Sinus leicht zittert müsste man das noch mal überdenken! Das 10-50 mal und Wert mittel! Um das ganze etwas genauer zu bekommen und Messfehlereinflüsse zu verringern. Dann muss der Wert vor der Ausgabe noch umgewandelt werden, ich benötige hier allerdings nicht die Spannung sondern einen Sensorwert! Dazu muss die Spannung umgerechent werden, die Formel steht noch nicht ganz wird aber wohl a la y=x^2+bx+c aussehen. Was würdet Ihr sagen, langt die Rechenleistung des µCs? Die Ausgabe an das Display kann auch nur alle 100-200ms erfolgen, das würde reichen! Trotzdem muss natürlich konstant gewandelt werden und die Amplitude bestimmt werden;)
Lothar Miller schrieb: >
1 | > Signal 10kHz: |
2 | > 7 /\ /\ /\ /\ |
3 | > / \ / \ / \ / \ |
4 | > / \ / \ / \ / \ |
5 | > / \ / \ / \ / \ |
6 | > / \ / \ / \ / \ |
7 | > / \ / \ / \ / \ |
8 | > / \ / \ / \ / \ |
9 | > 0/ \/ \/ \/ \ |
10 | > |
11 | > | | | | | | | | | |
12 | > | | | | | | | | | |
13 | > 2 5 1 7 0 6 2 3 3 |
14 | > |
15 | > Abtastung >20kHz |
16 | > |
Hehe, Ein Dreieckssignal hat starke Oberwellen im Spektrum. Wenn also schon die Grundschwingung (das Dreieck) mit 10kHz schwingt, sind die Oberwellen weit drüber. ;)
Hallo, die 800 Taktzyklen pro Datenpunkt, die dir bei 25kSps und 20MHz Takt zur Verfügung stehen könnten ausreichen, allerdings muss das Programm dafür meiner Einschätzung nach gut durchdacht sein. Ich bin mir auch nicht sicher, ob C mit Optimierung ausreicht, oder ob es in ASM geschrieben werden muss. Da das Signal eine bekannte Form und eine feste Frequenz hat und scheinbar wirklich nur der Spitzenwert interessant ist könnte man das Signal auch analog aufbereiten und dann nur für die Anzeigewerte den fertigen Analogwert mit dem ADC erfassen (vergleichbar einer Wechselspannungsmessung mit einem Multimeter). Gruß Kai
100 kHz * 12 Bit = 1200 kBit/s, da das SPI-Modul keine "krummen" Transfers kennt, laufen 100 kHz * 16 Bit = 1600 kBit/s = 200 kByte/s über SPI. 20 MHz / 200 kByte/s = 100 Taktzyklen Wenn die Daten über USB rausgehen sollen, kann es durchaus sein, dass u.U. ein Teil der Daten zwischengespeichert werden muss bis sie gesendet werden dürfen. Soll mit Interrupt gearbeitet werden, muss auch dort der Overhead miteinberechnet werden...
Hi >100 kHz * 12 Bit = 1200 kBit/s, da das SPI-Modul keine "krummen" >Transfers kennt, ... . Das SPI-Modul nicht. Aber die USART im SPI-Mode. Da sollte der TO evtl. mal über einen ATMega164P mit 2 USARTs nachdenken. MfG Spess
>spess53 schrieb: >Das SPI-Modul nicht. Aber die USART im SPI-Mode. Da sollte der TO evtl. >mal über einen ATMega164P mit 2 USARTs nachdenken. In meiner Leichtsinnigkeit bin ich davon ausgegangen das ich mir meine Daten von ADC einfach per SPI hole und dann per Uart an den FT232R weitergebe. Auf die Gefahr das, dass jetzt peinlich wird: dachte die Module würden unabhängig voneinander laufen...
Stefanie B. schrieb: > Ein Dreieckssignal hat starke Oberwellen im Spektrum. Naja, sooo stark sind die auch nicht. Siehe mal die Spektren dort: http://public.beuth-hochschule.de/~s33688/ue4.php Nur ein Sinus hat weniger Oberwellen... ;-) Und ich wollte damit eigentlich nur zeigen, dass die doppelte Abtastfrequenz zu Amplitudenbestimmung nicht ausreicht. Und es ist einfacher zu zeichnen, deshalb schrieb ich auch: >>> Hier einfach mal mit einem Dreiecksignal
Hi > Auf die Gefahr das, dass jetzt peinlich wird: dachte die >Module würden unabhängig voneinander laufen... Wenn du SPI und USART meinst hast du Recht. Aber die USART des ATMega88 (und anderer neueren ATMegas) können auch als SPI konfiguriert werden (SPI-Mode). Allerdings habe ich das 'krumme' im Beitrag von Arc Net (arc) fälschlicher weise auf den SPI-Takt bezogen. Er meint aber die Anzahl der Datenbits. Eine USART im SPI-Mode würde durch die Pufferung der Ein- und Ausgangsregister aber geringfügig schneller als das SPI-Modul sein. MfG Spess
>Lothar Miller schrieb: >Und ich wollte damit eigentlich nur zeigen, dass die doppelte >Abtastfrequenz zu Amplitudenbestimmung nicht ausreicht. Und es ist >einfacher zu zeichnen, deshalb schrieb ich auch: >>>> Hier einfach mal mit einem Dreiecksignal Da hast du vollkommen Recht! Deswegen sprach ich auch von einer MINDESTENS Abtastfrequenz von 20kHz. Um das sauber zu gestalten müsste ich wohl doch deutlich höherfrequent abtasten. >spess53 schrieb: >Allerdings habe ich das 'krumme' im Beitrag von Arc Net (arc) >fälschlicher weise auf den SPI-Takt bezogen. Er meint aber die Anzahl >der Datenbits. Eine USART im SPI-Mode würde durch die Pufferung der Ein- >und Ausgangsregister aber geringfügig schneller als das SPI-Modul sein. Müsste doch mit dem standart SPI-Modul die ADC-Daten "locker" rüberschaufeln können? Wozu also zwei Usart? Das erschließt sich mir noch nicht!
spess53 schrieb: > Hi > >>100 kHz * 12 Bit = 1200 kBit/s, da das SPI-Modul keine "krummen" >>Transfers kennt, ... . > > Das SPI-Modul nicht. Aber die USART im SPI-Mode. Da sollte der TO evtl. > mal über einen ATMega164P mit 2 USARTs nachdenken. Mit krumm meinte ich 12-Bit bzw. 13-Bit wie vom AD-Wandler minimal benötigt. Die USARTs können bei den AVRs afaik auch nur 8-Bit oder 16-Bit-Transfers... Praktisch wäre das RSPI der RX200, das könnte zum einen auch 9, 10, 11-Bit etc., zum anderen könnte über den Puls-Generator das Startsignal generiert werden und über den Data Transfer Controller / Event Link Controller der Rest der Datenübertragung automatisiert werden (bräuchte man da nicht, da der passende 12-Bit, 1 MSPS AD-Wandler schon eingebaut ist...). Ähnliches sollte auch mit den AVR XMega gehen. Edit: > Wozu also zwei Usart? Das erschließt sich mir noch nicht! USARTs deshalb, da diese direkt 16-Bit-Werte übertragen können, würde einen Interrupt/einen Test einsparen.
Hi >Müsste doch mit dem standart SPI-Modul die ADC-Daten "locker" >rüberschaufeln können? Wozu also zwei Usart? Das erschließt sich mir >noch nicht! Ich will dich doch nicht zu zwei USARTs zwingen. Aber ich hatte oben schon geschrieben, das in deinem Fall eine USART im SPI-Mode komfortabler zu bedienen ist wie das SPI-Modul. Um deine 12 Bit abzuholen must du per SPI zwei Byte 'senden' um den Takt zu erzeugen. Bei der USART im SPI-Mode kannst du die beiden Byte faktisch unmittelbar hintereinander in den Transmitpuffer schaufeln. Beim SPI-Modul mußt du warten bis das erste gesendet wurde und das Empfangsregister auslesen bevor du das zweite Byte losschicken kannst. Eine USART im SPI-Mode kann zwei empfangene Bytes puffern. Damit kannst du du den Zeitpunkt des Auslesens selbst festlegen. MfG Spess
spess53 schrieb: > Eine USART im SPI-Mode kann zwei empfangene Bytes puffern. Echt? Ich dachte bisher, die Doppelpufferung gibt es nur in Senderichtung und beim Empfang muß das erste Byte aus dem Empfangspuffer geholt werden, bevor das zweite vollständig "reingetaktet" wurde.
Danke für die vielen Antworten! Ich werd mir das mit dem USART im SPI-Mode noch mal durch den Kopf gehen lassen. mfg Timo
ATMega88A: The USART in MSPIM mode includes (double) buffering of the transmitter. The SPI has no buffer.
Hubtau schrieb: > ATMega88A: The USART in MSPIM mode includes (double) buffering of the > transmitter. Das weiß ich. Es ist aber nichts davon zu lesen, dass das bei dem Receiver auch so ist.
Hi >Das weiß ich. Es ist aber nichts davon zu lesen, dass das bei dem >Receiver auch so ist. Datenblatt ATMega88: 19. USART0 19.2 Overview ...The Receiver is the most complex part of the USART module due to its clock and data recovery units. The recovery units are used for asynchronous data reception. In addition to the recovery units, the Receiver includes a Parity Checker, Control logic, a Shift Register and a two level receive buffer (UDRn). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 20. USART in SPI Mode 20.2 Overview ...the USART in Master SPI Mode (MSPIM) logic. In this mode of operation the SPI master control logic takes direct control over the USART resources. These resources include the transmitter and receiver shift register and buffers, and the baud rate generator. ^^^^^^^^ ^^^^^^^^ Noch Fragen? MfG Spess
Spess53 schrieb: > Noch Fragen? Nein. Vielen Dank für Deine Mühe. Werde ich bei Gelegenheit mal ausprobieren.
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.