Hallo ersteinmal! Ich habe folgende Aufgabe ich will 4 Datenleitungen (TTL Pegel) in meinen PC bekommen. Mehr oder weniger soll es ein Logik Analyzer sein. Mehr oder weniger eben. Gibt es eine möglichkeit dies hinzubekommen? Wenn ja kann mir einer verraten wie? Achja die Daten will ich dann später per VB weiter verarbeiten. Danke schon mal an alle im vorraus. Anthony Smith PS: Zur Datenrate der kürzeste Puls ist ~500ns lang auf dessen fallende Flanke ich Trigger.
Gast
#1204946
Ich habe hier das UM245R Platinchen von FTDI im Einsatz. Bisher habe ich zwar nur das runtersenden probiert (also PC -> Schaltung), aber beim Hochsenden funktioniert das ähnlich. Und zwar werden die Daten an die Datenpins des FTDI Chips angelegt, dann wird eine Steuerleitung (WR#, glaub ich) auf LOW gezogen und der Chip liest das Byte ein. Den Transfer zum PC übernimmt der Chip eigenständig, du musst halt auf der PC-Seite die Daten mit der D2xx DLL von FTDI abholen. Wenn du also deine Triggerleitung an den WR# Pin hängst, und die Datenleitungen an D0..4, so sollte das ganze schon laufen. Einen Tag löten, einen Tag PC programmieren, schon rennt die Sache ;-) Ein Problem bei deiner Schaltung könnte nur auftreten, falls der Chip gerade keine Daten lesen möchte (TXE# auf HIGH). Bei mir habe ich halt nen µC dran, der die Daten dann später nochmal versucht zu senden.
Gast
#1207558
Hallo peterguy, danke für deine sehr hilfreiche Antwort. Habe da noch 2 Fragen. Hoffe das du oder jemand anderes mir da weiter hift. 1. Löst der Treiber bzw. die DLL unteer VB6 einen Event bei neuen Daten aus? 2. Wie funktioniert das mit dem Lesen der Daten konkret? Würde mir bitte jemand ein Beispiel schicken? pittiplatsch86b@web.de Danke für Eure Mühen im vorraus Philipp
Das liegt daran, dass der Übertragungsrahmen bei USB nur aller 1ms gesendet wird. Wäre es nicht sinnvoller die Messdatendaten nach auslösen des Triggers in Hardware abzulegen und anschließend den Speicherinhalt an den PC senden.
Anleitungen zu den D2xx DLL Treibern findest du bei FTDI auf der homepage. Dort kannst du sogar deine Entwicklungsumgebung angeben (C++ Builder, Visual C++,.....) http://www.ftdichip.com
Mit dem ablegen in Externen Speicher gute Idee. Das Problem ist nur das es nicht wirklich ein Logik Analyzer wird. Sprich bestimmte Datenlänge. Es geht umd das XY2-100 Protokoll welches ich mit lesen will und wieder in Grafik umsetzen will. Da ist die Menge der Daten sehr Variable. Ich bin davon ausgegangen das direkt in PC schaufeln "leichter" ist. Zu den Samples. Diese habe natürlich schon gesehen. Aber leider nicht so ganz simpel. Und so wie ich das gesehen habe kein Konkretes Beispiel für den FT245R. Oder? Lasse mich gern korregieren. mfg Philipp
Gast
#1209428
Also man kann in der D2xx DLL verschiedene Events registrieren. Darunter auch einen, der beim Empfang von Daten ausgelöst wird. Ob deine VB-Events damit auch funktionieren weiß ich leider nicht genau, aber ich gehe mal davon aus. Mit Beispielcode kann ich leider noch nicht dienen, da ich zum Testen in LabVIEW programmiere. Dort funktionieren die Events z.B. nicht, also muss gepollt werden... Ich habe das doch richtig verstanden, daß du keinen µC verwendest, sondern die Leitungen mehr oder weniger direkt an den Chip hängst?
Mehr oder weniger richtig ;-) Da es Differentielle Signale sind wandel ich diese zuerst mit einem IC um aber das soll alles sein. Werde den FT2232H nutzen der andere ist wohl zu langsam.
Gast
#1210648
Das sind doch die neuen USB2.0 Chips, oder? Hast du von denen eine fertige Platine gefunden oder machst du ein eigenes Layout?
Ersteinmal JA sind die 2.0 Chips. Ich habe bei Farnell ein Dev. Kit gesehen. Aber denke ich werde es fädeln. Um kosten zu sparen. Nur Chip liegt bei ca. 10 € als Dev. Platinchen mit USB anschluss und auf Stiftleisten geführt um die 30€. Gruß Philipp
Gast
#1211202
Naja, 30€ geht ja noch. Meine UM245R Platinchen waren auch nicht viel günstiger. Habe auch vor, auf einen der beiden USB 2.0 Bausteine "upzugraden", wenn ich mein Layout mache. Bei 500ns Datentakt bist du schon auf den 2232H angewiesen, denn 16MBit schaffen die 1.1er nicht. Du hast halt leider 50% Overhead bei deiner Schaltung, da der Chip 8Bit einlesen wird, von denen du nur 4 brauchst. Evtl. wäre es schlauer, noch einen µC zwischenzuhängen, der zum Einen je 2 Messwerte in ein Byte packt und zum Anderen auch als Puffer dient, falls der FTDI-Chip mal den TXE# disabled.
ginge ja auch mit Schieberegistern und Addierern so ist das nicht. Will aber möglichst wenig extern Peripherie. Noch immer ist die Frage offen. Wer ein schönes Beispiel als FTDI für mich in VB6 hat :-) @peterguy Verrätst du mir was du konkret machst? Also mit den Chip von FTDI
Wie schon weiter oben erwähnt wird bei USB jede Millisekunde ein Frame gesendet. Je nach Übertragungsart hat ein Frame unterschiedliche Größen, z.B. HID: 64 byte, Mass Storage Class: 1024 byte. Das heisst: Du musst die Daten zwischenspeichern und als Block versenden um annährend in die Größenordnung deiner gewünschten Übtetragungsrate zu kommen. Da helfen auch die neuen, schnellen Chips nicht. Noch ein Punkt: USB 2.0 sagt nichts über die Geschwindigkeit aus, sondern nur über das Protokol (die alten FTDI chips waren auch schon 2.0 tauglich). Für die Geschwindigkeit ist die Bezeichnung "High Speed" (480Mbit/s), "Full Speed" (12Mbit/s) oder "Low Speed" (1.5Mbit/s) wichtig.
hmm... nur so zum verständniss, der FT2232H kann doch die Daten für mich zwischenspeichern. Oder? Das bedeutet ich schaufe in meinem 500ms Raster in ihn rein und lese im 1ms. Raster einfach "große" Blöcke aus. Oder? Also echtzeit ist kein Kreterium für mich.
Gast
#1211340
> Wie schon weiter oben erwähnt wird bei USB jede Millisekunde ein Frame > gesendet. Je nach Übertragungsart hat ein Frame unterschiedliche Größen, > z.B. HID: 64 byte, Mass Storage Class: 1024 byte. Das heisst: Du musst > die Daten zwischenspeichern und als Block versenden um annährend in die > Größenordnung deiner gewünschten Übtetragungsrate zu kommen. > Da helfen auch die neuen, schnellen Chips nicht. Genau diese Protokollumsetzung erledigen die FTDI Chips. Das ist ja das schöne, man muss sich mit dem USB Protokoll nicht abmühen, einfach einen geeigneten Chip an RS232 oder parallel anschließen und auf PC-Seiten über die mitgelieferte DLL die Daten empfangen. Natürlich ist man mit fertigen Lösungen wie den FTDI chips nicht so flexibel und kommt auch nicht wirklich tief in die Materie USB rein. Das ist halt der Haken an der Sache. > Noch ein Punkt: USB 2.0 sagt nichts über die Geschwindigkeit aus, > sondern nur über das Protokol (die alten FTDI chips waren auch schon 2.0 > tauglich). Für die Geschwindigkeit ist die Bezeichnung "High Speed" > (480Mbit/s), "Full Speed" (12Mbit/s) oder "Low Speed" (1.5Mbit/s) > wichtig. Ich meinte mit USB 2.0 implizit auch HighSpeed, da die drastisch gestiegene Datenraten ja der Hauptnutzen aus Anwendersicht sind. Aber es stimmt, richtigerweise müsste man von USB 2.0 HighSpeed reden. > @peterguy Verrätst du mir was du konkret machst? Also mit den Chip von > FTDI Na klar, ist ja kein Geheimnis ;-) Ich baue ein CAN <-> USB Interface. Ich versuche die USB Schnittstelle möglichst generisch zu halten, um spätere Erweiterungen (z.B. LIN oder FlexRay) zu vereinfachen. Deswegen auch die Absicht, die HighSpeed- anstelle der FullSpeed-Bausteine von FTDI zu verwenden.
Gast
#1211343
@Phillip: was mir grade noch einfällt, deine Trigger kommen ja nicht in gleichbleibenden Abständen, oder? Hast du dir schon Gedanken gemacht, wie du das zeitliche Verhalten später im PC nachvollziehen kannst? Im Prinzip bräuchtest du ja so etwas wie einen Zeitstempel.
Der Tackt kommt mit genau 2MHz also 500ns. Aber die Zeitabhängigkeit ist "egal" es kommt nur auf die Daten bei Fallender Flanke auf CLK an. Von daher ist kein Zeitstempel nötig.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.