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?
Hallo, ganz ehrlich gesagt kann Dir so kein Mensch weiterhelfen. Wo genau ist dein Problem?
> 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
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.
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.
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.
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.
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.
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.
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.
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.
Meine Tests liefen mit dem Code, den ich auf libftdi-1 submitted hatte. Ich hatte 256 Requests mit je 4 kByte.
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.
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.
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.
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.
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
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.
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?
Johann schrieb: > Gibt es nicht einfach anzusteuernden externen Speicher für wenig Geld? Hast Du mal geguckt, was QDR-SRAM kostet? Duke
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)
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.
>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--
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/EMController/Memory/PSRAM/_/N-100409?action=products&cat=1&catalogId=500201&cutTape=&inStock=&langId=-1&proto=&rohs=&storeId=500201&topSellers=
Dann nimm doch einfach nen SRAM und schliss den an Spart3 an, und bau dann damit n FIFO
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.
>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)
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.
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?
Johann schrieb: > Wie kann ich denn die PID überschreiben? Na mit MProg beispielsweise. Da lässt sich VID/PID ändern.
MPROG habe ich bereits uach versucht. Wenn man auf programmieren klick dann findet er immer kein gültiges Device.
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.
Ich werde erst mal ein neues Module bestellen, und hoffen das es damit besser geht.
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.
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?
Ja nun denn, jetzt ist das EEPROM leer und kann neu programmiert werden.
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.
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.
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?
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.
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
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.
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.
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.
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%20Hi%20Speed%20Mini%20Module%20EEPROM%20Disaster%20Recovery.pdf
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.
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.
Mit dem neuen Treiber 2.08.02 habe ich eine Übertragungsgeschwindigkeit in Richutung PC von 40MByte pro Sekunde erreicht.
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
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.