mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Auswahl Microcontroller für Messschaltung


Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Rahmen eines Projektes soll eine Messschaltung entwickelt werden, die 
4 analoge Werte messen soll und dann zunächst über den seriell Port 
ausgeben soll. Später soll eine busumwanlung zu usb stattfinden.

Ich bin ein Neuling im Bereich Mikrocontroller. Ich habe mich schon 
eingelesen und denke von der Support Seite her würde am besten ein Atmel 
AVR in Frage kommen.

Jetzt zu den Daten.

Die einzelnen Werte sollen mit mind.

25k sps abgetastet werden. Also gesamte Samplingrate 100 k sps.

Es soll eine Genauigkeit von mind. 10 Bit (vielleicht auch 
12Bit)verarbeitet werden.


Welcher Atmel AVR würde sich am besten eignen. Schwierig ist auf die 
hohen Abtastfrequenzen zu gelangen.

Welche erfahrungen habt ihr.

Gibt es vielleicht auch einen uC der schon die USB schnittstelle onboard 
hat und die Spezifikationen erfüllt.

Bin anhand des großen Angebots an unterschiedlichen uC bei der Auswahl 
noch nicht schlüssig.



Vielen Dank im Voraus

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei den Abtastraten brauchste dir keine Sorgen zu machen, die AVRs 
schaffen bis zu 200 kS/s, aufgeteilt auf 4 Kanäle ergibt das gut Luft.

Schlechter siehts schon mit der Auflösung aus, 10 bit nominell, in der 
Praxis verschwinden die unteren beiden Bits meistens im Rauschen. :-)

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm oder einen wählen mit 12 bit dann ???

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein AVR wird die Abtastrate von 100 ksps nicht schaffen.
Die maximal zulässige Eingangstaktfrequenz von dem SAR-Wandler ist 
(soweit ich das in Erinnerung habe) 250 kHz, damit kommt man niemals auf 
100 ksps.

Der AT91SAM7S64 schafft zum Beispiel bis zu 100 ksps und hat eine 12 
Mbit/sec USB Schnittstelle.

Grüße,

Peter

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh da hab ich mich versehen. also es soll eine tastfrequenz von 25khz 
pro kanal gegeben sein. dann würd der also gehen.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gabs auch schon mal einen Beitrag dazu:

Beitrag "Re: ADC - Wie schnell aktualisiert der? Ist ein Oszi möglic"

Grüße,

Peter

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit Mühe und Not, und knapp außerhalb der Spezifikation kommt man beim 
AVR (8bit) schon noch auf 100 ksps. Allerdings kann man dann nur mit 
etwa 8 Bit Auflösung rechnen.
Man könnte einen externenAD wandler nehmen, oder einen µC mit besserem 
AD Wandler, z.B. PIC33xxx , Atmel Xmega.
Das hat man 12 bit und genügend Tempo.

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Xmega hab ich mir auch schon angeschaut. aber ist dieser nicht für 
diesen zweck überdimensioniert?

20kHz pro kanal sollen noch gemessen werden können bei 10 bit 
genauigkeit. das wär gut

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dran denken, dass man die Daten nicht nur sampeln, sondern auch 
übertragen will. Vielleicht gleichzeitig. Könnte ein AVR leicht ins 
Schwitzen kommen. Also erst einmal ausprobieren, wie hoch die Auslastung 
des Controllers bei 200KB/s USB-Datenrate ist, denn die 12Mb/s sind die 
nominelle USB-Datenrate, nicht notwendigerweise die real dauerhaft 
erzielbare.

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder dann doch lieber einen mit externer umwandlung seriell->usb?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei diese serielle Schnittstelle zum USB-Controller dann mit an die 
2Mb/s laufen sollte. Auch das wird interessant. Generell würde ich 
peilen, dass jeder Controller ohne DMA aus dem Rennen ist.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was spricht denn gegen den AT91SAM7S64, den ich oben vorgeschlagen habe?
Den bekommt man als Einzelstück für 6,25 € und er hat alle geforderten 
Eigenschaften. Einen gcc Compiler gibts auch (für den ARM7).

Wenn der aus irgend einem Grund nicht optimal sein sollte, würde ich als 
nächstes bei den MSP430F5xxx suchen. Die sind aber deutlich schwieriger 
erhältlich und genauso neu wie die ATXmega.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die abtastrate ist eine Sache. Und was soll mite den Werten geschehen ? 
Ein paar floating point Matritzen ?

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die werte sollen an ni labview übertragen werden und dort angezeigt 
werden

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die werte sollen an ni labview übertragen werden und dort angezeigt 
werden.

Autor: Heinrich Boeller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mikro1111 schrieb:
> die werte sollen an ni labview übertragen werden und dort angezeigt
>
> werden

Was ist denn ni-labview? ist ni ein zusatztool für labview, ich kenne 
das garnicht, obwohl ich schon mal mit labview gemalt habe.

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
national instruments. also normales lab view

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke es läuft auf einen atmel xmega hinaus. ich hoffe, dass dieser 
die geforderten geschwindigkeiten erbringt. für die wandlung seriell zu 
usb könnte ja vielleicht ein FT232R zum Einsatz kommen.

wie kann bei dem xmega das dma laufen??? wie wird so etwas konfiguiert?`

Autor: Gebhard Raich (geb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei 100ksamples/s und 10 Bit hast du 200kByte/s Datenaufkommen.Falls die 
seriell geschickt werden sind das 2Mbit/s. Das ist schon sehr an der 
Grenze des FT232R überhaupt mit VCP-Treiber. Was den xmega betrifft 
weiss ich auch nicht ob der auf der seriellen so schnell ist. Würde zu 
einem System mit STM32F (ARM Cortex) und W5300 Ethernet Controller 
raten. Damit kommst du sicher durch, außerdem hat der STM 12 Bit A/D.

Grüße

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm wollte eher in richtung atmel avr bleiben. was wäre hier denn 
leistungsmäßig drin über die serielle schnittstelle?

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anderer Ansatz:

Standard ATMega128 zum Beispiel und per Data Auqisition System die daten 
an USER SPI schnittstelle übertragen.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum seit ihr alle so heiß auf FT232? Es gibt auch ein FT245.
Oder in deinem Fall ein FT2232H in FiFo Mode. Ich habe das erst kürzlich 
bei mir versucht: Ich habe ein Datenblock aus dem RAM eines xmega128A1 
über den 245-FIFO des FT2232H geschickt und komme damit (ohne DMA) auf 1 
MB/s.
Sollte also schon machbar sein.

Autor: mikro1111 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Standard ATMega128 zum Beispiel und per Data Auqisition System die daten
an USER SPI schnittstelle übertragen.

Hat jemand erfahrungen damit? welche analog digital wandlung würde dies 
denn bieten???

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.