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
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
>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.
>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...
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
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.
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.
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
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
>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
@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
