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
Nen atmega32 schafft ohne weiteres 1mbaud nen ft232* auch
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
@gast Erst lesen dann schreiben. Er benutzt externe ADC. Nix ADC von ATMega.
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.
Wenn die Signaländerung < 12 Bit / sample ist schlage ich vor das delta / channel zu senden.
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
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.