Hallo zusammen, ich habe seit kurzem ein SP601 Board mit einem Spartan6 drauf. Darüber will ich ein Display aus einem alten T40 (1024x768, 6x3bit Farbtiefe) ansteuern. Das Datenblatt habe ich, die Schnittstelle ist lvds und sehr genau beschrieben. Dem Display möchte ich per USB Daten schicken, die dann in einen DDR-2-RAM gepuffert werden. Direkt von usb zum display geht warscheinlich nicht, da usb keinen kontinuierlichen Datenstrom hat. Damit hätte ich drei Programmteile. 1. USB in DDR-RAM 2. DDR-RAM zu lvds 3. Ein DDR-RAM controller, der den RAM praktisch zu einem "Dualport" macht Zu usb habe ich von der von der offiziellen Seite eine Spec, ungefähr 27mb zip. Aber irgendwie werde ich daraus nicht so wirklich schlau. Zum DDR-RAM hat die Ise schon einen IP-Core drin. Es ist der MIG-Core. Dabei entsteht ein Ordner im workspace, mit Beispielcode usw. Da ich jetzt noch nicht so furchtbar erfahren bin, werde ich daraus nicht wirklich schlau. Der Spartan6 hat ja auch einen RAM-Controller, was genau kann/macht der? Dann lvds da gibt's praktisch nichts im Internet dazu, aus dem ich schlau werde. Das Signal ist 7bit lang auf 3 lvds-paaren+ ein PixelClock. Es wäre also praktisch bzw. die einzigste Möglichkeit das ganze in einen Serializer reinzujagen. Da die parallele Datenrate bei ca 50 MHz liegt. Aber wie macht man das? Also parallel in Serializer und dann in den lvds - Reciever. Muss ich da noch was beachten, was ich übersehen habe? Grüße scherzkeks
Damit bekommst du schon mal einen Überblick über die Funktionsweise von USB: "USB in a NutShell - Making sense of the USB standard" http://www.beyondlogic.org/usbnutshell/usb1.shtml
Zur LVDS-Schnittstelle kann ich die Xilinx Application Note XAPP1064 empfehlen, auch die zugehörigen Codebeispiele. Die Video-Anwendung mit 7:1 Serialisation wird darin auch erwähnt und lässt sich sehr einfach implementieren. Zum DDR2: Der MIG-Core nutzt schon dein internen Ram-Controller (Hardmacro) des FPGAs, sollte er zumindestens wenn alles richtig eingestellt wird. Zu den Evalboards gibt es da doch aber Beispiele. Der als Hardmacro im Spartan6 befindliche Ram-Controller ist allein noch nicht wirklich lebensfähig, da müssen noch Funktionen in der normalen FPGA-Logik dazu, die der MIG-Core mit generiert. Die Schnittstelle des MIG-Cores ist für den Anwendungsfall gut geeignet, da hier gleich Multiport-Interfaces angeboten werden. Kann man beim Generieren einstellen, z.B. 2x64Bit oder 6x32Bit Datenbreite. Beim Display bietet sich ein Burst-Transfer in einen BRAM-Fifo an, der dann in die Serializer entleert wird. Siehe hierzu auch Xilinx Userguides ug338 und ug416. USB: Geht soweit ich weiß nur in Verbindung mit einem externen IC der wenigstens den Physical-Layer macht. Gibt es da schon was auf dem Board? Wie schnell sollen die Daten über den USB-Port übertragen werden? Nur ab und an eine Änderung? Oder eher wie ein Videostream?
Danke Beeindruckend schnell! Dann lese ich mich da mal rein. Gibts das auch als fertigen IP-Core? Denn es sollte ja schon etwas länger dauern so ein USB Protokoll zu implementieren vorallem, wenn man VHDL gerade erst lernt. Ich hatte mir das so vorgestellt, dass die LVDS-Schnittstelle zum Display volkommen vom USB abgekoppelt ist. Das das Modul(USB) in die Daten vom PC in den RAM schreibt und das Modul(LVDS) sie wieder liest. Grüße scherzkeks EDIT: Felix schrieb: > Zum DDR2: > Der MIG-Core nutzt schon dein internen Ram-Controller (Hardmacro) des > FPGAs, sollte er zumindestens wenn alles richtig eingestellt wird. Zu > den Evalboards gibt es da doch aber Beispiele. Der als Hardmacro im > Spartan6 befindliche Ram-Controller ist allein noch nicht wirklich > lebensfähig, da müssen noch Funktionen in der normalen FPGA-Logik dazu, > die der MIG-Core mit generiert. > > Die Schnittstelle des MIG-Cores ist für den Anwendungsfall gut geeignet, > da hier gleich Multiport-Interfaces angeboten werden. Kann man beim > Generieren einstellen, z.B. 2x64Bit oder 6x32Bit Datenbreite. Beim > Display bietet sich ein Burst-Transfer in einen BRAM-Fifo an, der dann > in die Serializer entleert wird. > > Siehe hierzu auch Xilinx Userguides ug338 und ug416. Ja das habe ich gesehen mit den Multiport interfaces. Wieso baraucht man da noch einen fifo und kann das nicht direkt in den Serializer rein? Felix schrieb: > Geht soweit ich weiß nur in Verbindung mit einem externen IC der > wenigstens den Physical-Layer macht. Gibt es da schon was auf dem Board? > > Wie schnell sollen die Daten über den USB-Port übertragen werden? Nur ab > und an eine Änderung? Oder eher wie ein Videostream? Das ist ein unkomprimierter Videostream, mit etwa 45Mbyte/s. Theoretisch. 768*1024*18bit*25fps= 44236800mb/s auf dem Board gibt's einen Uart2USB Wandler, der ist aber höchstwarscheinlich zu langsam. Braucht man den externen IC wegen der 5v Toleranz?
:
Bearbeitet durch User
wg. USB: Sehe ich das richtig, dass das SP601 keinen USB-Programmer hat? (wie z.B. mein Digilent Atlys, da ist sowas http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,395,1053&Prod=JTAG-SMT2 gleich auf dem Board. Damit kann ich dann ueber http://www.makestuff.eu/wordpress/software/fpgalink/ auch prima Daten via USB mit dem Board austauschen) Ueber Ethernet ginge auch mit Hilfe eines Softcores, siehe Beitrag "BitHound - FPGA Logic Analyzer" Oder wenn alle Stricke reissen und es schnell genug waere, dann halt die USB/RS232 Bridge
Jetzt kommst du schon Gleich mit Softcores. ;) Auf dem Board ist ein JATAG programmer. Ich fände USB schon gut, wobei das Board auch eine Ethernet schnittstelle hat. Aber von USB haben alle Rechner mittlerweile viele Ports und von Ethernet nur eine. RS232 ist höchstwarscheinlich zu langsam ich weis aber nicht, wie weit man da die Datenraten hochschrauben kann.
*44236800 mb/s!* Das wär verdammt flott, wär ja sogar mit den GTP/GTX der 7er Reihe nicht zu machen. 768*1024*18bit*25fps = 353894400 b/s = 44236800 B/s = ~42,2 MB/s Das ist die Datenrate des Display-Datenstroms. An der Stelle überhaupt kein Problem. Den FIFO zwischen DDR-Controller und Serializer würde ich einplanen, damit der DDR-Ram auch mal beschäftigt sein kann, z.B. durch Refresh oder USB schreiben. Nein den USB-Phy brauchst du sicher nicht nur wegen der 5V-Toleranz. Oben schriebst du, du hast dir die USB-Spec angeschaut? Die Signalisierung auf dem Kupfer ist nicht ganz trivial. Das werden wohl die IO-Zellen des FPGAs nicht alles direkt unterstützen. Chips wären hier FX2 und vergleichbare. UART-zu-USB ist natürlich für die oben genannte Datenrate nicht verwendbar. Die Datenrate ist so schon an der Obergrenze dessen, was über USB2 geht. Da muss die Implementation auf beiden Seiten (PC, FPGA) sauber sein. Ich würde erstmal kleinere Brötchen backen, und das Display samt DDR-Controller aufsetzen. Zum Übertragen von Test-Bilddaten den USB-UART-IC nutzen, dann wird halt der Framebuffer im DDR2 nur langsam gefüllt. Wenn das läuft kann man weiterschauen, da sind genug Fallstricke drin...
Jo Sa schrieb: > Jetzt kommst du schon Gleich mit Softcores. ;) Hardcore User stehen halt auf Softcores :o) > Auf dem Board ist ein JATAG programmer. Der scheint aber nicht per USB angebunden zu sein, oder? Dann vergiss den Link zu Digilent... > Ich fände USB schon gut, wobei das Board auch eine Ethernet > schnittstelle hat. Aber von USB haben alle Rechner mittlerweile viele > Ports und von Ethernet nur eine. Dafuer gibt es 15,- EUR Switches, GBit Eth brauchst du sowieso wohl nicht, 100MBit tut's da auch. Und UDP kannst du komplett in der FPGA-HW loesen (siehe fpga4fun, oder Rene Doss macht da auch mit dem SP601 rum, such' mal hier im Forum). Mit dem Softcore beim Bithound wuerdest du halt auch so Sachen wie DHCP kriegen... > RS232 ist höchstwarscheinlich zu langsam ich weis aber nicht, wie weit > man da die Datenraten hochschrauben kann. Keine Ahnung, hab' ich die letzten 10 Jahre nicht mehr benutzt...
Felix schrieb: > *44236800 mb/s!* > Das wär verdammt flott, wär ja sogar mit den GTP/GTX der 7er Reihe nicht > zu machen. > > 768*1024*18bit*25fps = 353894400 b/s = 44236800 B/s = ~42,2 MB/s Jaja sorry. ;) Felix schrieb: > Das ist die Datenrate des Display-Datenstroms. An der Stelle überhaupt > kein Problem. Den FIFO zwischen DDR-Controller und Serializer würde ich > einplanen, damit der DDR-Ram auch mal beschäftigt sein kann, z.B. durch > Refresh oder USB schreiben. Wieso sollte ein RAM USB schreiben müssen !?! Felix schrieb: > Nein den USB-Phy brauchst du sicher nicht nur wegen der 5V-Toleranz. > Oben schriebst du, du hast dir die USB-Spec angeschaut? Die > Signalisierung auf dem Kupfer ist nicht ganz trivial. Das werden wohl > die IO-Zellen des FPGAs nicht alles direkt unterstützen. Chips wären > hier FX2 und vergleichbare. Wie funktioniert das mit dem Chip genau? Setzt man da ein Bit, wenn man was per USB schicken muss und schickt diese dann mit einem bestimmten Takt als 8/16bit Datenwort? Und der Chip setzt ein bit, wenn ein Datenwort vom PC kommt? berndl schrieb: >> Auf dem Board ist ein JATAG programmer. > Der scheint aber nicht per USB angebunden zu sein, oder? Dann vergiss > den Link zu Digilent... Doch der ist per USB angebunden. berndl schrieb: >> Ich fände USB schon gut, wobei das Board auch eine Ethernet >> schnittstelle hat. Aber von USB haben alle Rechner mittlerweile viele >> Ports und von Ethernet nur eine. > Dafuer gibt es 15,- EUR Switches, GBit Eth brauchst du sowieso wohl > nicht, 100MBit tut's da auch. Und UDP kannst du komplett in der FPGA-HW > loesen (siehe fpga4fun, oder Rene Doss macht da auch mit dem SP601 rum, > such' mal hier im Forum). Mit dem Softcore beim Bithound wuerdest du > halt auch so Sachen wie DHCP kriegen... Ist USB echt so kompliziert?
Jo Sa schrieb: > Wieso sollte ein RAM USB schreiben müssen !?! Da hab ich mich wohl ungünstig ausgedrückt. Ich meinte es anders herum. Der USB will auf den RAM schreiben. In der Zeit, in der der USB schreibt, kann das Display nicht lesen. Wenn der DDR2 im Refresh ist, kann das Display auch nicht lesen. Die FPGA-internen Schnittstellen des MIG-Cores bringen 64-Wort Fifos mit (Datenbreite entsprechend Einstellung, hier 32 oder 64 Bit). Ob diese Speichertiefe für einen ununterbrochenen Datenstrom zum Display reicht, musst du überschlagen. Außerdem: Der separate, größere Fifo vereinfacht das Burst-Lesen aus dem DDR-Ram. Einfach immer 64 Worte am Stück lesen.
Jo Sa schrieb: > berndl schrieb: >>> Auf dem Board ist ein JATAG programmer. >> Der scheint aber nicht per USB angebunden zu sein, oder? Dann vergiss >> den Link zu Digilent... > > Doch der ist per USB angebunden. ja, am Host. Aber wie am FPGA? Siehe http://www.makestuff.eu/wordpress/software/fpgalink/ Die Verbindungen zum FPGA sind das entscheidende. > > berndl schrieb: >>> Ich fände USB schon gut, wobei das Board auch eine Ethernet >>> schnittstelle hat. Aber von USB haben alle Rechner mittlerweile viele >>> Ports und von Ethernet nur eine. >> Dafuer gibt es 15,- EUR Switches, GBit Eth brauchst du sowieso wohl >> nicht, 100MBit tut's da auch. Und UDP kannst du komplett in der FPGA-HW >> loesen (siehe fpga4fun, oder Rene Doss macht da auch mit dem SP601 rum, >> such' mal hier im Forum). Mit dem Softcore beim Bithound wuerdest du >> halt auch so Sachen wie DHCP kriegen... > > Ist USB echt so kompliziert? Siehe http://www.makestuff.eu/wordpress/software/fpgalink/ Ohne uC wird das nix, fuer USB brauchst du ein uC Interface. Damit gehen dann auch 30+ MByte/sec Transfer via PC oder zig MB/Sec via Raspberry Pi...
USB Transfer über den FX2 ist recht einfach im Slave Fifo Modus. Alles was man am PC "reinsteckt" kommt am Fifo Interface des FX2 wieder raus mit Empty Signalen usw. Aber mehr als 40 MB/s sind nicht drin bei USB 2.0 mehr schaffst du zuverlässig und dauerhaft nur mit USB 3.0 dafür gibts den FX3, mit dem gibts auch ein Board für den FMC Anschluss des SP601.
berndl schrieb: > Siehe http://www.makestuff.eu/wordpress/software/fpgalink/ > Ohne uC wird das nix, fuer USB brauchst du ein uC Interface. > Damit gehen dann auch 30+ MByte/sec Transfer via PC oder zig MB/Sec via > Raspberry Pi... wieso wird das ohne uC nichts, ist das Protokoll zu kompliziert für einen FPGA? Christian R. schrieb: > USB Transfer über den FX2 ist recht einfach im Slave Fifo Modus. Alles > was man am PC "reinsteckt" kommt am Fifo Interface des FX2 wieder raus > mit Empty Signalen usw. Aber mehr als 40 MB/s sind nicht drin bei USB > 2.0 mehr schaffst du zuverlässig und dauerhaft nur mit USB 3.0 dafür > gibts den FX3, mit dem gibts auch ein Board für den FMC Anschluss des > SP601. Der FX2 sieht mal echt gut aus. wie läuft das, wenn ich mal was zum PC schicken will? Im datenblatt des FX2 steht: "up to 96Mbyte/s burst rate". Was soll mir das sagen? Sind die 40MB/s im Durchschnitt oder im Peak? Also kann ich mit den Rechnen oder eher nicht. Wird die datenrate in diesem Fall durch den Chip oder durch den PC begrenzt? Ich habe gesehen, dass der FX2 26 GPIO hat. Gibt's den auch ohne dieses Schnickschnack? Dafür in einem Anwenderfreundlicherem Package?
Jo Sa schrieb: > wieso wird das ohne uC nichts, ist das Protokoll zu kompliziert für > einen FPGA? Ja, gibts zwar auch als IP Core, aber nicht gerade billig. Außerdem muss der FPGA erst mal I/Os haben, die 480MBit/s verarbeiten können. Jo Sa schrieb: > Der FX2 sieht mal echt gut aus. wie läuft das, wenn ich mal was zum PC > schicken will? Dann schaltet man einfach die Richtung um, indem man die FIFO-Adresse ändert. Du hast 2 Adress Bits damit kannst du 4 Endpoints adressieren. Das muss natürlich in der Firmware des FX2 eingestellt werden. Jo Sa schrieb: > Im datenblatt des FX2 steht: "up to 96Mbyte/s burst rate". Was soll mir > das sagen? Marketing-Geschwurbel. Das ist die Datenrate, die man zwischen FPGA und FX2 erreichen kann. Denn das Interface kann 16 Bit und 48MHz. Ergibt 96MB/s. Jo Sa schrieb: > Sind die 40MB/s im Durchschnitt oder im Peak? Also kann ich mit den > Rechnen oder eher nicht. Wird die datenrate in diesem Fall durch den > Chip oder durch den PC begrenzt? Das ist fast das maximum was bei USB 2.0 High Speed geht. Denn die Kommunikation läuft in Microframes und Paketen ab. Ein Paket kann maximal 512 Byte fassen, pro Microframe passen 10 bis 11 Pakete rein, je nach Host Controller. Und ein Microframe ist 125µs lang. Mit ein wenig Rechnen kommt man da auf etwas zwischen 39 und knapp 43MByte/s. Das schafft man nur mit ausfreichend Puffer auf beiden Seiten und Übertragung großer Blöcke. Für jeden Transfer geht ein Microframe drauf, und wenn da nur 10 Byte drin sind, dann ist der Rest leer und kann nich anderweitig genutzt werden. Begrenzend ist hier einfach die Architektur von USB. Mit dem FX3 und USB 3.0 Super Speed übertrage ich hier übrigens knapp 320MB/s aus einem FPGA an den PC. Aber das ist dann auch stark abhängig vom verwendeten Host Controller. Das geht von 170MB/s bei AsMedia Schrott über 280MB/s...300MB/s beim TI oder Renesas Controller bis zu 320MB/s am Intel. Für den FX2 hab ich übrigens vor einer ganzen Weile mal eine Beispiel-Firmware hier eingestellt, denn der will auch noch programmiert werden. Musst du über die Suche mal suchen. Jo Sa schrieb: > Ich habe gesehen, dass der FX2 26 GPIO hat. Gibt's den auch ohne dieses > Schnickschnack? Dafür in einem Anwenderfreundlicherem Package? Naja, genauso Marketing, die hat man ja nur wenn man das GPIF nicht voll nutzt. Wenn du 16 Bit Slave FIFO machst, bleibt nicht mehr viel übrig. Für Bastler noch handhabbares Gehäuse ist SSOP56. Allerdings hast du in Verbindung mit dem SP601 ein Problem: Am FMC Stecker haben alle I/Os 2,5V VCCIO, der FX2 kann aber nur 3,3V. Da gibts zwar so einen Mobile Typ neuerdings der auch ab 1,8V kann, aber den gibts nur im BGA Gehäuse.
Christian R. schrieb: > Jo Sa schrieb: >> wieso wird das ohne uC nichts, ist das Protokoll zu kompliziert für >> einen FPGA? > > Ja, gibts zwar auch als IP Core, aber nicht gerade billig. Außerdem muss > der FPGA erst mal I/Os haben, die 480MBit/s verarbeiten können. > Die 480 MBit/s sind dabei noch das kleinste Problem. Da wären dann noch 5V Festigkeit, Clock Data Recovery ...... Deswegen setzen diese IP Cores einen externen ULPI Transceiver vorraus, (z.B. Cypress CY7C68003). Damit ist dann zwar das Handling des physikalischen Interface stark vereinfacht, aber auch das ist nur die erste von vielen Hürden.
Christian R. schrieb: > > Allerdings hast du in Verbindung mit dem SP601 ein Problem: Am FMC > Stecker haben alle I/Os 2,5V VCCIO, der FX2 kann aber nur 3,3V. Das sollte kein Problem sein, ist zwar knapp aber die Pegel sind innerhalb der Spec( Voh - Vih) Ich hatte mal auf einem Prototypen 3.3V auf der FPGA, und 1.8V auf der anderen Seite. Obwohl dabei die Pegel die Spec verletzen, hatte ich keine Probleme. (Der Fehler wurde natürlich für die Serie korrigiert).
Lattice User schrieb: > Die 480 MBit/s sind dabei noch das kleinste Problem. Da wären dann noch > 5V Festigkeit, Clock Data Recovery ...... > Deswegen setzen diese IP Cores einen externen ULPI Transceiver vorraus, > (z.B. Cypress CY7C68003). Damit ist dann zwar das Handling des > physikalischen Interface stark vereinfacht, aber auch das ist nur die > erste von vielen Hürden. Also mit IP-Core wird das dann nichts. Gibt's für den FX2 auch ein Erweiterungsboard für das SP601? Ich habe nix gefunden. Lattice User schrieb: > Das sollte kein Problem sein, ist zwar knapp aber die Pegel sind > innerhalb der Spec( Voh - Vih) > Ich hatte mal auf einem Prototypen 3.3V auf der FPGA, und 1.8V auf der > anderen Seite. Obwohl dabei die Pegel die Spec verletzen, hatte ich > keine Probleme. (Der Fehler wurde natürlich für die Serie korrigiert). Das ist ja mal praktisch. BGA löten kann ich (derzeit) noch nicht. EDIT: Christian R. schrieb: > Jo Sa schrieb: >> Der FX2 sieht mal echt gut aus. wie läuft das, wenn ich mal was zum PC >> schicken will? > > Dann schaltet man einfach die Richtung um, indem man die FIFO-Adresse > ändert. Du hast 2 Adress Bits damit kannst du 4 Endpoints adressieren. > Das muss natürlich in der Firmware des FX2 eingestellt werden. Programmiert oder konfiguriert man den? Ich hab irgendwo gelesen, dass es da eine Software für gibt, mit der man das ganze über den USB Port machen kann.
:
Bearbeitet durch User
Naja, die 2,5V I/Os mit 3,3V zu Überfahren wird auf Dauer auch schädlich sein. Den FX2 kann man auch über USB programmieren oder ein EEPROM anschließen. FMC Board gibts keins wahrscheinlich genau wegen der VCCIO Problematik.
Christian R. schrieb: > Naja, die 2,5V I/Os mit 3,3V zu Überfahren wird auf Dauer auch schädlich > sein. Nein, Laut Spartan6 Datasheet ist Vih max für LVCMOS25 4.1V. (mehr als bei Lattice ECP3 , da sind es nur 3.6V)
Christian R. schrieb: > Den FX2 kann man auch über USB programmieren oder ein EEPROM > anschließen. FMC Board gibts keins wahrscheinlich genau wegen der VCCIO > Problematik. Wozu soll der Eeprom gut sein? Ich dachte der hat schon einen FIFO drin, in den ich einfach daten lesen/schreiben kann? Was passiert eigentlich mit dem Fifo, wenn man schon daten reinschreibt, also FPGA--> PC , aber man donch nicht alle daten gelesen hat, also PC --> FPGA? Werden die DATEN dann gelöscht? Wenn ja, setzt der ein Flag, wenn gerade keine Daten im Fifo sind und man so ohne Bedenken schreiben kann? Was kann man da genau programmieren? Ist das ein vorprogrammierter Microcontroller? Lattice User schrieb: >> Naja, die 2,5V I/Os mit 3,3V zu Überfahren wird auf Dauer auch schädlich >> sein. > > Nein, Laut Spartan6 Datasheet ist Vih max für LVCMOS25 4.1V. > (mehr als bei Lattice ECP3 , da sind es nur 3.6V) Dann ist ja gut.
Jo Sa schrieb: > Christian R. schrieb: >> Den FX2 kann man auch über USB programmieren oder ein EEPROM >> anschließen. FMC Board gibts keins wahrscheinlich genau wegen der VCCIO >> Problematik. > > Wozu soll der Eeprom gut sein? Ich dachte der hat schon einen FIFO drin, > in den ich einfach daten lesen/schreiben kann? Der FX2 braucht eine Firmware, die kanm man entweder über USB laden oder vom I2C-EEProm, für eigene Vendor und DeviceID braucht man den EEProm auch.
Lattice User schrieb: > Jo Sa schrieb: > Christian R. schrieb: > Den FX2 kann man auch über USB programmieren oder ein EEPROM > anschließen. FMC Board gibts keins wahrscheinlich genau wegen der VCCIO > Problematik. > > Wozu soll der Eeprom gut sein? Ich dachte der hat schon einen FIFO drin, > in den ich einfach daten lesen/schreiben kann? > > Der FX2 braucht eine Firmware, die kanm man entweder über USB laden oder > vom I2C-EEProm, für eigene Vendor und DeviceID braucht man den EEProm > auch. Heißt das, dass ich auf jeden Fall einen Eeprom brauche?
Jo Sa schrieb: > Lattice User schrieb: >> Der FX2 braucht eine Firmware, die kanm man entweder über USB laden oder >> vom I2C-EEProm, für eigene Vendor und DeviceID braucht man den EEProm >> auch. > > Heißt das, dass ich auf jeden Fall einen Eeprom brauche? Auf jedem Fall nicht. Ohne EEProm, bzw wenn dieser noch nicht programmiert ist, kommt der FX2 mit seiner eigenen ID hoch. Es gibt einen Treiber der dann die FW lädt und den FX2 zum reenumieren des USB Busses veranlasst. Dieses Reenumieren kann bei Windows Stress machen z.B. wenn man den Rechner nur in Sleep schickt. Auch wenn man mehrere verschiedene Devices hat, die das Verfahren nutzen ist das Chaos unvermeidbar. Der EEProm ist also dringend zu empfehlen. Der wird dich nicht arm machen.
Wenn der FIFO PC -> FPGA (OUT Endpoint) voll ist, kommt nach dem eventuellen Timeout die Schreib-Funktion im API zurück. Genauso, wenn am IN Endpoint keine Daten oder zu wenig vom FPGA anstehen. Dass der S6 so großzügig mit der VIH ist, wusste ich noch gar nicht, wieder was gelernt.
Lattice User schrieb: > Auf jedem Fall nicht. > > Ohne EEProm, bzw wenn dieser noch nicht programmiert ist, kommt der FX2 > mit seiner eigenen ID hoch. Es gibt einen Treiber der dann die FW lädt > und den FX2 zum reenumieren des USB Busses veranlasst. > Dieses Reenumieren kann bei Windows Stress machen z.B. wenn man den > Rechner nur in Sleep schickt. Auch wenn man mehrere verschiedene Devices > hat, die das Verfahren nutzen ist das Chaos unvermeidbar. > > Der EEProm ist also dringend zu empfehlen. Der wird dich nicht arm > machen. Ich hab Linux sieht das da anders aus? Hab ich das richtig verstanden, dass der EEProm nur dazu da ist, um die DeviceID zu speichern? Christian R. schrieb: > Wenn der FIFO PC -> FPGA (OUT Endpoint) voll ist, kommt nach dem > eventuellen Timeout die Schreib-Funktion im API zurück. Genauso, wenn am > IN Endpoint keine Daten oder zu wenig vom FPGA anstehen. Gut, der sagt einem also, was los ist. EDIT: Mir ist noch nicht ganz klar, wozu der Adress Bus gut ist, weil man da drin ja keinen RAM hat, den man adressieren müsste. Sind die dann zur Befehlübermittlung da, oder zu etwas ganz anderem.
:
Bearbeitet durch User
Jo Sa schrieb: > > Ich hab Linux sieht das da anders aus? > Hab ich das richtig verstanden, dass der EEProm nur dazu da ist, um die > DeviceID zu speichern? Nein, man kann da auch die FW speichern. Der FX2 braucht im Gegensatz zu einem FTDI immer eine Firmware. Das braucht dich aber nicht abschrecken, da finden sich viele Beispiele. > > EDIT: > Mir ist noch nicht ganz klar, wozu der Adress Bus gut ist, weil man da > drin ja keinen RAM hat, den man adressieren müsste. Sind die dann zur > Befehlübermittlung da, oder zu etwas ganz anderem. Man kann ja mit dem FX2 noch mehr machen als nur Datentransfer zu einem FPGA. Vielleicht willst du ja auch noch Parameterregister im FPGA implementieren.
Lattice User schrieb: > Man kann ja mit dem FX2 noch mehr machen als nur Datentransfer zu einem > FPGA. Vielleicht willst du ja auch noch Parameterregister im FPGA > implementieren. Was würde das nutzen?
Etwas verspätet. Unter Linux kannst du auch mit dem FX2 arbeiten. Für die Firmware brauchst du dann den SDCC, weil der µC im FX2 ein oller 8051 ist. Als Treiber nimmt man dann üblicherweise libusb und erstellt die passenden udev Regeln. Soweit ich weiß kann libusb auch irgendwie beim Anstecken die Firmware in das RAM des FX2 übertragen, aber wie schon geschrieben, bau lieber ein 64k oder 128k EEPROM dran. Zum Übertragen der Firmware in den RAM oder das EEPROM gibts da so ein Linux Tool FX2loader: http://www.makestuff.eu/wordpress/software/fx2tools/ Achja, für den SDCC musst du dir die angepassten Header und Libs im Netz zusammen suchen. Die sind etwas anders als die für den KEIL Kompiler. Du kannst auch einen FX2 im 56 Pin Gehäuse nehmen, der hat keinen Adressbus, nur den 16 Bit GPIF und ein paar Steuerleitungen.
Christian R. schrieb: > Etwas verspätet. > > Unter Linux kannst du auch mit dem FX2 arbeiten. Für die Firmware > brauchst du dann den SDCC, weil der µC im FX2 ein oller 8051 ist. Als > Treiber nimmt man dann üblicherweise libusb und erstellt die passenden > udev Regeln. Soweit ich weiß kann libusb auch irgendwie beim Anstecken > die Firmware in das RAM des FX2 übertragen, aber wie schon geschrieben, > bau lieber ein 64k oder 128k EEPROM dran. Zum Übertragen der Firmware in > den RAM oder das EEPROM gibts da so ein Linux Tool FX2loader: > http://www.makestuff.eu/wordpress/software/fx2tools/ Achja, für den SDCC > musst du dir die angepassten Header und Libs im Netz zusammen suchen. > Die sind etwas anders als die für den KEIL Kompiler. > > Du kannst auch einen FX2 im 56 Pin Gehäuse nehmen, der hat keinen > Adressbus, nur den 16 Bit GPIF und ein paar Steuerleitungen. Alles klar!
Kannst dir aber auch mal den FT2232H anschauen, da musst du keine Firmware schreiben.
Christian R. schrieb: > Kannst dir aber auch mal den FT2232H anschauen, da musst du keine > Firmware schreiben. Danke, den werde ich mir mal anschauen. Hat der noch irgendeinen Nachteil außer dem etwas unangenemen Package? EDIT: Kann das sein, dass der etwas schwerer zu bekommen ist, wie der FX2?
:
Bearbeitet durch User
Ein Nachteil ist das knackige Timing, da die 60MHz vom Controller kommen und nicht änderbar sind. Bei FX2 kann man auch mit gemütlichen 25MHz und 16 Bit noch die 40MiByte/s auslasten. Beim Treiber bist du halt auf FTDI angewiesen aber das muss ja kein Nachteil sein. Der 2. Kanal am FTDI kann manchmal sehr nützlich sein, und es spart halt Zeit, weil der Controller fest programmiert ist.
Jo Sa schrieb: > Christian R. schrieb: >> Kannst dir aber auch mal den FT2232H anschauen, da musst du keine >> Firmware schreiben. Ich bin bisher davon ausgegeangen dass die FT2232 nur seriell können. Ein Blick ins Datenblatt des FT2232H hat mich eines besseren belehrt. 60 MHz schrecken mich nicht ab. > > Danke, den werde ich mir mal anschauen. Hat der noch irgendeinen > Nachteil außer dem etwas unangenemen Package? Es gibt für den FT2232H fertige Module, erspart einem auch die Beschaffung von USB Buchsen etc. http://www.digikey.de/product-detail/de/FT2232H%20MINI%20MODULE/768-1030-ND/2027252 http://www.elv.de/elv-highspeed-mini-usb-modul-um-ft2232h-komplettbausatz.html
Die 60MHz an sich sind nicht wild, aber die Fifo Flags kommen im Worst Case so spät dass der FPGA nicht mehr schnell genug das TX Enable wegnehmen kann um das Setup Timing einzuhalten.
Christian R. schrieb: > Die 60MHz an sich sind nicht wild, aber die Fifo Flags kommen im Worst > Case so spät dass der FPGA nicht mehr schnell genug das TX Enable > wegnehmen kann um das Setup Timing einzuhalten. Wenn ich mir "Figure 4.4 FT245 Synchronous FIFO Interface Signal Waveforms" im FT2232H Datasheet anschaue sehe ich nicht wo das Problem sein soll. Allerdings sind Datenblätter bei vielen Herstallen etwas creativ, deswegen die Frage hast du das mit dem FTDI schon selbst getestet?
Lattice User schrieb: > Allerdings sind Datenblätter bei vielen Herstallen etwas > creativ, deswegen die Frage hast du das mit dem FTDI schon selbst > getestet? Hier findest du einen älteren Thread zu dem Thema: Beitrag "Timing FT2232H" Meine persönliche Erfahrung mit dem Teil im synchron-parallel Modus: vom Timing-Diagramm her fand ich ebenfalls alles unproblematisch. Im praktischen Aufbau bei hohen Datenübetragungsraten hat mich das Teil schrecklich genervt: egal wie die constraints saßen, es ging immer mal wieder sporadisch ein Byte verloren. Ich hatte damals eins der fertigen Module eingesetzt (UM232H). Vielleicht hat sich auch das nachteilig auf das timing ausgewirkt. Ein schnelles Oszi, mit dem ich ernsthaft die Setup-Zeiten/die Signalintegrität hätte beurteilen können, hatte ich keins zur Verfügung. Seitdem setze ich den FT232H des öfteren im asynchronen-parallel Modus ein. Damit komme ich zwar nur bis ca. 13MByte/s, ab wo das ausreicht läuft es umproblematisch und stabil.
Naja, das Diagramm sieht unkritisch aus. Aber schau mal in die Timing Tabelle. Das TXE Flag hat eine Setup Time von max. 7,15ns und das WR Steuersignal aber mindestens 8 ns. Du hast also im Worst Case im FPAG nur 1,5ns Zeit, das WR wegzunehmen. Sehr wahrscheinlich stört es den FT2232H nicht, wenn du den FIFO überfüllst, aber du musst eben dann im FPGA auch schnell genug auf das TXE ragieren und das Auslesen aus dem FIFO oder was auch immer im FPGA stoppen. Das sollte aber mit den richtigen Constraints gerade eben so gehen. Der FX2 hat übrigens bei den Marketing 48MHz das gleiche Problem, aber den kann man ja mit niedrigerem IFCLK betreiben, dann passt alles. Ich betreibe den mit 25MHz und gebe den Takt negiert aus dem FPGA aus, somit entspannt sich das Timing ungemein. Praktische Erfahrungen hab ich mit dem FT2232H nur, was JTAG und SPI angeht, da wir für schnelles Streaming den FX2 bzw. jetzt den FX3 nehmen. Damals zum Produktstart gabs den 2232H noch nicht. Da war der FX2 der einzige High Speed Controller.
:
Bearbeitet durch User
Christian R. schrieb: > Naja, das Diagramm sieht unkritisch aus. Aber schau mal in die Timing > Tabelle. Das TXE Flag hat eine Setup Time von max. 7,15ns und das WR > Steuersignal aber mindestens 8 ns. Du hast also im Worst Case im FPAG > nur 1,5ns Zeit, das WR wegzunehmen. Sehr wahrscheinlich stört es den > FT2232H nicht, wenn du den FIFO überfüllst, aber du musst eben dann im > FPGA auch schnell genug auf das TXE ragieren und das Auslesen aus dem > FIFO oder was auch immer im FPGA stoppen. Das sollte aber mit den > richtigen Constraints gerade eben so gehen. Wenn ich mir das Timing so anschaue, muss man das WR# erst nach dem nächsten CLK High wegnehmen. Zu beachten ist dann natürlich, dass die Daten in diesem Zyklus nicht geschrieben wurden, man also nicht das nächste Byte aus dem internen FIFO holen darf. Mit etwas Pipelining sollte das aber machbar sein. Ich versuche in solchen Fällen immer Constraints zu vermeiden, mit von Hand instanzierten IOs (am bestem als IDDR und ODDR) kommt man sehr weit und ist vom Routing unabhängig. Davon abgesehen möchte der TO Daten in die andere Richtung übertragen, und da ist das Timing weitaus unkritischer. Insbesondere kann man davon ausgehen, dass wenn RXF# aktiv wird man immer einen ganzen USB Bulk Block lesen kann.
Zusammenfassung: FX2 Vorteil: unkritischeres Timing, flexibel. Nachteil: braucht Firmware FT2232H Vorteil: keine FW, fertige Windowstreiber. Nachteil: schnelleres eventuell kritisches Timing nötig, unflexibel. Es gibt auch sehr günstige FX2 Evalmodule, selberlöten ist erst mal unnötig: http://www.ebay.de/sch/i.html?_trksid=p2050601.m570.l1313.TR0.TRC0.H0.XCY7C68013A+&_nkw=CY7C68013A+&_sacat=0&_from=R40
Danke für die Zusammenfassung. Ich bleibe glaube ich beim FX2 eine Platine muss ich sowieso machen da kommt es auf so einen EEPROM auch nicht mehr an. Wie groß muss der denn so sein? Muss der irgendwie besonders schnell sein? Oder kann ich einfach den billigsten nehmen, den ich finde?
Jo Sa schrieb: > Danke für die Zusammenfassung. > > Ich bleibe glaube ich beim FX2 eine Platine muss ich sowieso machen da > kommt es auf so einen EEPROM auch nicht mehr an. Wie groß muss der denn > so sein? Muss der irgendwie besonders schnell sein? Oder kann ich > einfach den billigsten nehmen, den ich finde? Ist ein I2C EEprom, da gibt es besonders schnell nicht. Irgendein 24C128 mit 3.3V ist ok. Gibt es einen besonderen Grund fürs selbermachen?
Lattice User schrieb: > Gibt es einen besonderen Grund fürs selbermachen? Naja ich möchte zwar auch mit dem Board rumspielen, aber später soll das ganze sowieso mit FPGA und co. auf eine eigene Platine. Das Board will ich nur zum testen verwenden.
:
Bearbeitet durch User
Naja, du musst das ja an den FMC knippern, da musst du ja eine 4 lagen Platine machen. Sonst kommst du vom Stecker kaum weg.
Christian R. schrieb: > Naja, du musst das ja an den FMC knippern, da musst du ja eine 4 lagen > Platine machen. Sonst kommst du vom Stecker kaum weg. Hat jemand gesagt, dass ich das development board dafür verwenden will? Ich wollte eine selbständige platine mit FPGA, Flash, FX2, EEPROM und so weiter machen.
Jo Sa schrieb: > > Hat jemand gesagt, dass ich das development board dafür verwenden will? Indirekt schon: > > Naja ich möchte zwar auch mit dem Board rumspielen, aber später soll das > ganze sowieso mit FPGA und co. auf eine eigene Platine. Das Board will > ich nur zum testen verwenden. Ich lese das so: jetzt ein Adapterboard an das SP601, später wenn alles läuft ein eigenes Board.
Jo Sa schrieb: > Ich wollte eine selbständige platine mit FPGA, Flash, FX2, EEPROM und so > weiter machen. Den Aufwand kannste dir sparen: http://www.ztex.de/index.d.html
Christian R. schrieb: > Den Aufwand kannste dir sparen: http://www.ztex.de/index.d.html Ansich ok aber ziemlich teuer :(. Ab 99 gehts los das ist ein bisschen zu viel.
:
Bearbeitet durch User
Hallo, weil hier die Übertragung mit dem FX2 im Raum steht, eine kurze Bemerkung meinerseits. Ich bekomme mit libusb, einem C Programm und einem FX2 mit SlaveFifo 8 Bit 30 Mhz maximal ~11 MB/s hin. Ich habe aber noch keine umfangreichen Erfahrungen mit FX2 und libusb. Probiert habe ich den syncronen und asyncronen Modus. Unter Linux sind die Werte aber besser. Gruß Alexander
Wahrscheinlich überträgst du pro Transfer nur wenig Daten, du musst du viel wie möglich auf einen Schlag lesen bzw. schreiben. Dann solltest du auch nahe an die 30MB/s ran kommen. Mit nur immer 512 Byte abholen kommt man auf etwa 8MB/s. Wenn du allerdings gleich z.B. 256kB liest, kann der Controller die Microframes voll packen. Wir lesen hier mit WinUSB reichlich 40MiByte/s aus dem FX2 halt mit großen Datenmengen. Und viel Puffer auf dem FPGA. Mit dem FX3 schafft man da reichlich 300MB/s.
Christian R. schrieb: > Allerdings hast du in Verbindung mit dem SP601 ein Problem: Am FMC > Stecker haben alle I/Os 2,5V VCCIO, der FX2 kann aber nur 3,3V. Der FX3 ware hier etwas bequemer, da kannst Du die Bank-Spannung Deinen Bedürfnissen anpassen. Abgesehen davon ist das Firmware-Debugging auf dem FX3 (ARM) etwas fortschrittlicher als auf dem FX2 (80C51). Beim FX2 hast Du bei kleineren Packages unter Umständen nicht mal ne Debug-UART weil Du Deine Pins anderweitig brauchst...
Ich denke ich bleib beim FX2 der FX3 ist mir noch eine Nummer zu groß. So viel datendurchsatz brauche ich nicht. EDIT: Ist sowas als Testumgebung ok? http://www.ebay.de/itm/CY7C68013A-56-EZ-USB-FX2LP-USB-2-0-Develop-Module-Logic-Analyzer-EEPROM-hv2n-/301006996484?pt=LH_DefaultDomain_77&hash=item46156a4404
:
Bearbeitet durch User
Jo Sa schrieb: > Ich denke ich bleib beim FX2 der FX3 ist mir noch eine Nummer zu groß. > So viel datendurchsatz brauche ich nicht. > > EDIT: > Ist sowas als Testumgebung ok? > > http://www.ebay.de/itm/CY7C68013A-56-EZ-USB-FX2LP-USB-2-0-Develop-Module-Logic-Analyzer-EEPROM-hv2n-/301006996484?pt=LH_DefaultDomain_77&hash=item46156a4404 Ist nicht teuer, wenn es nicht klappt ist es kein Beinbruch. Hast du ein Breakout Board für den FMC Connector auf dem SP601? z.B. http://www.xilinx.com/products/boards-and-kits/HW-FMC-XM105-G.htm (das wiederum IST teuer) Für die Verbindung von solchen Boards, d.h. Pfostenleiste -> Pfostenleiste, haben wird uns mal 10 cm lange Flywires machen lassen. (4 versch. Farven, 3 verschiedene Stecker/Buchse Varianten. Wenn man weiss was man tut, erreicht man damit auch hohe Datenraten.
Lattice User schrieb: > Ebay-Artikel Nr. 301006996484 > > Ist nicht teuer, wenn es nicht klappt ist es kein Beinbruch. Dann werde ich das mal probieren. Lattice User schrieb: > Hast du ein Breakout Board für den FMC Connector auf dem SP601? > z.B. > http://www.xilinx.com/products/boards-and-kits/HW-FMC-XM105-G.htm > > (das wiederum IST teuer) > > Für die Verbindung von solchen Boards, d.h. Pfostenleiste -> > Pfostenleiste, haben wird uns mal 10 cm lange Flywires machen lassen. (4 > versch. Farven, 3 verschiedene Stecker/Buchse Varianten. > > Wenn man weiss was man tut, erreicht man damit auch hohe Datenraten. Das finde ich ziemlich unverschämt teuer. Ich habe auch schon nach so einem Board gesucht, die waren aber alle so teuer. Wieso? Da ist ja nix drauf. Einen FMC Stecker finde ich aber auch nicht, um sowas aufzubauen.
Jo Sa schrieb: > Einen FMC Stecker finde ich aber auch nicht, um sowas aufzubauen. Ist öfters mal ein Thema Beitrag "Re: FMC Stecker Spartan 6 SP 601" Beitrag "Re: Spartan-6 FPGA SP605 Evaluation Kit Externer Connector" Google: SP601 FMC SP605 FMC
Naja, ist halt schon etwas Aufwand. Ich glaube die Extension Card hat 6 oder mehr Lagen, das kostet halt in den kleinen Stückzahlen. Wir haben auch mal ein Testboard mit FMC gemacht, unter 4 Lagen kommt man da halt leider nicht weg. Und dann halt Schablone und Lötpaste. Das FX2 Board ist in Ordnung, wir haben ein paar von Brain Tech rumliegen, da ist ja selbst das China Teil offensichtlich viel besser entworfen. Funktionieren tun die aber auch.
Jo Sa schrieb: > Einen FMC Stecker finde ich aber auch nicht, um sowas aufzubauen. http://shop.collion.de/FMC/Vita-57-FMC-LPC-connector-male-ASP-134604-01.html
Wieso baraucht man da so viele Lagen. Der Stecker hat 4 Reihen mit pins. Da sollten (theoretisch) 2lagen reichen, wenn man auch so technische spielereien, wie auf der Degug card verzichtet. Oder?
Naja, wenn du das zwischen den Pins durchgefädelt bekommst, und es auch egal ist, dass du nach zwei Seiten wegmusst, dann gehts vielleicht auch mit 2 Lagen. Timing wird dann halt ungünstig, LVDS geht natürlich dann auch nicht. Die Pads am FMC sind halt ziemlich groß, da ist nicht viel Platz dazwischen.
Impedanzkontrolle ist mit 2 Lagen auch nicht wirklich möglich. Der Stecker ist halt darauf ausgelegt, dass man das ohnehin machen möchte. Ich mag diesen Stecker auch nicht - das macht einfache Tests unnötig teuer. Auf den Boards mit FMC gibts ja leider oft kaum andere Anschlussmöglichkeiten für langsamere Sachen...
Naja, wenn man das professionell betreibt, kauft man sich einmal died Debug Card und fertig ist.
Christian R. schrieb: > Naja, wenn du das zwischen den Pins durchgefädelt bekommst, und es auch > egal ist, dass du nach zwei Seiten wegmusst, dann gehts vielleicht auch > mit 2 Lagen. Timing wird dann halt ungünstig, LVDS geht natürlich dann > auch nicht. Die Pads am FMC sind halt ziemlich groß, da ist nicht viel > Platz dazwischen. Wenn man die inneren zwei Pinreihen durchkontaktiert, und an der Unterseite weiter führt, müsste es noch gehen. Ich hatte noch eine Idee/Hirngespinst: Wenn man direkt auf den FMC-Stecker, also nicht der auf dem Board, einen Pfostenstecker mit dem gleichen Footprint löte, müsste das doch gehen... Bei solchen waghalsigen Konstruktionen, stellt sich mir aber auch die frage, ob man das Board durch einen Kurzschluss am Stecker schrotten kann. Oder ob da einfach ein Überlastungschutz angeht und gut ist.
Muss man unbedingt alles kontaktieren? Wenn man nur die H Reihe benutzt (bei den anderen nur GND verbindet) hat man 1 Clock und 11 LVDS oder 22 LVCMOS, für Experimente mit dem FX2 reicht das. Das nächste Problem ist das Auflöten, mit Lötkolben geht es nicht. Wie gross sind eigentlich die Pads, und welches Raster haben sie?
Christian R. schrieb: > Naja, wenn man das professionell betreibt, kauft man sich einmal died > Debug Card und fertig ist. Die $160 sehen teuer aus, aber nur bis man anfängt nach entsprechenden Boards von 3rd Party Herstellern zu suchen.
Lattice User schrieb: > Das nächste Problem ist das Auflöten, mit Lötkolben geht es nicht. Irgendwie geht das schon mit Heisluft oder so, das ist ja kein empfindliches Bauteil. Lattice User schrieb: > Wie gross sind eigentlich die Pads, und welches Raster haben sie? Würde mich auch interessieren, dazu habe aber nichts gefunden. Lattice User schrieb: > Die $160 sehen teuer aus, aber nur bis man anfängt nach entsprechenden > Boards von 3rd Party Herstellern zu suchen. Mag sein, dass das ein gutes preis/leistungsverhältnis hat, ist aber für mich als Schüler nicht zu bezahlen, vor allem, weil die anderen Elektronikspielereien auch nicht ganz umsonst sind.
Jo Sa schrieb: > Lattice User schrieb: >> Das nächste Problem ist das Auflöten, mit Lötkolben geht es nicht. > > Irgendwie geht das schon mit Heisluft oder so, das ist ja kein > empfindliches Bauteil. Da wäre ich mir jetzt nicht so sicher, wenn sich der Stecker verzieht und deswegen nicht mehr passt, hast du auch nichts davon. > > Lattice User schrieb: >> Wie gross sind eigentlich die Pads, und welches Raster haben sie? > > Würde mich auch interessieren, dazu habe aber nichts gefunden. > Du hättest aber an deinem SP601 nachmessen können. Trotzdem hier ein Link http://www.samtec.com/standards/vita.aspx (Vita 57 ist was du suchst) Pin Abstand ist 1.27 mm, Pfostenleisten (2.54 mm) direkt anlöten ist da nicht. > > Mag sein, dass das ein gutes preis/leistungsverhältnis hat, ist aber für > mich als Schüler nicht zu bezahlen, vor allem, weil die anderen > Elektronikspielereien auch nicht ganz umsonst sind. Es wäre gut, wenn so das nicht nur unterschwellig sondern von Anfang an klar ausgedrückt wird. Mal eine Idee zur Bastellösung: Laborkarte mit 1.27 Raster, 2 seitig durchkontaktiert. http://www.reichelt.de/Laborkarten/RE-435LF/3/index.html?&ACTION=3&LA=2&ARTICLE=34775&GROUPID=3374&artnr=RE+435LF Zum Auflöten des Steckers brauchts du auch Lötpaste, und zwar reichlich da es diese in die Durchkontaktierungen zieht. Löten mit Heisslust, oder mit viel Geduld und Vorsicht von der anderen Seite der Platine und Lötkolben. Wenn der Stecker erfolgreich aufgelötet ist, mit Fädeldraht die nötigen Signalleitungen zum 2.54 raster Bereich verbinden, Alle GNDs als Lötwürste. Aber: Ein Fehlversuch ist teuer (ca 30€ Platine + Samtec Stecker).
Lattice User schrieb: > Pin Abstand ist 1.27 mm, Pfostenleisten (2.54 mm) direkt anlöten ist da > nicht. Gibt es keine Pfostenleisten mit 1,27? Lattice User schrieb: > Aber: Ein Fehlversuch ist teuer (ca 30€ Platine + Samtec Stecker). Die Platine Kostet bei Reichelt 10€.
Jo Sa schrieb: > Lattice User schrieb: >> Pin Abstand ist 1.27 mm, Pfostenleisten (2.54 mm) direkt anlöten ist da >> nicht. > > Gibt es keine Pfostenleisten mit 1,27? Gibt es, da hört es aber nicht auf. Du braucht dann auch etwas zum Draufstecken, z.B. Flywires mit Buchsen auf der einen Seite passend zu den dünnen Stiften der 1.27 mm Pfostenlesite und auf der anderen Seite zu den 2.54 mm auf der FX2 Platine. > > Lattice User schrieb: >> Aber: Ein Fehlversuch ist teuer (ca 30€ Platine + Samtec Stecker). > > Die Platine Kostet bei Reichelt 10€. Plus 20€ für den Samtec Stecker.
Lattice User schrieb: > Gibt es, da hört es aber nicht auf. Du braucht dann auch etwas zum > Draufstecken, z.B. Flywires mit Buchsen auf der einen Seite passend zu > den dünnen Stiften der 1.27 mm Pfostenlesite und auf der anderen Seite > zu den 2.54 mm auf der FX2 Platine. Man könnte auch eine Buchsenleiste nehmen, da kann man mit diesen Kabeln für die Steckplatinen direkt weg.
Jo Sa schrieb: > Lattice User schrieb: >> Gibt es, da hört es aber nicht auf. Du braucht dann auch etwas zum >> Draufstecken, z.B. Flywires mit Buchsen auf der einen Seite passend zu >> den dünnen Stiften der 1.27 mm Pfostenlesite und auf der anderen Seite >> zu den 2.54 mm auf der FX2 Platine. > > Man könnte auch eine Buchsenleiste nehmen, da kann man mit diesen Kabeln > für die Steckplatinen direkt weg. Nur haben die Buchsenleisten für 1.27 mm kleinere Kontakte. Und Kabel für 2.54mm sind auch zu dick, so dass man keine 2 nebeneinander an 1.27mm bekommt. Deine Lötkünste musst du selber einschätzen, mach aber erst mal Lötversuche bevor du den teuren Samtec Stecker riskierst. Gilt auch für die von mir vorgeschlagene Variante. (z.B. mit SOT-23 oder SOIC-8 Bausteilen auf der Reicheltplatine) Wöruber man auch nachdenken sollte, ist die mechanische Stabilität, es machtr sicher keinen Spass wenn nach nur wenigen Steckzyklen das ganze wieder auseinander fällt.
Lattice User schrieb: > Deine Lötkünste musst du selber einschätzen, mach aber erst mal > Lötversuche > bevor du den teuren Samtec Stecker riskierst. Gilt auch für die von mir > vorgeschlagene Variante. (z.B. mit SOT-23 oder SOIC-8 Bausteilen auf der > Reicheltplatine) Ich habe schon SOIC-8 gelötet, das dürfte mir aber nicht so viel bringen, da bei dem Stecker die Kontakte unter dem Gehäuse sind und ich die damit ganz anders löten muss. Lattice User schrieb: > Wöruber man auch nachdenken sollte, ist die mechanische Stabilität, es > machtr sicher keinen Spass wenn nach nur wenigen Steckzyklen das ganze > wieder auseinander fällt. Da hab ich mir auch schon Gedanken drüber gemacht, bin aber zu keiner Lösung gekommen. Das ist aber auch bei industriell gelötetem SMD so. Hier sind einfach die Vorteile von DIL.
Hier kannst du mal gucken: http://danstrother.com/2010/12/04/fmc-lpc-to-sata-adapter-board/ Handlöten ist echt nicht drin. Ansonsten gibts noch die Platte von AD: http://www.digikey.com/product-detail/en/AD-DAC-FMC-ADP/AD-DAC-FMC-ADP-ND/2700515 ist etwas günstiger.
Christian R. schrieb: > Hier kannst du mal gucken: > http://danstrother.com/2010/12/04/fmc-lpc-to-sata-adapter-board/ Würde mir das Sata board was bringen? Ich habe auch keine Moglichkeit gefunden die platine für das SATA-Board zu kaufen. Christian R. schrieb: > Ansonsten gibts noch die Platte von AD: > http://www.digikey.com/product-detail/en/AD-DAC-FMC-ADP/AD-DAC-FMC-ADP-ND/2700515 > ist etwas günstiger. Das ist auch nicht arg viel günstiger, wie die Debug-Card. :/
Jo Sa schrieb: > Ich habe schon SOIC-8 gelötet, das dürfte mir aber nicht so viel > bringen, da bei dem Stecker die Kontakte unter dem Gehäuse sind und ich > die damit ganz anders löten muss. Dazu hatte ich oben einen Vorschlag gemacht, Nochmal: Lötpaste auf die Bestückungseite, die Hitze von der anderen Seite der 1.27 Laborkarte zuführen. Da die Durchkontaktierungen nicht mit einer Plane verbunden sind, hält sich der Wärmeverlust in Grenzen. Und genau das vorher mit dem SOIC-8 ausprobieren, von oben kann den jeder Löten. > > Lattice User schrieb: >> Wöruber man auch nachdenken sollte, ist die mechanische Stabilität, es >> machtr sicher keinen Spass wenn nach nur wenigen Steckzyklen das ganze >> wieder auseinander fällt. > > Da hab ich mir auch schon Gedanken drüber gemacht, bin aber zu keiner > Lösung gekommen. Das ist aber auch bei industriell gelötetem SMD so. > Hier sind einfach die Vorteile von DIL. Auch da hast du mich missverstanden, wenn man am Samteck Stecker alle 160 Pads industriell lötet ist das Bombenfest. Pfostenleisten direkt an die Pins zu löten sind es eben nicht. Auch bei der Variante mit der Laborkarte fallen die Zentrierzapfen weg und damit ein Stabilisierungselement.
Lattice User schrieb: > Dazu hatte ich oben einen Vorschlag gemacht, Nochmal: > Lötpaste auf die Bestückungseite, die Hitze von der anderen Seite der > 1.27 Laborkarte zuführen. Da die Durchkontaktierungen nicht mit einer > Plane verbunden sind, hält sich der Wärmeverlust in Grenzen. > Und genau das vorher mit dem SOIC-8 ausprobieren, von oben kann den > jeder Löten. Ok da habe ich dich missverstanden. Dann Probiere ich das mal. Lattice User schrieb: > Auch da hast du mich missverstanden, wenn man am Samteck Stecker alle > 160 Pads industriell lötet ist das Bombenfest. Pfostenleisten direkt an > die Pins zu löten sind es eben nicht. Auch bei der Variante mit der > Laborkarte fallen die Zentrierzapfen weg und damit ein > Stabilisierungselement. Ich hatte mal eine platine mit industriell gelöteter USB-Buchse, die nach ziemlich kurzer Zeit abgegangen ist. Der Samteck-Stecker hat natürlich ein paar Pins mehr.
Jo Sa schrieb: > industriell Oder vielleicht doch nur unterhaltungsindustriell?! Unsere Jungs stöhnen zwar auch immer über den FMC-Stecker, aber bisher habe ich noch keine Ausfälle beobachtet. Wir verwenden dazu Paste und eine Maske. Duke
Jo Sa schrieb: > Ich hatte mal eine platine mit industriell gelöteter USB-Buchse, die > nach ziemlich kurzer Zeit abgegangen ist. > Wenn der Layouter Mist baut (zu kleine Pads für das Gehäuse?) hilft auch der beste Lötprozess nichts.
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.