mikrocontroller.net

Forum: FPGA, VHDL & Co. FT2232H Sync FIFO


Autor: Gustl Buheitel (-gb-)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
mir ist klar, dass es ältere Threads zum Thema gibt, aber die haben mir 
nicht wirklich weitergeholfen.

Ich möchte viele Daten über USB ausgeben, lesen ist mir egal, das 
brauche ich nie. Zuerst hab ich versucht die 60 MHz vom FT2232 im FPGA 
zu verwenden, aber die Daten kommen aus einer anderen Taktdomäne. Das 
ist eher kompliziert da den dual-clock-FIFO der ja dann auch einen Takt 
Latenz hat richtig anzuhalten wenn der FT2232H FIFO voll ist, das Timing 
ist halt doch eher hart für mich.

So, jetzt habe ich das versucht indem ich im FPGA nur einen 300 MHz Takt 
verwende. Da kann (so dachte ich) man schön die Flanke der 60 MHz Clock 
erkennen und hat mehrere Takte Zeit Daten auszugeben und vom interen 
FIFO zu lesen. Also man kann in einem Takt prüfen ob der FT2232 FIFO 
nicht voll ist, dann vom FIFO im FPGA ein neues Byte lesen und das 
ausgeben. Eigentlich ganz schick. Habe natürlich auch ne Testbench 
gebaut die wie ich finde gut genug testet. TXE geht zwischen 1 und 7.15 
ns nach CLKOUT auf Low oder High. Was ich nicht ganz verstehe im 
Datenblatt ist das

t14, WR# setup Time to CLKOUT (WR# low after TXE# low)

ist das jetzt die Zeit die WR# vor CLKOUT seinen Pegel geändert haben 
soll oder nach TXE#? Ich mache das so, dass wenn ich eine steigende 
Flanke von CLKOUT erkannt habe, ich WR# entsprechend zu TXE# setze.

Aber natürlich funktioniert das nicht obwohl die Simulation gut 
aussieht. Ich würde mich freuen, wenn da mal Jemand drüberguckt.
Vielen Dank!

: Bearbeitet durch User
Autor: Lars R. (lrs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die Variante mit dem Taktdomain-Übergang ist die einfachere Variante.

Autor: Klakx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde es wahrscheinlich auch mit einem ansynchronem Übergang 
angehen, da bei 300 MHz das "bitgestreichel" schon gut losgeht.

Aber bleiben wir doch mal bei deiner Variante. Wenn du Überabtastung mit 
einer eigenen Taktquelle umsetzt, dann benötigst du einsynchronisierte 
Signale bzw. einen einsynchronisierten Bus. Dies konnte ich auf dem 
ersten Blick nicht erkennen.

Zweitens. Ist deine STA sauber?

Gustl B. schrieb:
> Habe natürlich auch ne Testbench
> gebaut die wie ich finde gut genug testet

:)

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klakx schrieb:
> dann benötigst du einsynchronisierte
> Signale bzw. einen einsynchronisierten Bus.

Wieso? Also ich will damit ja nur Daten zum FT2232 hin ausgeben. Reicht 
es da nicht den 60 MHz Takt zu erkennen? Die anderen Signale verwende 
ich ja nicht direkt sondern immer nur als Enable ... wenn ich das mit 
mehreren FFs einsynchronisiere habe ich doch wieder Latenz. Derzeit 
"lese/sample" ich die Signale vom FT2232 und reagiere darauf indem ich 
selber Signale anlege.

Klakx schrieb:
> Ist deine STA sauber?

Muss ich mir mal angucken ... gab zumindest keinen Fehler bisher.

: Bearbeitet durch User
Autor: Klakx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Wieso? Also ich will damit ja nur Daten zum FT2232 hin ausgeben. Reicht
> es da nicht den 60 MHz Takt zu erkennen? Die anderen Signale verwende
> ich ja nicht direkt sondern immer nur als Enable ... wenn ich das mit
> mehreren FFs einsynchronisiere habe ich doch wieder Latenz. Derzeit
> "lese/sample" ich die Signale vom FT2232 und reagiere darauf indem ich
> selber Signale anlege.

Genau. Vollkommen richtig nur die Flanke zu erkennen und Enables zu 
nutzen. Aber die Flanke muss sauber auf der Taktdomäne sitzen.

Im geposteten Code geht das USB-Takt "CLKOUT" direkt in einen 
kombinatorischen Flankendetektor. D.h. hier sollte input-constraints 
schonmal richtig gesetzt sein, damit es für die STA auch korrekt läuft. 
Metastabilität ist aber eben noch das größere Problem im Flankendetekor.

Das mit der Latenz ist blöd, aber sowas kriegt man bei asynchronen 
Übergängen nunmal irgendwo mit rein. Synchronisier doch CLKOUT bevor es 
in die Logik geht mit 2 FFs auf CLK300. Ggf. müssen noch Eingangssignale 
angepasst/verzögert werden; vielleicht auch nicht.
Bei einem Oversampling von 5 sollte es doch noch nicht so schlimm sein 
zwei Zyklen abzugeben?

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast mir sehr weitergeholfen! Habe mal in der Post-Implementation 
Timing Simulation (wusste gar nicht, dass VIVADO das kann) geguckt, und 
in der Tat, das ist mein Problem.

Klakx schrieb:
> D.h. hier sollte input-constraints
> schonmal richtig gesetzt sein, damit es für die STA auch korrekt läuft.

Constraints habe ich noch nie gebraucht (ausser um die IOs zuzuordnen 
mit Treiberstärke und so) und auch nichts diesbezüglich gelernt, leider. 
Muss ich nachholen.

Klakx schrieb:
> Im geposteten Code geht das USB-Takt "CLKOUT" direkt in einen
> kombinatorischen Flankendetektor.

Das habe ich noch nicht ganz verstanden. Ist das kombinatorisch, weil da 
nur ein FF verwendet wird um den alten Wert von CLKOUT zu speichern und 
dann im Vergleich auch direkt der Wert von CLKOUT verwendet wird ohne 
ein FF dazwischen?
Ob das mit der Latenz der paar Takte gut geht wird sich zeigen, die 
Daten müssen eben rechtzeitig am FT2232 anliegen. Sollte aber 
funktionieren.

Edit: Mit zwei FFs sieht es in der Tat gut aus, nur ist die Latenz 
enorm. Werde mal auf die fallende Flanke triggern, dann sollte es 
passen.

Mir ist auch inzwischen klar wieso das falsch war. Und am Ende war es 
eben Dummheit. Hatte sogar zuerst die Methode von Lothar mit mehreren 
FFs drinnen, aber dann war mir die Latenz zu groß, so dass ich da einige 
rausgeworfen habe. In der einfachen Simulation sah das unverändert gut 
aus ...

: Bearbeitet durch User
Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, also laut Simulation halte ich die Spec vom FT2232 nicht ganz ein, 
da kann TXE# auch noch 7,15 ns nach CLKOUT seinen Pegel ändern, ich 
checke das aber zuletzt grob 6,5 ns nach CLKOUT, aber, jetzt auch 
Hardware macht das keinen Ärger. Ich schaffe fast 42 MB/s ohne Fehler.

Jetzt kommt noch ein FIFO ins FPGA und die Daten werden realistischer 
generiert, also nicht nur ein Zähler wie bisher.

Jedenfalls vielen Dank!

Autor: Mw En (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Das
> ist eher kompliziert da den dual-clock-FIFO der ja dann auch einen Takt
> Latenz hat richtig anzuhalten wenn der FT2232H FIFO voll ist, das Timing
> ist halt doch eher hart für mich.

Der async FIFO kann man im Coregen auch weitere Ausgänge verpassen wie 
"gleuch voll" und/oder "gleich leer".
Ab wann der das dann ausgibt ist auch einstellbar.
Also zB "fast voll" wenn noch 8 Bytes reinpassen.

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist mir klar, aber wenn ich in jedem Takt zum FT232H hin schreibe 
und aus dem FIFO mit einem Takt latenz lese, kann passiert es, dass der 
FT232H das TXE# auf high zieht, ich aber noch einen Takt lang neue Daten 
aus dem FIFO bekomme. Wenn der FT232H dann wieder Daten annimmt, muss 
ich also zuerst die zwei Bytes dorthin schreiben die zuletzt noch aus 
dem FIFO kamen, aber noch nicht gesendet wurden und zwar in der 
richtigen Reihenfolge. Da muss man also Daten noch speichern für den 
Fall, dass der FT232H nixmehr entgegennimmt.

Aber ja, werde ich mal bauen. Das mit den 300MHz macht beim BRAM 
irgendwie Probleme mit dem Timing ...

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Aber ja, werde ich mal bauen. Das mit den 300MHz macht beim BRAM
> irgendwie Probleme mit dem Timing ...

Mittel- und langfristig hast Du mit Deinem bisherigen Ansatz unnötige 
Schwierigkeiten nicht nur dort. Scheinbar bist Du talentiert und befasst 
Dich intensiv damit. Die Frage ist daher, welche essentielle Information 
Dir noch fehlt.

Du kannst kleine Teile des FPGAs (beispielsweise jene, die die state 
machines des besagten Interfaces darstellen) problemlos mit einem 
beliebigen externen Takt (beispielsweise mit dem des Interface-ICs) 
betreiben, insofern dieser sauber genug dafür ist. Ggf kann man ihn noch 
"sauber machen". Die Daten übergibst Du in beide Richtungen über jeweils 
eine FIFO. Siehe Beiträge oben.

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Scheinbar bist Du talentiert und befasst
> Dich intensiv damit.

Vielen Dank! Ist aber nur ein Hobby ... mal gucken, wenn man da als 
Seiteneinsteiger auch an Jobs kommt versuche ich das vielleicht mal. 
Aber zuerst Referendariat zwecks abgeschlossener Berufsausbildung.

> Die Frage ist daher, welche essentielle Information
> Dir noch fehlt.

Eigentlich keine, nur die nötige Zeit. Und dann bin ich eben doch nicht 
allzu schlau ...

Ja, richtig, mein Ansatz ist jetzt die 60 MHz von Extern zur 
Datenausgabe zu verwenden. Da könnte ich noch eine PLL intern drauf 
verwenden, aber der Takt sieht auch so gut genug aus.
Für den Taktübergang habe ich mir jetzt ein Dual-Clock-FIFO erzeugen 
lassen, auf der einen Seite schreibe ich mit den 100 MHz rein die ich 
auch sonst im FPGA verwende und auf der anderen Seite lese ich eben mit 
den 60 MHz.

Jetzt muss ich "nurnoch" die Logik erdenken/beschreiben die auf die 
externen Steuersignale reagiert. Also sowas wie "was passiert wenn ich 
Daten ausgebe, aber TXE# auf High geht?" Die Daten die ich also gerade 
eben angelegt habe an den Ausgang wurden nicht übernommen, die müssen 
gehalten werden und in dem Takt kommen neue Daten aus dem FIFO, die 
müssen auch "gemerkt werden" und dann wenn TXE# wieder Low wird zur 
richtigen Zeit ausgegeben werden. Alles nicht sooo einfach und das 
Datenblatt von FTDI ist im Timing-Diagramm auch nicht sehr hilfreich bei 
den seltsam eingezeichneten Zeiten.
Am Wochenende werde ich da etwas Zeit drauf werfen ...

Edit:
Wieso nicht gleich mit 60 MHz sondern das rumprobiere mit den 300 MHz? 
Mit 60 MHz hatte ich angefangen, das lief auf einem Spartan 6, aber ohne 
Dual-Clock-FIFO und nur mit Testdaten, einem Zähler in der 60 MHz 
Domäne. Mit dem FIFO habe ich das da einfach nicht hinbekommen und auch 
nicht gesehen was nicht klappt. Jetzt verwende ich einen Artix und 
VIVADO, auch da war mir lange nicht klar dass es eine 
Post-Implementation-Simulation gibt (gab es die in ISE?) also hab ich 
zuerst mit 300 MHz angefangen weil ich dachte "da hast du genug Takte". 
Aber jetzt mit der wunderschönen Simulationsmöglichkeit werde ich das 
nochmal mit den 60 MHz testen.

: Bearbeitet durch User
Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei dem beknackten Timing des FT2232B kannst du nur hoffen dass nicht 
beide Werte den Worst Case gleichzeitig annehmen, denn dann hättest du 
für die Kombinatorik aus TXE und deinem Fifo Ready für das Write Enable 
nur 850ps im FPGA incl. IO Delays. Nicht machbar. Da der FTDI auch kein 
programmierbares Fifo Flag hat, ist das eigentlich unbrauchbar. Da kann 
man eben nur hoffen, denn meist klappt es ja.
Wir verwenden u.a. deshalb die Cypress Chips, da hat man selbst beim Fx2 
16 Bit und kann ganz entspannt mit 25MHz fahren und beim FX3, wo die 
Latenz sogar 2 Takte ist kann man die Fifo Flags programmieren. Das 
kriegt man dort alles sauber hin.

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> denn dann hättest du
> für die Kombinatorik aus TXE und deinem Fifo Ready für das Write Enable
> nur 850ps im FPGA incl. IO Delays.

Das verstehe ich nicht. Ich kann doch immer zu jeder steigenden 
Taktflanke vom 60 MHz Takt ein neues Byte anlegen wenn TXE# Low ist. 
Wenn TXE# High ist, muss ich damit aufhören bzw. merken dass gerade nix 
angekommen ist.

Edit: So hatte ich das in Kombination mit dem Spartan 6 gemacht. Da war 
noch kein FPGA-internes FIFO dabei sondern die Testdaten waren nur ein 
Zähler. Aber das hat funktioniert soweit. /Edit.

Der FX2 sieht für mich erstmal komplizierter aus, vor allem auch auf PC 
Seite. Da war der FTDI extrem einfach in C anzusprechen aber der FX2 hat 
da unterschiedliche Endpunkte und lauter Zeug um das man sich kümmern 
muss.

Was ich aber generell nicht verstehe:
Ich mach das nicht weil ich was lernen möchte, sondern weil ich Daten 
über USB ausgeben möchte. Ich würde da auch gerne was für kleines Geld 
kaufen wenn das geht. Klar Lernen ist auch gut und mache ich ja auch 
gerne, aber an dieser Stelle habe ich gerade keine Zeit dazu eigentlich. 
Also wieso haben die Hersteller von den Steinen nix im Angebot für Leute 
wie mich die einfach wollen dass es geht? Ein Stück VHDL und ein Stück 
C. Ist ja nicht so, dass ich hier etwas total exotisches mache, ich will 
ganz normale Funktion des Steins nutzen, das müssen die Hersteller doch 
auch mal gemacht habe.

Aber wie auch immer, jetzt kostet es eben Zeit und ich lerne mal etwas 
(-:

: Bearbeitet durch User
Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Das verstehe ich nicht. Ich kann doch immer zu jeder steigenden
> Taktflanke vom 60 MHz Takt ein neues Byte anlegen wenn TXE# Low ist.
> Wenn TXE# High ist, muss ich damit aufhören bzw. merken dass gerade nix
> angekommen ist.

Ganz genau darum geht es ja. Nur ist die Zeit arschknapp. TXE reagiert 
im Worst Case 7. 15ns nach der letzten Flanke. OK, bleiben von den 
16.66ns noch 9.51 übrig. Dann will WREN aber schon 8ns vor der nächsten 
Flanke den Pegelwechsel im Worst Case haben, dann hast du nur noch 
1.51ns um die Signale im FPGA zu verknüpfen (ich hab oben die 0.66 
unterschlagen und mit 16ns gerechnet), denn du musst ja das WREN inaktiv 
setzen. Klar, man kann jetzt drauf spekulieren dass schon nix passieren 
wird wenn man auf den vollen Fifo noch was schreibt, aber sauber ist das 
nicht. Um die interne Logik des FPGA zu stoppen und das Auslesen aus dem 
internen Fifo anzuhakten, sollte die Zeit aber reichen. Ich denke die 
meisten Designs arbeiten so. Das kannst du mit Constraints abtesten 
lassen.

Der FX2 sieht nur auf den ersten Blick komplex aus, die liefern Firmware 
Beispiele mit, ich hab hier auch schon mal was gepostet an Quellcode. 
Auf der PC Seite kannst du auch dann den WinUSB oder LibUSB Treiber 
benutzen. Nachteil an den Cypress ist dass du eine USB Vendor ID 
brauchst.

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah das meintest Du. OK das mag für Dich nicht sauber sein, aber wird 
sogar im Datenblatt so gemacht, da geht WR# auch erst mit der nächsten 
Taktflanke hoch.
https://www.mikrocontroller.net/attachment/114971/burst.PNG
Das sehe ich mal als Indiz dafür, dass das schon so funktioniert.

Eine USB ID habe ich nicht.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, na schau an. OK, dann scheint also nix zu passieren wenn du den Fifo 
überfüllst. Dann hast du auch mit 60MHz ksin Problem, die 16.66ns - 
7.15ns reichen aus um intern zur Flanke zu stoppen.

Autor: Gustl Buheitel (-gb-)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, zuerst wollte ich alles vom Lesen beim FPGA internen FIFO bis zur 
Ausgabe von den Daten zum FTDI alles in einen getakteten Prozess packen, 
aber das habe ich nicht geschafft weil ich da dann immer Latenz habe und 
echt viele Zustände beachten muss.

Naja, also ... habe ich Kombinatorik dazugenommen. Ist auch schön 
übersichtlich und macht in der Verhaltenssimulation keine Fehler. Aber 
in der Post-Implementation-Timing-Simulation schon, aber selten. Und 
zwar nutze ich ja den externen 60 MHz Takt vom FTDI um intern am 
FPGA-FIFO zu lesen. Und do zwischen ist Latenz zwischen dem externen 
Takt und dann dem tatsächlichen Takt am FIFO. Naja, geht ja auch vom Pad 
erstmal rein in den Stein. Also eine PLL reingebaut. Die lockt auf die 
externen 60 MHz und dann sollte das passen. Jetzt ist es seltsam: Die 
Implementation sagt irgendwas von Timing Violations und zwar ist wohl 
ein Intra-Clock-Path verletzt mit einem Total Negative Slack von 
-947.579 ns. Was soll das? Wo kommt sowas her? Ich habe in meiner .xdc 
nur die beiden externen Takte constraint.
Jedenfalls, trotz des Fehlers habe ich ja eine fertige Implementation 
und jetzt zeigt die Post-Implementation-Timing-Simulation keine Fehler 
mehr, aber weil die PLL Clock minimal Versatz zur externen FTDI-Clock 
hat schaffe ich die 8 ns Setup-Time der Daten und vom WR# nicht, sondern 
nur etwas über 7.

Mal gucken was die Hardware sagt ...

Edit:
Sieht auch gut aus. Getestet mit etwas über 30 MB/s und keine Fehler. 
Aber muss ich mal länger laufen lassen.

Edit2:
Jetzt hab ich die PLL wieder draussen und es gibt auch keine Fehler auf 
Hardware. Das mit der PLL und der Simulation verstehe ich sowieso nicht. 
Ich meine ob jetzt der Takt von extern zu der Logik geht oder aus der 
PLL ist doch egal weil die Latenz zwischen Pad und Logik ja sowieso für 
alle Logikteile gleich ist. Und bei der PLL eben auch.

: Bearbeitet durch User
Autor: Gustl Buheitel (-gb-)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, und hier das Ganze mit dem IP FIFO.

: Bearbeitet durch User
Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, bei den grob 34MB/s wird der FPGA-integre 64kByte FIFO doch manchmal 
voll und es fehlen Bytes. Bei jetzt 25MB/s (ich brauche später nur 
22MB/s) passiert das nur noch extrem selten. Zum Testen habe ich jetzt 
mal grob eine Stunde lang (4000s = 100GByte) Daten zum PC geschickt und 
habe jedes Mal nur so eine Hand voll Fehler bei denen anscheinend der 
FIFO voll war (es fehlen jeweils mehrere Bytes am Stück).

Also sprich ich bin zufrieden, werde aber auch noch unter Linux testen, 
vielleicht sieht es da ja anders aus.

Autor: Klakx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fehler sollten doch eigentlich keine entstehen?

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso nicht? Wenn der PC eine Zeit lang nicht von USB liest läuft intern 
der FIFO voll. Ich erzeuge ohne Unterbrechung Daten weil das später in 
der Anwendung eben auch so seien wird.

Autor: Klakx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso meinst du das. Deine Anwendung auf dem FPGA schreibt da zuviel 
rein. Wenn das erlaubt ist, ok.
Bei Datenübertragung und den Worten Fehler und anscheinend bin ich sehr 
vorsichtig. Wenn sich der Overflow vermeiden lässt,  würde ich lieber 
kontrolliert anhalten.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist denn das für eine Anwendung? Für dauerhaftes Streaming ist BULK 
nicht geeignet. Das geht zwar am schnellsten, aber nur wenn auf dem Bus 
Platz ist. Für Streaming gibts isochronen Transfer. Da bekommst du 
24MB/s garantiert, aber eben keine Datensicherheit.
Kannst oder willst du den Datentransfer nicht anhalten? Wir machen das 
bei uns so ähnlich wie Speicher-Oszi, der Host PC fordert die Daten an, 
und wenn der PC halt beschäftigt ist, wird die Blindzeit zwischen zwei 
Messungen halt größer. Für Dauer-Streaming wirst du auch bei Linux nicht 
mehr Glück haben, USB und insbesondere BULK gibt das nicht her.

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also als Anwendung haben wir an der Uni ein 
Transmissionselektronenmikroskop (TEM). Das rastert mit dem Strahl über 
die Probe und hat also horizontale und vertikale Ablenkspannungen. Diese 
werden in einem Rechner mit einer Karte von NI und leider closed-source 
Software generiert. Die NI-Karte hab ich schon angeguckt und weis auch 
wo ich die 2x16 Bit + 4xClock abgreifen kann die also die Pixeladresse 
auf dem Bild sind. (Ich greife das vor den 2 AD-Wandlern ab). Bei 
sinnvollem Scanning bei dem die Bilder nicht allzu verrauscht sind 
ändert sich die Adresse jede us., also ich bekomme mit 1MHz jeweils 
einen neuen Pixel.

Dann soll ja auch was gemessen werden und zwar mit 8 AD-Wandlern die 
jeweils 16 Bit liefern. Das soll synchron zu dem 1MHz Takt der 
Pixeladresse funktionieren damit ich also zu jedem Pixel so die 
"Farbinformation" bekomme.
So, und dass soll möglichst stumpf zum PC übertragen werden und da sitzt 
dann eine Software die die Daten erkennt und in ein Bildarray schreibt 
oder auch nur auf Platte schreibt und später verrechnet.
Übertragen muss ich die Pixeladresse und die 8x16Bit. Die Pixeladresse 
sind jedoch nicht die 2x16 Bit die an den AD-Wandlern ankommen sondern 
nur jeweils die oberen 11 Bit, denn mehr als 2048x2048 Pixel kann man in 
der Steuersoftware nicht einstellen.
Macht zusammen 2x11Bit + 8*16Bit = 150Bit.
Und damit ich im Datenstrom irgendwie den Anfang und das Ende eines 
Pixels erkennen kann habe ich mir das so gedacht:
Das letzte Bit jedes Bytes ist '0' ausser wenn ein neues Paket anfängt. 
Damit brauche ich dann 22Bytes/Pixel. Macht 22MBytes/s die ich also 
übertragen muss.

Anhalten kann ich nicht, weil ich keinen Zugriff auf die Interna der 
Steuersoftware habe. Aber ist auch egal. Man kann ja erkennen wenn Bytes 
fehlen weil die Pixeladresse nicht schön hochzählt oder sonst wie ein 
Paket unvollständig ist.

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, finde dein Projekt super und will es nicht schlecht reden. Falls 
Du es noch schneller brauchst, dann kannst Du Dir den FT601 anschauen, 
fertigen FPGA Code gibt es wohl auch für Xilinx und Altera.

http://www.ftdichip.com/Products/ICs/FT600.html

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank! Schneller brauche ich das nicht aber ja, der Stein ist 
interessant. Derzeut verwende ich aber nicht den FT232H auf einer 
eigenen Platine, sondern die UM232H wo alles schon fertig drauf ist. Der 
FT232H wäre aber auch selber noch gut auf zweilagig zu layouten. Beim 
FT601 finde ich a) keine kompakte schöne fertige Platine die ich an den 
FPGA stecken könnte und b) sieht das zum selber layouten etwas 
anspruchsvoller aus. Vielleicht mache ich das mal wenn ein neues Projekt 
höhere Anforderungen hat ...

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.