FPGA ohne Druckerport

schrieb im Newsbeitrag

Eventuel dieser:

Tut es mit diveresen Programmiertools aus der Mikrocontrollerszene. Alles läuft damit jedoch auch nicht.

Etwa 200 Euro

Meine Version von xc3sprog kann auch XC95XL|XV aus dem Jedecfile ueber Byteblaster/DLC5/FTDI-MPSSE und FX2-USRP/XGUFF/(Eigene Protokollerweiterung) flashen. Auch XC3SAN ISF geht, auch Verify, auch Readback.

Braucht zum Kompilieren cmake, libftdi und libftdi, laeuft auch ohne root Zugriff und auch unter win32, mit mingw32 crosskompiliert. Wer Betatesten will bitte Mail an mich, als Betatester sollte man aber auch in Code schauen und ggf etwas reparieren koennen...

PS: Tarfile mit einigen Bitfile Images fuer die ISF Programmierung unter

Den Algorithmus fuer XC2C hab ich mir angeschaut, dass braucht einiges, den zu programmieren. Wohl was fuer lange Winterabende...

Wenn du auf etwas Komfort verzichten kannst, dann kannst du aber auch mit Impact ein SVF File erzeugen und dann eins der vielen JTAG Tools mit SVF Unterstützung zum Programmieren nutzen, bspw. UrJTAG, da solltest du dann auch diverse billige USB Kabel finden.

Grüße, Jan

Ich kann Dir nur weitergeben, was Leute mit was aehnlichem, dem alten Parallelprogrammer von TI (MSP430) erlebt haben und was TI dazu meinte: Ging an "virtuellen" LPT Ports ueber USB Anschluss nicht und TI sagte, das waere allenfalls mit PCMCIA Interface machbar. Also musste ich mir fuer unterwegs einen neuen besorgen, $100 auf die Theke legen.

Moin!

Für USBprog, eine offene Hardware die sich mit diversen Programmer- Firmwares beschicken lässt, gibts einen "XSVF USB Player" - allerdings seit 2007 im Status alpha.

Gruß, Michael.

Das ist ein interessantes Konzept. Vor allem weil man sich damit die Auseinandersetzung mit den internas von Xilinx spart. Ich frag mich nur wie lange es dann dauert ein FPGA zu programmieren.

Ist es bei so einer Anwendung, also einzelne Pegel am Druckerport umschalten, uebehaupt von Bedeutung ob man ein High oder Lowspeed Adapter nachbaut?

Olaf

Redet dein Programm irgedendwie mit Impact? Oder wandelst du auch in diese SVC Files um und uebertraegst dann selber?

Das sollte wohl kein Problem sein. Ich melde mich mal sobald das konkreter wird. Ich muss mir auch noch den Source von dem Japaner mit dem 78K0 Brenner anschauen. Das ist im Prinzip auch nur ein USB-SPI Wandler. Er hat wohl ein Programm cbslrv von

Olaf

Joerg:

Ich habe zwar keine Ahnung, wie Betriebssysteme virtuelle LPT Schnittstellen realisieren, aber wird wohl so sein, daß einfach nur die Standarddatenprotokolle unterstützt werden (die werden ja von Programmieradaptern normalerweise gar nicht benutzt).

Von daher folgende Idee:

Brauche ich eigentlich eh' für's Echtzeit-Debugen, der Datendurchsatz vom Xilinx3-Kabel ist ja nicht wirklich doll, und bei USB-Dingern ist das halt schwierig, die von eigenen Programmen aus zu nutzen (zumal wenns nicht C sein soll).

Gibt's irgendwo einen ECP/EPP => JTAGer fertig?

Gruss

Jan Bruns

libusb-win32 existiert.

Naja, dann...

Gruß Henning

Naja, aber wie spassig ist das denn, sich erstmal in trockene, vermutlich undokumentierte USB-Protokolle irgendeines spezifischen JTAGers reinzufuchsen?

Zumal ich gar keinen USB-JTAGer habe.

Gruss

Jan Bruns

Du hattest doch den Selbstbau vorgeschlagen. Bevor ich heute noch ein Parallelportgerät im CPLD zusammenstricke, nehme ich mir doch lieber einen USB-uC, das Protokoll muss man sich ja dann eh selbst ausdenken.

Ist aber nicht genau das Thema des Threads? (Siehe Subject.)

USB-Druckeradapter sind ungeeignet, spezielle USB-Parallelport-Adapter sind furchtbar lahm

Also dann lieber gleich eine "echte" USB-Lösung. Da reicht womöglich sogar Software-USB im uC mit Low-Speed aus, wenn man keinen Cypress FX2 o.ä. programmieren möchte.

Gruß Henning

Boah, auch das noch. Dann also nicht nur computerseitig selbst am Betriebssystem vorbai USB rumwerkeln, sondern sich auch noch Geräteseitig damit rumärgern? Ich nicht.

Inwiefern? Die sind wie Jörg schrieb ungeeignet, um mit Tools, die dieses Xilinx3 Kabel und sowas zu betreiben.

USB-Druckeradapter sind geeignet, um Scanner-, Drucker-, und andere Datenstrom-Anwendungen zu betreiben.

Genau das ist aber doch eben nicht mein Vorschlag. eben nicht pro Pegelwechsel ein Druckerportzugriff, sondern quasi sowas:

cat some_datafile >/dev/weissichnich dd -if /dev/weissichnich -of some_resultfile -bs=1 -count=dateilaenge

Oder so.

Das ist zwar eine Alternative, aber mein Vorschlag hat den Vorteil, daß man über das Betriebssystem ohne zusätzliche Treiber FileHandles direkt zum Programmieradapter hat.

Gruss

Jan Bruns

Ja, genau.

Nicht einmal das. Die melden sich als USB Printer Class Device an und sprechen mit dem Drucker nur reines IEEE1284, wie in dcoulh festgestellt, funktionieren sie nicht einmal mit alten Nadeldruckern, die die IEEE1284-Kommandos zur Ermittlung von Hersteller- und Produkt-Strings noch nicht unterstützen.

Ok, aber wie willst Du dann das Timing auf dem Parallelport gewährleisten? Da muss dann schon ein Protokoll auf dem Bus her. Gerne mit Paketen via ECP, aber Kommandos wie "D0 high, D1 low, 10 us warten, D2 high, warten bis RDY low mit Timeout 1ms" müssen in Deinem CPLD dann schon verarbeitet werden, da muss also Intelligenz hinein.

Also wenn man's richtig machen wollte, müsste man auch schon ppdev laden und /dev/parportX mit ioctl()s beackern, wie avrdude&Co es tun. Und dann kann man auch gleich die libusb in Betracht ziehen.

Gruß Henning

Naja, es ist vermutlich kein grosses Problem sich selber einen USB-Brenner zu basteln. Jedenfalls wenn man selber schonmal was mit USB gemacht hat. Ich gerade erst noch einen USB9604 gekauft. :-)

Allerdings waere der Witz der ganzen Sache eigentlich das es Xilinxkompatible ist damit man sich die ganzen Zwischenschritte spart. Und dann wuerde die USB Anbindung doch etwas problematischer.

Heh? Wie kommst du auf das duenne Brett? Wenn ich etwas selber machen sollte dann wird es auf jedenfall in C sein etwas anderes ist von vornerrein absurd.

Olaf

Genau da ist das Problem. Wenn man einam so einen Original Xilinx Brenner hat dann schwindet schnell die Motivation das dann noch selber zu machen.

Ich wollte auch mal einen eigenen Adapter fuer das drahtlose Blitzprotokoll von Pentax machen weil deren Preise von Blitzgeraeten so dreist ueberzogen sind, aber wenn man erstmal den 360FGZ rumliegen hat und ja nicht nur das Protokoll auslesen kann sondern halt auch fotografieren kann, dann veschiebt man es auch immer auf demnaechst...

Olaf

Jan Bruns:

Also um das nochmal zuende darzustellen:

Nehmen wir an, der JTAGer erwartet an LPT Eingabedaten mit folgender Struktur:

wobei AA,BB,CC Paare von jeweils gleichzeitig zu sendenden TDI/TMS sind, und XX angibt, ob AA,AABB oder AABBCC gültige JTAG-Daten sein sollen (oder evtl. Betriebsparameter wie bspw. JTAG-Taktrate festlegen).

Der JTAGer sammelt die TDOs in einem RAM, und schmeisst die auf Anfrage raus.

Somit kann man 3 JTAG-Datenbits pro LPT-Byte senden, die zudem mithilfe der ECP/EPP Hardwarebeschleunigung gesendet werden können. Für jedes solche LPT-Byte fielen bis zu 3 Bit TDO-Daten an, die, wenn man die verzögert auslesen will, einen 3/8-tel LPT-Transfer benötigen würden, also insgesamt ein Datendurchsatz von (3/(1+3/8))=2,18 BiDirJTAGBits pro LPT-Transfer (zum Vgl: mit dem Xilinx3-Adapter schafft man bestenfalls 0,33 BiDirJTAGBits pro LPT-Transfer).

Die Kommunikation zwischen JTAGer und Filehandle macht das Betriebssystem, da gibt's nichts zu tun. Der JTAGer selbst hat einfach eine EPP/ECP Schnittstelle, die bestens in einen kleinen CPLD passt (mit der zusätzlichen SRAM-Schnittstelle muss vielleicht eher ein mittlerer CPLD her).

Um SVF abzuspielen braucht man eigentlich gar keine Rückmeldung vom JTAGer, denn SVF/XSVF bieten ja gar keine Möglichkeit, auf diese zu reagieren (abgesehen vom Kompletten Abbruch, der aber prinzipiell verzichtbar ist, solange man eh' immer mit der gleichen Chain arbeitet). Ob's funktioniert hat, kann man hinterher immer noch durch Auslesen der TDOs und den Vergleich mit den SVF-Masken herausfinden. Ein Übersetzer von SVF in das oben beschriebene Beispielprotokoll ist dementsprechend trivial zu schreiben.

Gruss

Jan Bruns

olaf:

Dnn hat man aber das problem, daß es die Xilinx-Software (oder ein Nachbau) ist, die mit dem JTAGer spricht, und das erschwert den Einsatz zum Echtzeit-Debugen (also bspw. über die USER-Register).

Gruss

Jan Bruns

Also habe ich das richtig verstanden, dass Du einen derartigen Adapter dann an einen USB-Drucker-Adapter hängen würdest und dann einfach blind Daten auf /dev/usblp0 schieben würdest? Ok. Würde wohl funktionieren, aber elegant finde ich es immer noch nicht.

Eine kurze Internetrecherche hat ergeben, dass es OpenOCD-kompatible USB-Adapter gibt:

Gruß Henning

Keine Ahnung, habe in dieser Hinsicht wenig Linux-Erfahrung. Aber so oder so ähnlich müsste es eigentlich wohl selbst dann funktionieren, wenn man unbedingt über USB muss (trifft auf mich nicht zu).

Noch nie von gehört, da noch nie einen ARM-Debugger benötigt. Aber das wäre sicher ein leichtes, diesen Debugger kompatibel zu 'ner stinkpiefnormalen Pipe zu machen, oder nicht?

Das mit der Xilinx-kompatiblität ist natürlich echt schade, aber für mich auch egal, da ich froh sein kann, die Xilinx Software auf Kommandozeile (und ohne Programmierfunktionen) auf meinem Debian_64 ans laufen gekriegt zu haben (stumpf über ein chroot auf 'ne Suse32-Partition, musste nur noch /proc dazumounten).

Gruss

Jan bruns