Tutorial zum Parallelport ...

**nobody0** · 31.10.05, 16:07

... gibt's von mir und zwar hier:

http://www.loetstelle.net/praxis/par...rallelport.php

Die Programme sind für Linux und unter der GPL.

**ilmig** · 31.10.05, 19:26

Vielen Dank, der Thread kam wie gerufen

Suche jetzt seit 10 Minuten bei Google, hab aber wohl nach dem Falschen gesucht. Dann gucke ich mal kurz hier rein, und sehe dass es nen neuen Thread gibt

Ich will ne LED anschließen, die leuchtet wenn ich nen Query oder Highlight bekomme, mit dem Howto wird das ein Kinderspiel

**Pingu** · 18.11.05, 14:25

@nobody0
Die Begründung für die Verwendung des Gray-Codes ist nicht ganz richtig. Sieh mal bei Wikipedia nach, die ist etws besser, wenn auch nicht ganz toll.

Zum Beispiel wird immer davon geredet, daß sich "nur" ein Bit ändert. Aber das ist ja genau DIE Eigenschaft dieses Kodes. Das sich "genau" ein Bit ändert.

Außerdem hat dies nichts mit der Übertragungsgeschwindigkeit zu tun, sondern der Vorteil liegt in der Symmetrie des Kodes, was Änderungsberechnungen vereinfacht und Symmetrie kann auch verschiede Vorteile bei einer Übertragung haben, insbesondere bei der analogen Übertragung (Thema Gleichstromfreiheit, Datensicherheit)

Pingu

**nobody0** · 18.11.05, 15:08

Zitat von Pingu

@nobody0
Die Begründung für die Verwendung des Gray-Codes ist nicht ganz richtig. Sieh mal bei Wikipedia nach, die ist etws besser, wenn auch nicht ganz toll.

Zum Beispiel wird immer davon geredet, daß sich "nur" ein Bit ändert. Aber das ist ja genau DIE Eigenschaft dieses Kodes. Das sich "genau" ein Bit ändert.

Ja, mir ging es hier aber darum zu betonen, dass man hiermit Daten asynchron und sehr wenig CPU-Last übertragen kann. Das findet man nämlich nur in wenigen Lehrbüchern und Ingenieure wissen davon meist nichts; die würden von allein nie daruf kommen.
Praktisch wird es zwar in einigen Geräten wie Korrelatoren genutzt, aber leider gibt es z. B. AD-Wandler oder Binärzähler mit Gray-Code-Ausgang anscheinend nirgends fertig zu kaufen; sowas muss man mit einem Mikrocontroller selber programmieren (was aber wenig Aufwand erfordert).
Ich werde das mal demnächst mit einem MSP430 machen.

**derguteweka** · 18.11.05, 17:23

Moin,

Zitat von nobody0

Ja, mir ging es hier aber darum zu betonen, dass man hiermit Daten asynchron und sehr wenig CPU-Last übertragen kann. Das findet man nämlich nur in wenigen Lehrbüchern und Ingenieure wissen davon meist nichts; die würden von allein nie daruf kommen.

Richtig, ich waere auch sicher nicht darauf gekommen, mittels graycode sich "langsam" aendernde Daten zu uebertragen. Da kann ich irgendwie keinerlei Vorteile sehen. Fuer sich "langsam" aendernde Daten wuerd' ich eher was sigma-delta-artiges empfehlen, das kommt dann auch nur mit einem bit aus. Fuer' n Schutz gegen Uebertragungsfehler hilft der Gray auch nicht weiter, die Mindesthammingdistanz ist ja immernoch 1 -also bietet sich fuer solche Faelle doch eher ein Hammingcode oder eine Kreuzparitaet an, wenns korrigieren koennen muss und noch halbwegs simpel bleiben soll.
Wieso soll die CPU-Last davon abhaengig sein, mit welchem Code ich meine Daten uebertrage? Graycode ist evtl. gut fuer eine Datenerfassung (Winkelmessung, etc) aber doch nicht fuer eine Datenuebertragung.
Oder ist mir da ganz grob was entgangen?

Gruss
WK

**nobody0** · 18.11.05, 18:18

Zitat von derguteweka

Moin,
Richtig, ich waere auch sicher nicht darauf gekommen, mittels graycode sich "langsam" aendernde Daten zu uebertragen. Da kann ich irgendwie keinerlei Vorteile sehen. Fuer sich "langsam" aendernde Daten wuerd' ich eher was sigma-delta-artiges empfehlen, das kommt dann auch nur mit einem bit aus.

Was soll sigma-delta am Parallelport? Das eine ist ein AD-Verfahren und das andere ist digital; das passt nicht.

Zitat von derguteweka

Fuer' n Schutz gegen Uebertragungsfehler hilft der Gray auch nicht weiter, die Mindesthammingdistanz ist ja immernoch 1 -also bietet sich fuer solche Faelle doch eher ein Hammingcode oder eine Kreuzparitaet an, wenns korrigieren koennen muss und noch halbwegs simpel bleiben soll.

Am Parallelport gibt's normalerweise keine Übertragungsfehler. Wenn doch, kann man das mit Leitungstreibern und Terminierung beseitigen.

Zitat von derguteweka

Wieso soll die CPU-Last davon abhaengig sein, mit welchem Code ich meine Daten uebertrage? Graycode ist evtl. gut fuer eine Datenerfassung (Winkelmessung, etc) aber doch nicht fuer eine Datenuebertragung.
Oder ist mir da ganz grob was entgangen?
Gruss
WK

Ja, denn mit Polling wird viel CPU-Zeit verbraten, mit Hanschaking oder IRQ sieht's zwar besser aus, aber da geht zumindest ein Bit für die Synchronisation weg und einfach nur Auslesen, so wie beim Gray-Code, reicht da nicht.

**derguteweka** · 18.11.05, 18:42

Moin,

Zitat von nobody0

Was soll sigma-delta am Parallelport? Das eine ist ein AD-Verfahren und das andere ist digital; das passt nicht.

Naja, aber gerade fuer die von dir vorgestellten "langsam" sich aenderenden Messwerte passt das prima - obs dann ueber nen Parallelport oder sonstirgendwie in den PC faellt ist allerdings wurscht.
Uebrigens gehts auch prima in die andere Richtung: D->A : Ein simpler RC-Tiefpass und fertig ist der Lack - z.b. 8 analoge Ausgangsspannungen aus einem Parallelport; Aufwand: 8 Widerstaend und 8 Cs

Zitat von nobody0

Am Parallelport gibt's normalerweise keine Übertragungsfehler. Wenn doch, kann man das mit Leitungstreibern und Terminierung beseitigen.

Wollte damit nur verdeutlichen, das der Graycode keinerlei Korrektureigenschaften oder auch nur Fehlererkennungseigenschaften hat.

Zitat von nobody0

Ja, denn mit Polling wird viel CPU-Zeit verbraten, mit Hanschaking oder IRQ sieht's zwar besser aus, aber da geht zumindest ein Bit für die Synchronisation weg und einfach nur Auslesen, so wie beim Gray-Code, reicht da nicht.

Da steh' ich aber jetzt irgendwie maechtig aufm Schlauch. Wie soll den der Graycode Polling verhindern koennen? Will ich irgendwelche Werte einlesen, dann isses doch voellig wurscht, wie die codiert sind. Ich nehm' oder gebe halt z.b. ein 8-bit Sample, wenn ich ein Byte via parallelport ausgebe oder einlese. Und wenn ich wissen will, ob sich irgendwas am Parport geaendert hat, dann lass' ich's nen IRQ ausloesen oder ich poll' halt den Port - jenachdem wie pressant das Ereignis so ist - aber was hat das mit Graycode zu tun?

Gruss
WK

**nobody0** · 20.11.05, 18:17

Das stimmt nicht. Beispielsweise wird mit Gray-Code der Drehwinkel gemessen und gray-codiert ausgegeben, bei den Absolute Rotary Encoders:
http://www.inotek.com/Catalog/omron7cn.html

Deshalb werden Winkel meistens mit Gray-Kodierung gemessen:
http://www.peg.si/electro/angle.html

Ob nun Winkelschritte oder Pulse von einem Geigerzähler gezählt werden, ist dabei egal.
Beim ADC +Tiefpass +Speed-Gray ist es nicht viel anders.

Edit: Im worst case sind alle N Bis zu kippen, so dass beim Speed-Gray die Quelle mindestend N-mal schneller getaktet sein muss, wenn die Werte trotz Gray-Codierung EXAKT ohne Takt übertragen werden.
Bei den 400 kHz Lese-Frequenz und N=13 (Bit) braucht man also eine Sample-Frequenz von 5,2 MHz, die bei den oben angegebenen 6 ns Setuptime völlig problemlos sind.

**quinte17** · 19.03.06, 10:55

also ich habe mir jetzt mal so einen relais bausatz am parport besorgt und mir die software selbst geschrieben, und ich muss sagen es funzt

allerdings habe ich einen einfacheren code für das setzen der daten-bits am parport verwendet als hier geposted.
stichworte für den code:
ioctl
ioctl_list
open
write
close
/dev/lp0

greetz

**nobody0** · 20.03.06, 11:23

Den Code kannst Du ja mal anhängen

**quinte17** · 20.03.06, 13:05

dies will ich eigentlich nicht, da dort der lerneffekt 1. weg ist, und 2. sehr einfach nachzuvollziehen ist...
1. du musst einen open auf das /dev/lp0 device machen (readwrite zum beispiel)
2. du musst ein byte so modifizieren, dass dort die gewählten bits auf 1 sind, die auf 1 sein sollen also ala:
char x = 0;
x = x | 128; // für das letzte bit
x = x | 1; // für das erste bit
3. einen write(filehandle,&x,1)
4. close vom device

für einen "reset" der pins gibts 2 möglichkeiten
1. echten reset über ioctl, heißt dass man mit ioctl LPRESET setzen muss, und danach 1 byte in lp0 schreiben muss (inhalt des bytes egal), um einen echten reset durchzuführen
2. ohne ioctl einfach obiges x auf 0 lassen und dies schreiben, setzt allerdings nur die datenbits zurück

greetz

ps: ein echo -n 1 > /dev/lp0 hat auch einen effekt auf die datenbits...

**nobody0** · 20.03.06, 17:55

Ok, aber damit bekommt man keine 16- und 32-Bit-Zugriffe hin. Wenn man z. B. alle 12 Ausgangs-Pins nutzen will, reicht das nicht aus.

**quinte17** · 21.03.06, 05:46

Das habe ich auch nicht behauptet

habe ja immerhin nur von den datenbits gesprochen. und die kann man damit schalten.
was sind denn die anderen 4 ausgangsports?
pin 1,14,16,17 ?
naja, mit LPCAREFUL kann man zumindest 14,16,17 auf high schalten... darf halt 15 kein high zurückgeben..
was ist mit pin 1 eigentlich gemeint, wenn da in den spezifikationen steht:
strobe: Datenübergabe;Daten müssen bei 0-Signal gültig sein
hat dies was mit timing zu tun? also des strobe schaltet ständig zwischen 1 und 0, bei 1 werden die daten geändert, und bei 0 darf der drucker sich die holen oder?

greetz

**nobody0** · 21.03.06, 17:22

Die 4 anderen Ausgangsports unterscheiden sich eigentlich nicht, außer dass ein Pin invertiert ist.
Das mit Timing und so gehört zum Centronics-Drucker, also einer speziellen Anwendung des Parallelports.

**misrax** · 01.08.06, 14:01

Hab mir mal einen Schaltplan für eine Relaiskarte erstellt.
Habe vor, mit dem LPT-Port (über die 8 Pins) meine Relais zu schalten.

Würde euch bitten, mal einmal kurz über den Schaltplan rüberzugucken, ob ich alles richtig gemacht habe, vorallem beim ansteuern der Transistoren bin ich mir nicht sicher, ob das so geht.

Vielen Dank im voraus.
Vg Marcel.