www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FT2232H USB 2.0 High Speed


Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein Board mit einem FT2232H und einem Spartan 3A. Nun möchte 
ich Ansteuerung für den sync. FIFO Modus erstellen. Der 60MHz Clock vom 
FTDI-Chip geht direkt auf einen GLOCK Pin vom FPGA.

Die Daten vom AD-Wandler habe ich in einem Block-Ram geschrieben. 
Probleme habe ich jedoch bei der Übertragung der Daten vom FPGA zum 
FTDI-Chip.

Die THE# Leitung bereitet mir Bauchschmerzen. Diese Leitung gibt an, ob 
der FIFO vom FTDI-Chip voll ist oder nicht. Wenn der FIFO voll ist 
besitzt die TXE#-Leitung einen High-Pegel.

Hat jemand schon mal die Ansteuerung vom diesem FTDI-Chip hinbekommen?

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ganz ehrlich gesagt kann Dir so kein Mensch weiterhelfen. Wo 
genau ist dein Problem?

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bauchschmerzen hab ich!

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann geh zum Arzt!

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die THE# Leitung bereitet mir Bauchschmerzen. Diese Leitung gibt an, ob
> der FIFO vom FTDI-Chip voll ist oder nicht. Wenn der FIFO voll ist
> besitzt die TXE#-Leitung einen High-Pegel.
Die Beschreibung zum THE-Signal kann ich im DB nicht finden => 
Tippfehler?

> Bauchschmerzen hab ich!
Und weswegen? Du hast zwei Möglichkeiten: Du wertest die TXE-Leitung 
aus, und bist auf der sichersten Seite, oder du ignorierst sie und 
schreibst so langsam, dass trotzdem nix passiert (Möglichkeit drei wär 
noch sie zu ignorieren und so schnell zu senden, dass TXE wieder seine 
Daseins-Berechtigung bekommt, aber wer das macht, ...).

Ralf

Autor: Uwe Bonnes (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ohne FIFO und eine State Machine, die von TXE und Deinem Schreibsignal 
gesteuert wird, wirst Du recht haeufig Aussetzer bekommen. Wenn Deine 
Daten dann groesser als ein Byte sind, kommst Du aus dem Tritte. 
Ausserdem wird irgenwann mal dein PC beschaeftigt sein, dann musst du 
komplette Datensaetz verwerfen.

Ich schreibe etwa jede Mikrosekunde einen Block von 8 16-bit Worten. Das 
erste Wort ist ein Zahler. Wenn beim Einlesen der Zaehler gesprungen 
ist, dann gabe es einen Aussetzer. Seit letzen Donnerstag laeuft die 
Auslese:

362078.08s total time 4804248.334 MiB captured 13585.2 kB/s curr rate 
13587.0 kB/s totalrate 106 dropouts

Die Aussetzer gibt es, wenn ich am PC arbeite. Am unbelastenen PC gibt 
es keine Aussetzter.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja es heist TXE :-)

Ich überlege ob ich den 60 MHz Takt verdoppeln muß ,damit ich nicht 
Daten an den FTDI-Chip sende, obwohl er beschäftigt ist.

Es dürfen keine Daten verloren gehen, daher Buffer ich die Daten 
ausreichend im FPGA zwischen. Wie gut dies funktioniert werde ich dann 
ja sehen.

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, nicht verdopppeln. Aber falls man schreiben wollte und 
zwischenzeitlich TXE ein volles Fifo signalisiert hat, muss man richtig 
handeln.

Ausserdem haben TXE and WR sehr harte Zeitanforderungen, mit einer 
Taktverdoppelung wird das nicht einfacher.

Hast Du den Verilog Code in meinem Posting entdeckt?

Welche Datenrate hats Du? Du musst immer damit rechnen, dass der PC 
gelegentlich fuer 20 oder mehr Millisekunden beschaeftigt ist. In der 
Zeit kann einiges an Daten anfallen, so viel Speicher wirst Du nicht in 
Deinem FPGA haben. Daher brauchst Du auch eine Strategie fuer den Fall, 
dass der Puffer voll ist.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du meinst wirklich das der PC 20ms beschäftigt ist. Das denke ich mal 
ist viel zu lange. Man kann einen eigenen Prozess starten (hohe 
Priorität) so das die Daten regelmäßig übertragen werden.

Wenn ich das richtig verstanden habe, dannkann doch über die SIWUA 
Leitung eine Übertragung erzwungen werden?

Momentan rechne ich mit einer Datenübertragungsrate kleiner 10MByte.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bis jetzt habe ich noch keinen externen SRAM auf meinem Board vorgesehn 
^^

Jedoch habe ich 2 FDTI-Chips am FPGA angeschlosen, so das ich diese zur 
Not parallel benutzen kann.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo ist das Problem? Sobald FIFO voll gemeldet wird, musst du deine 
interne FF-Kette oder was auch immer das auslesen aus dem BlockRAM 
steuert, einfrieren. Wir verwenden Cypress FX2, da geht das genauso. Das 
Timing ist zwar haarig, aber es klappt zuverlässig. Wir haben sogar 
Pausen von bis zu 50ms festgestellt. Wohlgemerkt, wenn der PC "nichts" 
zu tun hat. Wenn da noch andere Anwendungen laufen, wirds noch 
schlimmer. Wir verwenden daher 128k FIFO im FPGA nur für die USB 
Pufferung und erreichen so konstante 40MB/s.

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SIWUA kannst Dui verwenden, wenn der FT eine Transfer anstossen will, 
obwohl sein Puffer voll ist. Aber wenn der PC keine daten anfordert, 
dann hilft das auch nicht.

Das FIFO in meinem Code ist kein externes Ram, sondern ein BRam im 
Spartan6.

Ein PC mit Windows oder Linux ist halt kein Echtzeitsystem.

Autor: Wolfgang R. (portside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welcher Treiber wird im OS benutzt?

Bei USB kann man mit vielen gleichzeitigen asyncronen USB requests z.B. 
100 die dann auch noch minimal  131072 bytes abholen viel erreichen.
Man muss eben sicher sein dass alle USB Frames voll genutzt werden.
Da lassen sich Datenmengen abholen bis der Hautspeicher voll ist ohne 
dass die Anwendung davon was merkt. Eventuell muss man sich dann seine 
eigenen Treiber schreiben aber alles läuft  Interrupt getrieben im 
System ab und die Anwendungen warten. Dann bleibt von der Aussage dass 
Win und Linux kein Echtzeit Betriebssystem sind nicht viel übrig.
Insbesondere dann wenn man beachtet dass Echtzeit OS nix mit 
Übertragungsleistung zu tun hat sondern nur eine Reaktion auf Ereignisse 
in nach vorgeschriebener Zeit verlangt.

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Tests liefen mit dem Code, den ich auf libftdi-1 submitted hatte. 
Ich hatte 256 Requests mit je 4 kByte.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Trotz massiv paralleler asynchroner Anfragen (bis zu 100 Transfers zu je 
128kiByte) kommt es immer mal zu Aussetzern. Weiß der Geier, was Windows 
da tut. Muss man halt ordentlich puffern, dann kann man das überbrücken. 
Da wir auf externe Triggerereignisse reagieren müssen und keinen 
einzigen verpassen dürfen, mussten wir dort massive Pufferung einbauen. 
Dann klappts aber problemlos.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann den kompletten BlockRam des FPGAs nutzen um Daten 
zwischenzuspeichern. Ich schau mal gleich nach wie viel Block Ram der 
FPGA besitzt und wie lange ich dadurch zwischenspeichern kann.

Ich werde mal berechnen wie viel Zwischenspeicher ich für 50ms benötige.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein FPGA besitzt 0,36MBit BlockRam

Mein AD-Wandler digitalisiert mit maximal 8MHz. 1Sample besteht aus 2 
Byte. Demnach habe ich eine Datenfransferrate von 16MByte pro Sekunde 
(128MBit). Der FTDI-Chip soll ja so um die 25MByte schaffen.

Wenn ich also 50ms zwischenspeichern möchte ,dann benötige ich einen 
FIFO mit 400k Speicherzellen je 16Bit. Das ist auf jedenfall zu viel für 
den FPGA

@ Christian

Habe ich das richtig verstanden, das Du einen FIFO mit 128k Werten als 
Buffer benutzt? Damit kannst Du dann aber keine 50ms überbrücken.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:

> Habe ich das richtig verstanden, das Du einen FIFO mit 128k Werten als
> Buffer benutzt? Damit kannst Du dann aber keine 50ms überbrücken.

Richtig. Bei voller Geschwindigkeit reicht das nicht aus. In der 
aktuellen Anwendung haben wir nur eine kontinuierliche Datenrate von 
4...5 MB/s zu garantieren. Das aber eben garantiert über eine komplette 
Messung (7 bis 10 Minuten). Da darf nix verloren gehen. Tuts auch nicht.

Autor: Wolfgang R. (portside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf jeden Fall pro USB Transfer requests  mit jeweils  128k Grösse 
aufsetzen damit der Protokoll Overhead bei USB so gering wie möglich 
ist. Die 128k sind USB spec geschuldet.

Christian hat ja auch über die USB Transfergrösse von 128k gesprochen.

Und immer nur einen USB Kanal pro HUB benutzen

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mein FPGA besitzt 0,36MBit BlockRam

Spricht etwas gegen distributed ram?

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das das teil direkt am Mainboard angeschlossen wird ist es schwer 
herauszufinden wie das Mainboard intern aufgebaut ist. Da die Daten zu 
einem Bild zusammengesetzt werden, dürfen auf keinen Fall Daten verloren 
gehen. Deshalb muß ich mich wohl noch nach größeren externen Speicher 
umschauen. Bis jetzt fand ich immer den DualSRAM von Cypress sehr 
interessant, jedoch ist dieser extrem teuer.

eine Ansteuerung für DDR-Module ist für die kurze Entwicklungzeit zu 
aufwendig, deshalb werde ich mal nach FIFOs suchen.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh man sind die FIFOs teuer. Ich habe einen FIFO von IDT 18M (1M x 18) 
gefunden (kostet ca. 200USD)

Dies ist deutlich zu teuer.

Gibt es nicht einfach anzusteuernden externen Speicher für wenig Geld?

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> Gibt es nicht einfach anzusteuernden externen Speicher für wenig Geld?
Hast Du mal geguckt, was QDR-SRAM kostet?

Duke

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So teuer sind die von IDT aber nicht (wenn man nicht was utopisches 
will).
Ein 72V06 zB kostet ca 14eu , ein 72V285 ca 45eu
(aber evtl sind die neuen XIL-Spart6 günstiger)

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir haben gerade 15k Euro für die Entwicklung des 1. Prototypen Boards 
ausgegeben, da kann ich nicht einfach auf den Spartan 6 wechseln. Ich 
habe mal nachgeschaut es gibt den XC6SLX45-2CSG324C von Xilinx dieser 
besitzt 2MBit BlockRAM. Außerdem ist dieser nicht wirklich verfügbar

Nach QDR-SRAM habe ich momentan noch nicht geschaut.

Wo bekommt man denn den 72V285 für 45€? Die Verfügbarkeit der IDT FIFOs 
ist nicht besonders gut. Ich habe mal bei Digikey und AVNET 
nachgeschaut.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wir haben gerade 15k Euro für die Entwicklung des 1. Prototypen Boards
>ausgegeben
Und jetzt fragst du nach nem Chip? Das weiss man normal vorher.

>Wo bekommt man denn den 72V285 für 45€?
Na die Preise werden sich bei den Distris (evtl Scantec) ja nicht so 
unterscheiden. (zugegeben, IDT ist nicht gerade an jeder Ecke verfügbar)

--könnst aber auch nen grösseren Spart3 nehmen--

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der XC3SD1800A besitzt 1,5MBit (ca. 42€) und der XC3SD3400A (ca. 55€) 
besitzt 2,2MBit internen BlockRAM (kosten unter.

Ich habe auf dem Board nicht so viel externen RAM vorgesehn, da laut 
FDTI bis zu 25MByte pro Sekunde übertragen werden können. Ich habe nicht 
daran gedacht das so lange Datenübertragungspausen entstehen können.

ICH habe noch PSRAM von Micron gefunden. (32MBit für ca 6$)

Hat jemand schon mal so ein PSRAM benutzt? Ich werde mir heute mal das 
Datenblatt durchlesen. Die Ansteuerung der internen BlockRAM FIFOs ist 
natürlich für mich deutlich einfacher zu gestalten.

http://avnetexpress.avnet.com/store/em/EMControlle...

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann nimm doch einfach nen SRAM und schliss den an Spart3 an, und bau 
dann damit n FIFO

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganau daran habe ich auch gerade gedacht. So ein Cypress SRAM kostet 
2,5USB und hat 2MBit. Allerdings muß ich dann einen SRAM-Controller im 
FPGA realisieren.

Ich speicher die Daten vom AD-Wandler in einem FIFO. Wenn dieser 
halbvoll ist dann überträgt der der SRAM-Controller die Daten in den 
externen RAM.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Allerdings muß ich dann einen SRAM-Controller.....
brauchst doch (fast) nur ein SRAM-Adr-Pointer-Reg, das beim Einschreiben 
ins Soft-FIFO, inc wird (und beim Auslesen dec wird) ...........
(Soft-FIFO ist nat. nicht so schnell machbar, wie echtes FIFO, aber es 
wohl in den meisten Fällen reichen)

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Momentan versuche ich mich an der Inbetriebnahme des FT2232H mini Module 
(Evaluatiob Board). Ich habe das FT2232H gekauft. Auf dem IC steht dies 
auch und auf dem Board ebenfalls. Ich benutze den neusten Treiber für 
WinXP. Im Gerätemanager werden jedoch 4 Serielle Ports angezeigt und die 
Bezeichnung laut Vendor ID heist FT4232H.

Dies verstehe ich nicht. Wie kann ich das Module überreden im Sync FIFO 
Modus zu laufen?

Ich habe die WR# Leitung ständig auf GND gelegt, so das unendlich viele 
Daten vom FTDI an den PC gesendert werden müssen. Jedoch kommt einfach 
nichts an. Der Buffer ist immer leer. Ich habe noch nicht die CLK 
Leitung untersucht. Im sync FIFO Modus muß der FTDI Chip einen CLK von 
60MHz erzeugen.

Ich habe das FT_PROG Tool von FTDI bereits heruntergeladen und 
ausprobiert, jedoch kann ich dort nicht den Modus umstellen.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch mal mit der Lupe auf das IC geschaut es ist wirklich der 
FT2232H, jedoch wird durch den Gerätemanager und das FT_PROG der FT4232H 
erkann. So wie es aussieht ist die falsche PID-Nummer auf dem IC oder 
dem externen EEPROM hinterlegt. Daher ist es mir nicht möglich den Modus 
zu ändern.

Wie kann ich denn die PID überschreiben?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:

> Wie kann ich denn die PID überschreiben?

Na mit MProg beispielsweise. Da lässt sich VID/PID ändern.

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mprog.exe auf www.ftdichip.com

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MPROG habe ich bereits uach versucht. Wenn man auf programmieren klick 
dann findet er immer kein gültiges Device.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe es noch mal mit MPROG 3.5 versucht.

Wenn ich ein Template für den FT4232H erstelle und dann auf 
programmieren Drücke erhalte ich folgende Fehlermeldung "Error reading 
device"

Wenn ich ein FT2232H Teplate erstelle und dieses auf den FT2232H 
hochladen möchte erhalte ich folgende Fehlermeldung: "No Devices Found"

Es ist einfach nur die falsche PID Nummer im EEPROM gespeichert. Der 
FT2232H besitzt die PID 6010 und der FT4232 die PID 6011. Deshalb 
erkennt Windows den FT2232 Chip als FT4232 und ich bekomme dies einfach 
nicht weg.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde erst mal ein neues Module bestellen, und hoffen das es damit 
besser geht.

Autor: Wolfgang R. (portside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MProg funktioniert wie die Chips, alles nur zur Hälfte gedacht.

Um MProg zu benutzen muss man etwas spielen, z.B. zuerst File/Open 
anklicken dieses open abbrechen erst dann ist Device/Erase oder Programm 
möglich.

Scan sollte ein Device Zeigen, Tools/Read etc testen.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn icj auf Erase klicke (Mprog 3.5) dann erscheint unten in der Box 
"Erase successful Device 0" Wenn ich dann auf Scan klicke dann erscheint 
folgendes:

Number Of Blank Devices = 1
Number Of Programmed Devices = 0

Was auch immer das Programm mir damit sagen möchte.


Was passiert eigentlich wenn ich den EEPROM vom FTDI-Chip trenne. Wird 
dieser denn mit der richtigen PID erkannt oder steht die falsche PID im 
FTDI-Chip?

Autor: Wolfgang R. (portside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja nun denn, jetzt ist das EEPROM leer und kann neu programmiert werden.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du das EEPROM trennst, wird er sich richtig melden. Die PID ist 
fest im ROM. Aber dann kannst du auch keine neue drauf machen. Aber da 
nun ein blank device ist, kannst du ihn beschreiben. Aber eben mit der 
o.g. Reihenfolge. Ist bissl ulkig gemacht.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang R. schrieb:
> MProg funktioniert wie die Chips, alles nur zur Hälfte gedacht.
>
> Um MProg zu benutzen muss man etwas spielen, z.B. zuerst File/Open
> anklicken dieses open abbrechen erst dann ist Device/Erase oder Programm
> möglich.
>
> Scan sollte ein Device Zeigen, Tools/Read etc testen.


Auch mit dieser Methode funktioniert es nicht.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe ich das richtig das die VIP und PID im FTDI-Chip gespeichert 
werden. Wenn jedoch ein externer EEPROM aneschlossen ist, dann werden 
die Informationen von der PID und VID und die 
Konfigurationsinformationen im externen EEPROM abgespeichert?

Wenn ich dann den externen EEPROM vom FTDI-Chip trennen würde, wird der 
Chip mit Sicherheit als FT2232H erkannt. Ist dann der syn. FIFO Modus 
das Standardmodus ohne externen EEPROM?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn kein EEPROM angeschlossen ist, wird die Standard-Konfig aus dem ROM 
genommen. Ob dann sync FIFO aktiv ist, verrät dir das Datenblatt. Was 
sagt denn FTDI dazu? Die haben einen schnellen und kompetenten Support.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den FTDI-Support habe ich bis jetzt noch nicht angeschrieben, da 
normalerweise die richtige PID im EEPROM steht. Ich denke mal der 
Hersteller der Boards einfach nur die flasche PID ins EEPROM 
reingeschrieben hat und dies nicht so einfach zu beheben ist. Deshalb 
will ich mal 1 neues Board kaufen.

Ich hatte das Board von RSONLINE. Jetzt werde ich mal ein neues bei 
Farnell bestellen. Wenn ich heute mal Zeit habe werde ich auch denn 
EEPROM auslöten

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich habe den EEPROM ausgelötet. Dies hat überhaupt nichts gebracht. 
Der FTDI-Chip wird immer noch als PID 6011 anstelle von 6010 erkannt. 
Nun kann ich nicht mal mehr einen Treiber installieren.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heute habe ich mein 2. 2232H mini Module erhalten. Diesmal habe ich es 
bei Farnell bestellt. Wenn ich das Module das 1. mal an den PC 
anschließe wird die neue Hardware erkannt. Mich macht schon stutzig das 
es als "Quad RS232-HS" erkannt wird.

Wenn ich im Gerätemanager dann die Geräteerkennung anschaue sehe ich 
schon wieder die PID 6011 anstelle der 6010. Demnach hat dieses Module 
das gleiche Problem wie das Andere.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, dann musst du mal den zustöändigen Mitarbeiter bei Farnell anrufen 
und das Problem schildern. Aber die werden ja nicht von Farnell 
programmiert sondern vom Hersteller der Boards. Bei Farnell die kümmern 
sich aber garantiert drum.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt ja sogar bei FTDI eine Applikation Note jedoch werde ich aus 
Dieser nicht besonders schalu

http://www.ftdichip.com/Documents/AppNotes/AN_136%...

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt kann ich nicht mal mehr den Treiber installieren. Immer geht bei 
der Installation etwas schief. Er kopiert die Datein in system32 
Verzeichnis dort sind Sie dann auch.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So den Fehler habe ich gefunden.

Man muß beim VCCIO an 3,3V einspeisen. Ich habe nur den 5V vom USB Bus 
mit dem Sapnnungsregler verbunden. Zusätzlich muß man den Ausgangs des 
3,3V Spannungsreglers auch mit den VCCIO verbinden.

Dann wird der CHIP auf als FT2232H in Windows erkannt.


Jedoch kann ich jetzt auf meinem Notebook nicht mehr den Treiber 
installieren. Die Treiberinstallation erzeugt immer einen Fehler.Ich 
habe schon den FTCLEAN verwendet.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem neuen Treiber 2.08.02 habe ich eine Übertragungsgeschwindigkeit 
in Richutung PC von 40MByte pro Sekunde erreicht.

Autor: Thomas L. (thomers)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Falls der Thread-Ersteller noch mitliest: ich habe derzeit das Problem, 
dass ich mit dem FTDI Morph-IC-II mit einem FT2232H chip und einem 
Cyclone II FPGA keinen Daten-Burst hinbekomme, sondern max. alle 4 Takte 
ein Byte rausschieben kann (da TXE# sofort high geht, sobals WR# low 
geht), und somit nur eine max. Datenrate von 10Mbyte hinbekomme. Siehe 
Beitrag "FT2232H in FT245 FIFO Mode - kein Burst möglich" .
Gibt es die Möglichkeit, den Codeausschnitt, der im FPGA zum 
rausschieben der Daten verantworklich ist (TX state machine), zu 
bekommen? Oder zumindest einen Signalverlauf?
Das würde mir bestimmt helfen.

Gruß

thomers

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]
  • [vhdl]VHDL-Code[/vhdl]
  • [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.