mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Schnelle Datenübertragung von µC zu PC


Autor: christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

erstmal die Hintergründe:

Ich bin im Moment am planen eines Mikrowellen-Transmission-Experiments. 
Die Kommunikation mit dem Aufbau wird über Internet erfolgen (evtl UMTS 
falls kein Netzanschluß in der Nähe). Als Hauptsteuerung ist dafür ein 
linuxfähiger SBC mit ARM9 im PC/104 Format vorgesehen der mit der 
restlichen Hochfrequenz-Hardware in einem wetterfesten Gehäuse 
untergebracht ist.

Ursprünglich war dieser Rechner mit seinen onboard-ADCs auch für die 
Messdatenerfassung gedacht, doch da wir auf einen gepulsten Sender 
umgeschwenkt sind, muss unser Konzept erweitert werden.

Das auf Linux laufende Messprogramm soll jede Sekunde einen µC starten 
der dann für die Pulserzeugung zuständig ist. Die Sendepulse sollen eine 
minimale Länge von 100 ns und eine Wiederholrate von 100 KHz haben. Im 
Empfänger werden dann mit 100 KS/s zwei Signale simultan vom ADC 
gewandelt. Der ADC und sein sample/hold müssen also genau auf die 
Sendepulse synchronisiert werden.

Für die Pulserzeugung wird ein einfacher µC genügen und für die Wandlung 
sollten zwei MAX196 oder ein MAX1304 passen.

Bei 12 Bit Auflösung ergibt sich also 2,4 MBit/s. Es muss aber nicht 
kontinunierlich gemessen werden. Zur Rauschmessung (einmal pro Minute) 
ca 100ms lang und dann wieder nur alle Sekunde ein paar Werte über die 
gemittelet wird.

Trotzdem würde ich gerne auf eine Pufferung verzichten und den µC-Teil 
möglichst einfach halten, also die Daten sofort streamen um sie auf die 
SD-Card im SBC zu schreiben. Von dort werden sie dann über sftp 
abtransportiert.

Der SBC hat USB2.0 und RS-485.

Wie würdet ihr das machen?

Danke schonmal im Voraus
christian

Autor: D. S. (jasmin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rs485..... (SPI)

Autor: Teplotaxl X. (t3plot4x1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nen atmega32 schafft ohne weiteres 1mbaud
nen ft232* auch

Autor: christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss meinen Thread nochmal ausgraben.

RS485 scheidet aus, weil der UART nicht schnell genug ist.
Es sind jetzt 4.8 Mbit/s (12bit 4CH @100KS/S) Daten die weggeschafft 
werden sollen.

Meine Lösung schaut im Moment so aus, das ein ATMega, der nur diese 
Aufgabe hat, die 12bit Daten abholt und für den FT245 in 8Bit Daten 
zerlegt. Der FT245 kann laut Angabe von FTDI bis zu 1Mbyte/s. Sollte 
also gehn. Diese Transferrate erreicht man aber, widerum laut FTDI, nur 
mit den "D2XX Direct Drivers".

Leider ist mir nicht klar wie ich ohne (virtuellen) Com-Port auf der PC 
Seite die Daten schnell genug empfangen und wieder zusammensetzen soll. 
Werden die Daten vom Betriebssystem gepuffert und ich lese dann zyklisch 
einfach diesen Puffer mit der read-Funktion der D2xx-API aus?

grüße

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es sind jetzt 4.8 Mbit/s (12bit 4CH @100KS/S) Daten die weggeschafft
>werden sollen.

>Meine Lösung schaut im Moment so aus, das ein ATMega

Sportliche Aufgabe. Nehmen wir mal an ATMega Takt 16MHz.
Das sind dann ganze 26 Befehle die der uC zum auslesen
eines Bytes aus dem AD Wandler und zum reinschaufeln
in den FTDI hat.

Autor: christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sportliche Aufgabe. Nehmen wir mal an ATMega Takt 16MHz.
>Das sind dann ganze 26 Befehle die der uC zum auslesen
>eines Bytes aus dem AD Wandler und zum reinschaufeln
>in den FTDI hat.

Ja, der macht auch noch andere überaus sportliche Sachen, aber wenn 
gewandelt wird macht er nur das.
Das Problem ist ja auch, wie die Daten aus dem USB im PC wieder schön 
raus zu bekommen sind...

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die megas machen 100ksps nur mit glück

ab einem gewissen takt  > 700khz ADC takt fängt der an ab und an mist zu 
messen

der kern kann natürlich auch 20-30MHz laufen
der ADC selbst darf laut atmel max 250khz

und er brauch eine wandelzeit von grob 13 takten bei singlended 
messungen
also selbst die 1Mhz bei 8bit sind arg hoch
1Mhz ADC takt  bei 13 takten für eine wandlung sind immernoch 76,9ksps

im multiplexbetrieb wird es also schwer an die 100ksps ranzukommen

die angestrebten 100kspsp sind also schwer möglich

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@gast

Erst lesen dann schreiben. Er benutzt externe ADC.
Nix ADC von ATMega.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
benötigst du zwingend 12bit oder reichen auch 8 bit? Es gibt von TI AD 
Wandler mit parallelem 8 bit Interface, dann würde schonmal die wandlung 
12->8bit wegfallen.

Autor: BinGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn die Signaländerung < 12 Bit / sample ist schlage ich vor das delta 
/ channel zu senden.

Autor: BinGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RS422 ist auch Bestandteil von SCSI Bus-Systemen
(mit Transferraten von 60Mbit bei LVD Treibern, allerdings mit 
reduzierter Leitungslänge). Vielleicht dort mal suchen

Würde eher Fiberoptik(module) vorschlagen. Könnten schnell genug sein 
;-).
Hat auch den Vorteil der galvanischen Trennung und kein EMV-Problem da 
die Leitung ja sonst eine etwas ungeplante Sende-Empfangs Antenne ist.

Autor: christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8 Bit reichen leider nicht. Aber die Idee nur immer das Delta/channel zu 
übertragen ist eigentlich nicht schlecht. Bringt halt auch nur was, wenn 
man das auf 8 Bit beschränkt. Damit ergibt sich natürlich eine 
Einschränkung der Messgenauigkeit und es ist leider noch nicht abzusehen 
ob diese dann noch ausreicht.

Eine andere PC-Schnittstelle zu benutzen habe ich mir auch schon 
überlegt. Auf einem PC/104 Board ist ja der PC/104- bzw. ISA-Bus 
eingentlich genau dafür da, kleine Module wie ADC-Boards anzubinden. Man 
könnte dann, oder auch mit SCSI, wunderschön Daten par DMA übertragen. 
Aber bis das bei mir als Einsteiger in die Materie mal funktioniert, 
dauert es wohl etwas länger bzw. zu lang.

Ich werde mich aber gleich mal daran machen das Datenblatt vom NCR53C80 
zu durchstöbern um mal eine Ahnung von der Komplexität oder vielleicht 
sogar Einfachheit von SCSI zu bekommen.

Bin aber immer noch für möglichst einfache und zur Not auch unelegante 
Lösungsforschläge für den Datentransfer von 4,8 Mbit/s von µC zum PC 
dankbar.

grüße
christian

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FT245 oder FH2232(H) als (synchrones) Fifo.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
christian wrote:
> Bin aber immer noch für möglichst einfache und zur Not auch unelegante
> Lösungsforschläge für den Datentransfer von 4,8 Mbit/s von µC zum PC
> dankbar.

Ich würde es mit einem Ethernet-Controller machen, z.B. den ENC28J60. Da 
gibts schon eine Menge Schaltungen und Software hier, auch fertige 
Boards z.B. bei Pollin.
Wenn man das geschickt programmiert, muss der ATmega dann nichts weiter 
tun, als die Messwerte in den Buffer des ENC28J60 zu schreiben und den 
Befehl zum senden zu geben, wenn das Paket voll ist. 4,8 Mbit/s sollten 
damit zu schaffen sein.

Gruss
Andreas

Autor: christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich würde es mit einem Ethernet-Controller machen, z.B. den ENC28J60.
Behalt ich mal im Hinterkopf. Danke.

>FT245 oder FH2232(H) als (synchrones) Fifo.
Ui. Der neue FT2232H ist wohl nochmal ein ganzes Stück schneller. Aber 
die 25Mbyte/s bei synchronem Fifo gehn wohl nur mit der internen 60 MHz 
clock. Und da kann ich wohl die Daten nicht schnell genung anliefern.

Mir würden ja die 8 Mbit/s eines FT245 gut reichen. Aber generell, auch 
beim FT2232H, habe ich so meine Sorgen bei der Übertragung vom Tx_Fifo 
zum Pc. Denn wenn der nicht rechtzeitig vor einem Überlauf die Daten 
abholt wird meine Messung, die ja kontinuierlich übertragen werden muss, 
unbrauchbar.

Hat jemand Erfahrung mit den maximalen 8 Mbit/s die auch PC-seitig 
kontinuierlich garantiert werden können.

Besten Dank
christian

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian
Sowohl der FT245|2232(h) als auch das Betriebssystem des PCs haben 
Puffer. Man muss nur sicherstellen, dass immer genuegend Leseanfragen am 
Device anstehen. Ein extra Thread kann hilfreich sein, aber fuer den 
FT245|FT2232L sollte es auch ohne gehen. Das USRP Projekte erreicht mit 
dem FX2 in einer aehnlichen Anwendung etwa 33 MByte/sec

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.