Hallo,
bin c++-Einsteiger und habe jetzt ein bisschen mit Konsolenanwendungen
in VisualC++ rumexperimentiert (iostream.h), d.h. Zeichen und Ergebnisse
von Rechenoperationen auf dem Bildschirm ausgeben etc.
Jetzt würde ich gerne mal was Steuerungstechnisches mit dem PC
unternehmen. Zwei Fragen dazu:
1) wie kann man unter c++ den Parallelport (Datenbits, Ausgabe Bitmuster
für z.B. Schrittmotorsteuerung, LEDs...) ansteuern? Geht das auch mit
iostream???
2) gibt es die Möglichkeit, ohne Schleifen o.ä. bestimmte
Verzögerungszeiten unabhängig von der CPU-Geschwindigkeit zu nutzen
(analog Bascom z.b. "waitms 5", damit 5ms verstreichen, bis der nächste
Befehl ausgeführt wird)?
Viele Grüße!
emil schrieb:
> 1) wie kann man unter c++ den Parallelport (Datenbits, Ausgabe Bitmuster> für z.B. Schrittmotorsteuerung, LEDs...) ansteuern? Geht das auch mit> iostream???
iostream ist dazu prinzipbedingt ungeeignet, da es ggf. puffert.
I.d.R. benutzt man das Parport-Kernelmodul, für einfache Sachen gehts
auch mit ioperm() und inb/outb, direkt. Simpel, aber effektiv.
> 2) gibt es die Möglichkeit, ohne Schleifen o.ä. bestimmte> Verzögerungszeiten unabhängig von der CPU-Geschwindigkeit zu nutzen> (analog Bascom z.b. "waitms 5", damit 5ms verstreichen, bis der nächste> Befehl ausgeführt wird)?
sleep(), usleep(). Ist bei Mehrprozess-BS reine Spekulation.
emil schrieb:
> 1) wie kann man unter c++ den Parallelport (Datenbits, Ausgabe Bitmuster> für z.B. Schrittmotorsteuerung, LEDs...) ansteuern? Geht das auch mit> iostream???
So:
http://www.teuniz.net/RS-232/
ein schrieb:
> emil schrieb:>> 1) wie kann man unter c++ den Parallelport (Datenbits, Ausgabe Bitmuster>> für z.B. Schrittmotorsteuerung, LEDs...) ansteuern? Geht das auch mit>> iostream???> So:> http://www.teuniz.net/RS-232/
Seltsam, ich dachte immer, der Parallelport heißt so, weil da acht
Datenbits PARALLEL kommen.
>http://www.teuniz.net/RS-232/
ok, dann weiß ich für später schon mal, wie ich com-me ;)
>für einfache Sachen gehts auch mit ioperm() und inb/outb, direkt. Simpel, aber
effektiv
Sind ioperm() und inb/outb Dateien wie iostream.h oder Befehle? Wenn
ersteres, sind sie in VisualC++ schon enthalten?
(sorry, bin wirklich Einsteiger und "By-Doing-Learner")
Sven
Hast du die Angabe des Compilers 'Visual C++' übersehen.
Da ist nichts mit Linux :-)
@emil
Du kannst zb das hier
http://www.driverlinx.com/DownLoad/DlPortIO.htm
benutzen.
Zumindest bei Win2K und WinXp gings noch. Bei Vista hab ich das noch nie
probiert, könnte aber auch noch gehen.
Karl heinz Buchegger schrieb:
> Sven> Hast du die Angabe des Compilers 'Visual C++' übersehen.> Da ist nichts mit Linux :-)
Ups.
Hast natürlich Recht, dann halt so Krücken wie PortIO etc. :-)
>http://www.driverlinx.com/DownLoad/DlPortIO.htm
ok, werds gleich runterladen.
habe das VisualC++ unter Win2000 installiert, könnte es da
zugriffsprobleme auf den parallelport geben (unter qbasic ist z.b. in
der richtung nichts zu machen)
Unter allen ernstgemeinten* Windows-Versionen ist ein direkter
Hardware-I/O-Zugriff nur über einen Devicetreiber zugelassen. Es gibt
einen Frickeltreiber (giveio), der diese I/O-Beschränkung aufhebt, der
aber lässt sich nicht mit 64-Bit-Versionen verwenden.
Mit diesem Frickeltreiber ist es auch mit QB prinzipiell möglich, auf
die Druckerschnittstelle zuzugreifen.
*) alles außer 95/98/Me und den uralten 16-Bit-Versionen
emil schrieb:
>>http://www.driverlinx.com/DownLoad/DlPortIO.htm> ok, werds gleich runterladen.>> habe das VisualC++ unter Win2000 installiert, könnte es da> zugriffsprobleme auf den parallelport geben (unter qbasic ist z.b. in> der richtung nichts zu machen)
Nein. Funktioniert tadellos.
In der Lib sind, wenn ich mich recht erinnere, auch Beispiele drinnen,
wie man sie mit VC++ benutzt.
>Nein. Funktioniert tadellos.>In der Lib sind, wenn ich mich recht erinnere, auch Beispiele drinnen,>wie man sie mit VC++ benutzt.
gut zu hören!
wie kann ich die lib eigentlich öffnen?
Ok, habe DLPortIO auf dem Rechner installiert.
Habe die Datei DlPortio.h sowie den Ordnerinhalt von (bei mir)
D:\Programme\DLPortIO\MSVC
(also z.B. PortIO.h, PortIO.cpp, PortIO.mak, PortIODlg.cpp, PortIODlg.h)
ins VisualC++-verzeichnis
D:\Programme\Microsoft Visual Studio\VC98\Include
kopiert.
Danach habe ich auf VC++ folgendes Testprogramm versucht zu compilieren:
#include <Dlportio.h>
void main(void)
{
}
Das führt zu sage und schreibe 69 Fehlermeldungen.
Liegt es vielleicht daran, dass ich die o.g. Dateien falsch eingebunden
habe (Dlportio.h wird auf jeden Fall vom Compiler gefunden)?
Oder fehlen der Datei Dlportio.h zusätzliche Parameter im Programm,
weshalb diese Minimalversion nicht funktioniert???
emil schrieb:
> Ok, habe DLPortIO auf dem Rechner installiert.>>> Habe die Datei DlPortio.h sowie den Ordnerinhalt von (bei mir)> D:\Programme\DLPortIO\MSVC> (also z.B. PortIO.h, PortIO.cpp, PortIO.mak, PortIODlg.cpp, PortIODlg.h)>> ins VisualC++-verzeichnis> D:\Programme\Microsoft Visual Studio\VC98\Include> kopiert.
Autsch.
Genau da gehört das alles nicht hin.
emil schrieb:
> Danach habe ich auf VC++ folgendes Testprogramm versucht zu compilieren:>> #include <Dlportio.h>> void main(void)> {> }>> Das führt zu sage und schreibe 69 Fehlermeldungen.
Schau doch ganz einfach mal in PortIO.cpp bzw PortIODlg.cpp hinein.
Das sind Source Code Files und die kann man mit dem Editor öffnen.
Dir werden höchst wahrscheinlich ein paar Includes vor dem DlPortio.h
abgehen.
Karl heinz Buchegger schrieb:
> Autsch.> Genau da gehört das alles nicht hin.
Kein Problem, kann ich wieder rückgängig machen.
Was gehört denn wo hin, damit es funktioniert?
(in der Readme stand jedenfalls nichts zum Thema)
Ich kann das EXE hier bei mir auf dem 64-Bit Vista nicht laufen lassen,
daher weiß ich nicht mehr was da alles im Paket drinnen ist.
Aber im Zweifelsfall kopierst du dir alles auf dein Projektverezeichnis.
Höchstens eine DLL, die ins Windows Verzeichnis kopiert wird, damit sie
Windows beim hochfahren deiner EXE auch immer findet (aber auch dann
wird man die DLL lieber beim EXE lassen)
Rufus t. Firefly schrieb:
> Unter allen ernstgemeinten* Windows-Versionen ist ein direkter> Hardware-I/O-Zugriff nur über einen Devicetreiber zugelassen. Es gibt> einen Frickeltreiber (giveio), der diese I/O-Beschränkung aufhebt, der> aber lässt sich nicht mit 64-Bit-Versionen verwenden.
Es gibt auch modernere Treiber
http://www.highrez.co.uk/Downloads/InpOut32/default.htm
(signiert und x64) bzw.
http://sourceforge.net/projects/winring0/
(ebenfalls signierte Treiber und x64, Port-, CPU-MSR- und
PCI-Bus-Zugriff)
Hallo zusammen,
bin auch nicht durch und durch über solche Treiber informiert, hab aber
schon einiges mit diesem hier gemacht:
http://www.geekhideout.com/iodll.shtml
Ich weiß weder Vor- noch Nachteile, würde das aber gerne ändern ;)
>Habe die Datei DlPortio.h sowie den Ordnerinhalt von (bei mir)>D:\Programme\DLPortIO\MSVC>(also z.B. PortIO.h, PortIO.cpp, PortIO.mak, PortIODlg.cpp, PortIODlg.h)>>ins VisualC++-verzeichnis>D:\Programme\Microsoft Visual Studio\VC98\Include>kopiert.
Schätze mal, DlPortio.h in den Include-Ordner zu transferieren war ok,
der Rest gehört zu einem Projektordner!?!!
Indem Du es ihm mitteilst. Packe alles, was dazugehört, in ein eigenes
Verzeichnis. Das musst Du dann dem Compiler als "additional include
directory" angeben, oder in der Environmentvariable INCLUDE mit
aufführen.
Rufus t. Firefly schrieb:
> Das musst Du dann dem Compiler als "additional include> directory" angeben,
ok, hab ich gemacht, auch mit dem lib.-usw.Dateien
habe dann das beigelieferte test-cpp-programm von dlportIO geöffnet,
beim compilieren kam eine fehlermeldung "nafxcwd.lib konnte nicht
geöffnet werden". besagte nafxcwd.lib befindet sich auch gar nicht auf
dem rechner.
morgen mehr...
>habe dann das beigelieferte test-cpp-programm von dlportIO geöffnet,>beim compilieren kam eine fehlermeldung "nafxcwd.lib konnte nicht>geöffnet werden". besagte nafxcwd.lib befindet sich auch gar nicht auf>dem rechner.>morgen mehr...
hab das problem zwischenzeitlich mal gegoogelt, haben wohl viele, die
VC++ in der Autorenversion benutzen.
Eine hilfreiche "Abhilfeanleitung" konnte ich allerdings noch nicht
entdecken (hatte aber auch noch nicht die zeit zum ausführlichen
googeln).
Karl heinz Buchegger schrieb:
> Dann nimm eine andere Lib, die dir direkten Port Zugriff gestattet. Gibt> ja auch noch andere.
was würdest du denn empfehlen?
Da ich mit keiner anderen Erfahrung habe, darfst du mich hier nicht nach
einer Empfehlung fragen :-)
Das Einzige was ich empfeheln würde ist: Eletrkisch extrem vorsichtig
mit Hardware am LPT zu sein. Ich hab mir in einem (Gott sei Dank alten)
Laptop schon einen LPT mit diesen Spielchen geschrottet.
>Das Einzige was ich empfeheln würde ist: Eletrkisch extrem vorsichtig>mit Hardware am LPT zu sein. Ich hab mir in einem (Gott sei Dank alten)>Laptop schon einen LPT mit diesen Spielchen geschrottet.
mein tipp:
einen sack 6V8 zenerdioden o. ä. besorgen und von jedem datenpin des
ports eine zenerdiode in gegenflußrichtung gegen masse schalten.
portpin O-------I-------O -> out (oder auch in)
I
-------,
DDD
DDDDD <- zenerdiode
DDDDDDD
I
I
Masse
Tölpel schrieb:
>>Das Einzige was ich empfeheln würde ist: Eletrkisch extrem vorsichtig>>mit Hardware am LPT zu sein. Ich hab mir in einem (Gott sei Dank alten)>>Laptop schon einen LPT mit diesen Spielchen geschrottet.>> mein tipp:> einen sack 6V8 zenerdioden o. ä. besorgen und von jedem datenpin des> ports eine zenerdiode in gegenflußrichtung gegen masse schalten.>>> portpin O-------I-------O -> out (oder auch in)> I> -------,> DDD> DDDDD <- zenerdiode> DDDDDDD> I> I> Masse
Hätte bei mir auch nicht geholfen.
Ich hatte unabsichtlich mit Krokokabeln einen Kurzen zwischen 2
Datenpins gebaut. Und ping ... war einer der beiden LPT-Pins hinüber.
krokokabel am portstecker ist aber auch eine gewagte lötersatztechnik...
aber dass ein kurzer zwischen zwei datenpins solche auswirkungen hat,
kann ich mir gar nicht vorstellen...
ansonsten kann man natürlich noch ein logikgatter hinter den port
klemmen, dann geht im zweifelsfall das gatter statt dem port kaputt.
emil schrieb:
> krokokabel am portstecker ist aber auch eine gewagte lötersatztechnik...
LOL.
Wie gesagt: Es war ein alter Laptop (von so um 1998). Von daher wars mir
egal.
Ich hatte da ein schönes Kabel drann auf eine Streifenrasterplatine mit
ein paar LED. Und beim spielen mit den Signalen, die ich mir von den LED
geholt hatte, ist es dann passiert :-)
> Und beim spielen mit den Signalen, die ich mir von den LED geholt hatte,> ist es dann passiert :-)
Ja, das hypnotische Blinken von LEDs hat bei Elektronik-Bastlern schon
immer zu Tod und Verderben geführt. ;-)
Mit steinalt meine ich Wind98 und 100Mhz.
Ich habe aber keinen direkten Vergleich mit eigener Software gemacht und
auch nicht gemessen, das ist nur mein Gefühl.
Diese Software von Pollin:
http://www.pollin.de/shop/dt/Mjc5OTgxOTk-/Bausaetze/Diverse/Schrittmotorplatine_Bausatz.html
verwendet die inpout32.dll. Diese Software läuft auf dem alten PC nicht
schnell genug um den Schrittmotor schnell zu bewegen. Auf meinem
normalen PC läuft die Software hingegen gut.
Das Programm NC-FRS:
http://nc-frs.holgerlauer.de/
verwendet hingegen die io.dll und schafft es damit auf dem alten PC
einen Schrittmotor schnell genug anzusteuern.
Vielleicht liegts auch an der Software um die dlls herum. Ich weiß es
nicht sicher.
Der Geschwindigkeitsunterschied aber wird nicht an den unterschiedlichen
verwendeten DLLs liegen, sondern höchstwahrscheinlich am unterschiedlich
effizient geschriebenen Programm.
Die höchste Geschwindigkeit übrigens ergibt sich bei Gebrauch des von
mir bereits angesprochenen "Frickeltreibers" giveio.sys, der schaltet
die I/O-Zugriffsüberwachung des Betriebssystems für einzelne Prozesse
aus, so daß direkt mit den I/O-Befehlen inp/outp aus dem
Usermodeprogramm heraus gearbeitet werden kann. Mit diesem Treiber
lassen sich sogar manche alte DOS-Programme zum Leben erwecken, wie z.B.
die Steuersoftware für das EPROM-Programmiergerät "EPROP" von taskit,
das am Parallelport angeschlossen wird.
Absolut tödlich ist es allerdings, über diesem Weg auf Hardware
zuzugreifen, die Interrupts erzeugen kann, wie z.B. die seriellen
Schnittstellen. Da ist der BSOD garantiert.
Auch deswegen nenne ich das eine Frickelei, außerdem ist der
Parallelport am aussterben, und das Zeitverhalten eines
Usermodeprogrammes ist auch nicht das definierteste.
Sauber ist es, die grundliegenden Ansteuerungsfunktionen für
irgendwelche Hardware mit einem µC zu erledigen, und mit diesem über
eine vom Betriebssystem unterstützte Schnittstelle wie RS232, USB oder
Ethernet zu kommunzieren. So können zeitkritische Dinge vom µc erledigt
werden, der das erheblich besser hinbekommt als ein PC, und so muss
nicht eine uralte Schnittstellentechnik künstlich am Leben erhalten
werden.
hab mir jetzt mal das buch "messen, steuern, regeln mit visual c++" von
r. mende und s. götz besorgt.
da steht auch einiges zum lpt-port drin. werde die tage mal genauer
reinschauen...
