Wer hat Lattice-Programmierung mit ispVM und Parallelport-Kabel unter Linux am Laufen?

...

Lasse das Programm mit "strace -f -o laufen, und suche nach dem Lauf z.B. mit grep nach dem Teil, wo die parallele Schnittstelle geoeffnet wird und versuche zu verstehen, warum was nicht geht.

Tschues

parport_pc ist nur der Low-Level Treiber. Fuer das Device /dev/parport0 ist der Treiber ppdev zustaendig. Pruefe als erstes ob auch der geladen ist bzw. geladen wird.

Hier sieht das so aus:

---------------------------------------------------------------------- # dmesg | grep -e parport -e ppdev parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP] ppdev: user-space parallel port driver

----------------------------------------------------------------------

Micha

Ich habe hier ein selbstgebautes Lattice Kabel, das auf meinem alten Rechner mit dem alten 14.3er ispVM erkannt wird: "ispDOWNLOAD(TM) Parallel cable Verison 2.0 Detected."

Auf meinem neuen Rechner (Debian Lenny AMD64) hatte ich mit der 17.9er ispVM aber leider auch keinen Erfolg.

Starte ich ispvm per sudo als root, erkennt ispvm wenigstens die Adresse der Parallelports (separate PCI Karte) richtig, cable detect geht aber schief :-(

Du könntest mal versuchen per strace der Sache auf den Grund zu gehen und den Lattice Support zu kontaktieren. Vor 5-6 Jahren hatte das recht gut geklappt, ispvm griff unabhängig von der Einstellung der Parallelports immer auf parport0 zu, der Support hat meinen Bugreport entgegengenommen und ispvm sogar gefixt.

Alternative: nimm UrJTAG

Irgendwann war es mir zu blöd mich dauernd mit impact, ispvm & Co rumzuärgern, selbstverständlich will natürlich die Xilinx Software kein Lattice Kabel und umgekehrt.

Mit UrJTAG läuft das alles sehr fein, vor allem kann ich mit meinem Lattice Kabel auch problemlos Xilinx XC95... programmieren :-) Achja, und avrdude liess sich auch recht einfach auf das Lattice Kabel konfigurieren, Xilinx und BSD Kabel setzen jetzt Staub an.

Um UrJTAG zum Laufen zu kriegen brauchst Du nur noch die BSDL Files von der Lattice Website. Wirf die in ein Verzeichnis und setze in UrJTAG den bsdl path da drauf. Bei mir sieht das zB am neuen Rechner so aus:

jtag> cable Lattice ppdev /dev/parport0 Initializing ppdev port /dev/parport0 jtag> bsdl path /home/hias/private/electronics/lattice/bsdl jtag> detect IR length: 6 Chain length: 1 Device Id: 00010111010010000010000101010111 (0x17482157) Filename: /home/hias/private/electronics/lattice/bsdl/m4a64p.bsm

Das "cable" und "bsdl path" steht bei mir in ~/.jtag/rc, aber Vorsicht, die Datei wird nur dann ausgewertet wenn Du UrJTAG interaktiv verwendest.

Zum Programmieren brauchst Du die Logik im SVF Format, ich mach das inzwischen automatisiert per shell-script, die ewige Klickerei in impact (oder ispVM) ist recht nervig.

Das shellscript zum programmieren sieht bei mir so aus:

#!/bin/sh

if [ $# -ne 1 ] ; then echo "usage: $0 svf-file" exit 1 fi

jtag

Also schrieb Matthias Reichl:

Das werde ich mal versuchen.

Das wäre komplettes Neuland. Nicht uninteressant, aber mglw. zeitintensiv, das produktiv hinzubekommen...

? Ich will eigentlich (erstmal) keinen Boundary Scan machen... braucht man die auch zum normalen Programmieren? Ist das sozusagen die Device Database, oder was? Muss da wohl mal wühlen gehen - oder hast Du einen direkten Link, bevor ich mir den Wolf suche?

OK...

... aber wie komme ich von XCF zu SVG? ;)

Danke für Deine ausführliche Antwort! Hab mir das mal gut aufgehoben. :)

Ansgar

./configure ; make ; sudo make install ; echo "fertig :-)"

Im Ernst: Am Anfang hab' ich auch etwas gebraucht um es zum Laufen zu kriegen, aber Du brauchst wirklich nicht mehr als ich geschrieben habe. Ist wahrscheinlich einfacher als ispVM zum Laufen zu kriegen.

Ja, die braucht man auch zum Programmieren.

So in etwa. Da steht alles drin (Boundary Scan Register etc.) was die JTAG Software über den Chip wissen muss um ihn per JTAG ansprechen zu können.

Auf der Lattice Website: Download->BSDL Models

Klar, dafür brauchst Du ispVM bzw impact. Zumindest impact lässt sich recht leicht im Batch-Mode aufrufen, mit ispVM sollte das evtl. auch gehen (hab' schon länger nichts mehr mit der Lattice Software gemacht).

Bei impact geht's zB mit folgendem impact batch File (Aufrufen mit "impact -batch batchfile"):

setMode -bs setCable -port svf -file myfile.svf addDevice -p 1 -file myfile.jed Program -p 1 -e -v Quit

Das macht aus myfile.jed ein myfile.svf. Parameter / Kommandos natürlich ggf. anpassen

Gerne!

Und, wie gesagt, keine Angst, das ist wirklich nicht so kompliziert.

so long,

Hias

Also schrieb Michael Baeuerle:

Hm. ppdev wäre bei mir auch geladen. Allerdings scheine ich eine udev-Regel zu brauchen, um die Berechtigungen für /dev/parport0 dauerhaft auf 666 zu setzen... hab nur von der udev-Syntax keine Ahnung...

Wie kriege ich denn aus der strace-Ausgabe die *relevanten* Teile raus? Was ich bisher sehen konnte, war, dass /dev/parport0 wohl erfolgreich geöffnet werden kann (ich hatte die Rechte zuerst nicht richtig gesetzt, dann kam an gleicher Stelle ein "Permission denied"), aber irgendetwas unter /proc bzw. /sys nicht so ist, wie die Software das gern hätte. Das mag auch ganz leicht sein, denn Lattice gibt an, das Zeugs nur unter RHEL4 getestet zu haben. Vielleicht hilft ja jemandem diese Aussage, um den entscheidenden Unterschied zwischen einem ollen RedHat und einem aktuellen Ubuntu zu benennen?

so viel nebenher zu lernen...

Ansgar

PS: So langsam geht's doch ins Linux-Eingemachte... wenn'S zu sehr OT wird, bitte Bescheid sagen, dann biegen wir den Thread geeignet ab... :)

Am 30.11.2010 16:19, schrieb Ansgar Strickerschmidt:

...

In /etc/udev/rules.d/98-parport.rules (oder wo immer bei Dir "parport" vorkommt, sonst anlegen): KERNEL=="parport*" GROUP="lp", OWNER="root", MODE="0660"

Ich verwende immer zunächst "strace -f -e open". Das -f sorgt dafür, daß auch evtl. geforkte Prozesse behandelt werden, -e gibt nur Aufrufe von aus.

Solange das Linux auf einem elektronischem Gerät läuft ;-)

Falk

Ich hatte mal einen USB-Parallelport-Adapter auf Basis eines ATMega8 und VUSB (ehemals AVRUSB) selbstgebastelt, in der Hoffnung, ihn mit VMware benutzen zu können. Mit voller ppdev-Kompatibilität, so dass er als /dev/parport0 sichtbar war und auch von avrdude mit Bitbanging (wenn auch langsam) benutzt werden konnte. Nachdem ich ihn dann in VMware als Parallelport eingetragen hatte kam die große Ernüchterung: Auch wenn VMware in seinem Konfigurationsdialog von /dev/parport0 spricht, werden nicht die ppdev-IOCTLs zum Zugriff verwendet, sondern VMware pult sich aus /sys/ die Basisadresse und IRQ heraus, um dann direkt mit PCI-I/O- Zugriffen mit der Schnittstelle zu sprechen. Dumm gelaufen.

Ziel war übrigens ein Xilinx Parallel Cable III zur FPGA-Programmierung aus einem in der VM laufenden ISE benutzen zu können...

Gruß Henning

Also schrieb Falk Willberg:

Bisher ist da nur 70-persistent-net und (OTTOMH) noch ein 70-irgendwas. Also mach ich das neu. (Note to self: udev genauer erlernen.)

OK, schaue ich mal.

Wird nachgeliefert, sobald ich etwas mehr Zeit habe, mich da reinzufuchsen. Im Moment haben wir einen Workaround (aka separater Windows-Rechner :-/ ) implementiert.

Ansgar