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.
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
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;)
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.
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
