Problem mit der Ansteuerung der LPT-Schnittstelle...
Christian 'HessiJames' Hesse
defacto wollte ich mich ein wenig mit der Programmierung der parallelen
Schnittstelle beschäftigen. Da mein Laptop(Acer Aspire 5024WLMI) diese
Schnittstelle nicht mehr anbietet, habe ich zu einem USB auf Seriel und
Parallel Adapter gegriffen. Nun hab ich folgendes Problem: der Treiber den
ich installiert hab, scheint den Parallelport über USB auf LPT3 zu legen und
den seriellen auf Com4, und wenn meine Recherchen richtig sind würde es den
parallelen Port im Speicher auf die 0x278 legen. Wenn ich über meine unten
folgende Klasse versuche darauf zuzugreifen passiert aber nix. Ich kann
weder auf den Port schreiben, noch einen Wert lesen. Bzw. die Werte die ich
lesen kann sind immer nur 255. Die DLL hab ich ins Windows-Systemverzeichnis
geschmissen und die Verlinkung gesetzt. Ich nutze die Microsoft Visual C#
2005 Express Edition, die war mal in der C't vor knapp nem Jahr. Falls
jemand einen Hinweis hat wo der Fehler liegen könnte immer raus damit, weil
ich such jetzt schon knapp 3Tage und werd einfach nicht schlau aus dem
Problem. Weil so wie ich es verstanden habe, kann man über die inpout32.dll
ja auf den Parallelport zugreifen, und wenn alles richtig ist sollte die
Adresse ja auch stimmen, nur irgendwie zeigt mein Multimeter keine Regung
beim messen an den Datenpins oder Steuerpins, wenn ich versuche einen Wert
zu schreiben. Vielen Dank schonmal für die Hilfe :)
Gruss Christian Hesse
public class CentronixAccess
{
/* For sending Value to the port */
[DllImport("inpout32.dll", EntryPoint = "Out32")]
public static extern void Output(int adress, int val);
/* For receiving Value from the port */
[DllImport("inpout32.dll", EntryPoint = "Inp32")]
public static extern int Input(int adress);
public void writeToPort(int adress, int val)
{
CentronixAccess.Output(adress, val);
}
public int readFromPort(int adress)
{
int return_value= CentronixAccess.Input(adress);
return (return_value);
}
}
Thomas Scheidegger [MVP]
> den seriellen auf Com4, und wenn meine Recherchen richtig sind würde es den
> parallelen Port im Speicher auf die 0x278 legen.
ungeprüft, aber ich glaube eher weniger,
dass die Windows-Treiber zu jene USB-Konverter auch IO-Ports 'virtualisieren'.
Jene inpout32.dll dürfte da nicht brauchbar sein.
'Offiziell' geht sicherlich das normale Win32 API für serielle/parallele Schnittstelle (und ggf .NET SerialPort),
alles andere wäre spezifisch für den USB-Treiber/Chip, => Hersteller fragen.
--
Thomas Scheidegger - MVP .NET - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/
Kerem Gümrükcü
"Thomas Scheidegger [MVP]" <spam.ne...@swissonline.ch> schrieb im
Newsbeitrag news:%23C9KQzA...@TK2MSFTNGP06.phx.gbl...
Huch, da is ja noch wer wach...:-)
Beste Grüße
Kerem Gümrükcü
Frank Dzaebel
> den seriellen auf Com4, und wenn meine Recherchen richtig sind würde es
> den parallelen Port im Speicher auf die 0x278 legen.
Naja, etwas dünnes Eis bei LPT3, nicht jeder
unterstützt das.
LPT1: I/O port 0x378, IRQ 7
LPT2: I/O port 0x278, IRQ 5
(http://en.wikipedia.org/wiki/LPT)
Ich weiss: http://www.lk.etc.tu-bs.de/lists/archiv/lug-bs/2002/msg04397.html
Hier sind auf jeden Fall wertvolle Hintergründe, falls
nicht eh schon bekannt:
[Jan's Parallel Port FAQ]
http://www.lvr.com/jansfaq.htm
Die inpout32.dll ist ja nicht auf allen OS vorhanden.
Solltest Du also eher selber über DeviceIoControl
schreiben.
[Inpout32.dll for WIN NT/2000/XP]
http://www.logix4u.net/inpout32.htm
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Christian 'HessiJames' Hesse
habe das mich die Antworten nicht so desillusionieren ;) ....na mal schaun
ob ich das Problem irgendwie lösen kann? Weil auch ein virtueller Port muss
ja irgendwo abgebildet sein im Speicher, ich geb also nicht auf mit der
Suche ^^ und falls ich ne Lösung finde lass ich es euch wissen ;)
Gruss "ich"
Thomas Scheidegger [MVP]
was willst du mit dem armen, alten LPT denn genau erreichen?
Hardware-Pins direkt lesen/schreiben? Wozu?
> ein virtueller Port muss ja irgendwo abgebildet sein im Speicher
AFAIK nicht wirklich (im PC-Speicher) wenn ein USB(-Bus!) dazwischen ist.
Dann werden all die IO-Port-Adressen (0x378 / 0x278, IRQ 5/7 usw) irrelevant.
[im PC-Speicher, IO oder MemMapped findet höchstens zB der mainboard-USB Controller]
Wenn du via USB die LPT-Hardware-Pins (am Adapter) _direkt_ lesen/schreiben willst,
musst du den (Chip-) Hersteller nach seinem USB-Protokoll fragen,
sowie ob es ein User-Mode DLL-API gibt oder generisch per DeviceIoControl-Codes.
Oder vergiss die hässliche LPT-Sache,
nimm einen native USB-Digital-IO Adapter der echt dafür gedacht ist.
Falls du auf LPT & inpout32.dll fixierst bist,
musst du im PC wohl eine LPT-Karte (PCI/PC-Card) einbauen, welche
Port-Remapping auf legacy Adressen (eben 0x378 / 0x278, IRQ 5/7 usw) unterstützen muss.
Mit heutigem Plug&Play, IEEE-1284.4-Murks und Power-Saving stehen da aber viele Fallen dazwischen,
insbesondere mit dem 'Hack' inpout32.dll.
Christian 'HessiJames' Hesse
> Hardware-Pins direkt lesen/schreiben? Wozu?
Du hast die Sache gut erkannt, ich hab den Zweck verfolgt die Pins direkt zu
schreiben, da ich gerne eine LCD Anzeige ansteuern wollte.
Und zum Lernzweck scheint mir der Parallelport als simpelste Variante. Im
Prinzip ist das wohl auch der Fall, sofern der Rechner einen solchen Port
direkt hat und man nicht mit nem Adapter arbeiten muss.
> AFAIK nicht wirklich (im PC-Speicher) wenn ein USB(-Bus!) dazwischen ist.
> Dann werden all die IO-Port-Adressen (0x378 / 0x278, IRQ 5/7 usw)
> irrelevant.
> [im PC-Speicher, IO oder MemMapped findet höchstens zB der mainboard-USB
> Controller]
Das würde erklären warum das eine Programm, welches mir die Portadressen
anzeigt bei LPT2 und LPT3 ne 0 ausgibt, interessanter Weise kennt es den
LPT1 als 0x378. Und das obwohl ich wie gesagt keinen Parallelport dran hab.
Der scheint also Standardmäßig gemappt zu sein.
> Wenn du via USB die LPT-Hardware-Pins (am Adapter) _direkt_
> lesen/schreiben willst,
> musst du den (Chip-) Hersteller nach seinem USB-Protokoll fragen,
> sowie ob es ein User-Mode DLL-API gibt oder generisch per
> DeviceIoControl-Codes.
Mhmm, da muss ich mal ins Datenblatt schauen ob ich da an jemand gelangen
kann der mir Auskunft gibt. Weil dann müßt ich mich in den Kram ja auch noch
reinarbeiten, sicherlich wird man da nicht dümmer, aber es ist ein
verfluchter Zeitfaktor den ich andersweitig sinnvoller nutzen könnte. Na mal
schaun ob ich da was machen kann.
> Oder vergiss die hässliche LPT-Sache,
> nimm einen native USB-Digital-IO Adapter der echt dafür gedacht ist.
OK, alternativ würde ich den Spaß auch vergessen. Wenn du mir noch ne
preiswerte Bezugsquelle sagen kannst für so ein Ding ;) weil irgendwie bin
ich mir sicher das ich sowas schon im Reichelt oder Conrad gesehen hab,
finds aber grad net. Da hätt ich dann auch gleich ne Frage wie sich das bei
USB verhält? Seriell würde ich ja ne Verbindung aufbauen mit nem bestimmten
Handle, Parallel würd ich direkt auf die passende Speicheradresse zugreifen.
USB ist ja wiederum ein Bus, da muss ich ja mit dem passenden Gerät
sprechen, wie bekomm ich die Kennung dieses heraus und bietet C# da schon
passende Klassen zur Kommunikation mit USB?
> Falls du auf LPT & inpout32.dll fixierst bist,
mitnichten, nur dacht ich halt es wäre eine einfache Umsetzung, was sich
scheinbar als Ente herausgestellt hat....
> musst du im PC wohl eine LPT-Karte (PCI/PC-Card) einbauen, welche
> Port-Remapping auf legacy Adressen (eben 0x378 / 0x278, IRQ 5/7 usw)
> unterstützen muss.
> Mit heutigem Plug&Play, IEEE-1284.4-Murks und Power-Saving stehen da aber
> viele Fallen dazwischen,
> insbesondere mit dem 'Hack' inpout32.dll.
überzeugt *g*...ich nehm USB, ist vermutlich auch sinnvoller als das
vorsintflutliche Parallelgedöns ;) ...obwohl ich sicherlich auch im späteren
Berufsleben evtl. mal was mit Schnittstellenprogrammierung zu tun habe von
Messgeräten, da wär es denk ich auch nicht verkehrt sowas wie Parallelport
über USB anzusteuern, da manche Messtechnik ja älter ist als heutige PCs
Thomas Scheidegger [MVP]
ist vermutlich im Chipset auf Mainboard integriert.
Würde bei einem Laptop evtl. via einer Docking-Station anschliessbar.
> ob ich da an jemand gelangen kann der mir Auskunft gibt.
wenn auf Hersteller-Homepage keine Hinweise auf SDKs o.ä.
dann besteht da meistens kein Wille Auskunft zu geben (ausser gegen viele k$)
> sowas schon im Reichelt oder Conrad gesehen hab
es gibt sicherlich div. Quellen, wurde auch öfters erwähnt (ohne Gewähr!)
http://www.heise.de/ct/03/08/204/
http://www.codemercs.com/IOWarriorD.html
> bietet C# da schon passende Klassen zur Kommunikation mit USB?
nein (weil auch nichts in Win32 bis XP, erst ab Vista [WinUSB]).
Andere Quellen, zB:
http://libusb-win32.sourceforge.net/
http://www.icsharpcode.net/opensource/sharpusblib/
wobei solches nur den Bus bedient, das eigentliche 'Protokoll' des USB-Gerätes
muss danach auch noch bekannt sein (und ist oft hersteller-spezifisch)
> USB verhält? Seriell würde ich ja ne Verbindung aufbauen mit nem bestimmten
> Handle, Parallel würd ich direkt auf die passende Speicheradresse zugreifen.
> USB ist ja wiederum ein Bus, da muss ich ja mit dem passenden Gerät sprechen
'sauber' wird dies durch einen Windows-Treiber gelöst,
entweder die generischen Class-Driver (zB HID Tastatur/Maus...) von Windows selber,
oder ein spezifischer Treiber (.SYS) des Geräte-Herstellers, mit SDK für User-Mode API DLL.
Dort gibt es dann typ. auch Calls ähnlich wie eben 'WriteToPort'.
Wenn es bei jener 'LCD Anzeige' um ein _grafisches_ Display geht,
wären wegen der Datenmenge jedoch USB Block-Transfer Mechanismen von Vorteil,
ggf. sogar mit etwas eigener Logik (zur LCD-Ansteuerung) im USB-Microcontroller.
Dies würde die PC-Software (in Hochsprache/Runtime wie C#)
enorm entlasten, weil so nicht jede Signaländerung separat über den USB übermittelt werden muss.
aber irgendwer dürfte sowas wohl auch 'fertig' verkaufen:
http://www.google.com/search?q=USB+LCD