hi um die Parallele Schnitstelle meines alten Pc anzusteuern hab ich ewig gebraucht. Zuerst wollte ich sie mit c ansteuern bin dan aber über ne Beschreibung in vb2008 gestolpert mit einer inpout.dll. Was mich am meisten genervt hat ist das meist nicht richtig einer Sprache zugeordnet werden konnte, als Laie ist das nun mal schwer wenn es nicht explizit darsteht. Dazu kam noch das meist nur da stand "parallelport steuern ist leicht" oder in c "das geht nicht". Bei einem Mikrokontroller die Ausgänge zu schalten fand ich im gegensatz leicht. allerdings ist ein Mikrokontroller doch auch nichts anderes als ein Pc nur eben langsamer. Deshalb müßte es doch auch ganz einfache Befehle wie DDRA = 0xff; PORTA = 0x03; in c geben. Da c ja auch noch eine sehr hardware nahe Umgebung ist. Wie ist das nun braucht man da auch eine bestimmte .dll oder muß man da in einen Treiber eingreifen (und wenn ja wie kann man die befehle die in einem Treiber definiert sind herausfinden. An einen PC zu zu schalten und zu walten find ich fiel schwieriger als bei einem Mikrokontroller. mfg
Kommt auf den Rest des PCs an. Beispielsweise eine echte parallele Schnittstelle (Druckerport), die lässt sich zumindest unter Linux/Unix ganz einfach so ansteuern, wie du das da beschreibst: 1. Zugriffsrechte besorgen 2. Datenbytes auf den Port schreiben, die erscheinen dann z.B. als TTL-Pegel an den Pins des Druckerports 3. Zugriffsrechte zurückgeben Das wär die einfachste Variante. Funktioniert in C auf jeden Fall, sollte sich ansonsten über mehr oder weniger lange Umwege auch in allen anderen Sprachen verwenden lassen. Weitere Infos --> http://tldp.org/HOWTO/IO-Port-Programming.html Ist zwar nicht Windows, aber immerhin recht ähnlich deiner Vorstellung, denke ich.
das ist auch so ne sache. Warum ist das Betrigssystem abhängig, die Befehle legt doch letztendlich die hardware fest. Zb sind die bei avr s immer gleich und die haben doch auch kein Betribssystem drauf. Ob sie ein Bios haben weiß ich nicht bzw hab noch nichts gelesen. Also myste doch letztendlich weil die Schnitstellen genormt sind immer die gleichen Befehle rauskommen. PS: Bin eigentlich win nutzer, hab zwar 2 vdr s, ich hab linux zwar schon 1 2 mal ausprobiert wenn man da aber nicht der Crack ist find ich es schwer. Noch dazu kommt das Programme die ich brauche nicht unter linux laufen. Trotzdem danke, wenn ich mal wieder nen Rechner übrig habe hau ichs mir mal wieder drauf. Ein Dualsystem mag ich nicht. mfg
Alf Tenner schrieb: > das ist auch so ne sache. > Warum ist das Betrigssystem abhängig, Weil ein Betriebssystem den Rechner verwaltet. Es kann nicht einfach zulassen, dass sich jedes dahergelaufene Programm an den Schnittstellen vergreift, wie es gerade lustig ist. In einer Zeit, in der auf einem Desktop-Rechner nur 1 Programm lief (zb in den Anfangszeiten des PC unter DOS), ging das. Aber in der heutigen Zeit, in der zb auf Windows mehrere Programme gleichzeitg laufen, geht das nicht mehr. Stell dir einfach vor, ein Programm druckt gerade und dann kommt ein anderes Programm daher und fängt mitten im Druckvorgang an, den parallelen Port umzukonfigurieren. > die hardware fest. Zb sind die bei avr s immer gleich und die haben doch > auch kein Betribssystem drauf. Eben drum. Genau deshalb kann dein Programm auch einfach auf die Schnittstellen bzw. die restliche Hardware zugreifen. Es ist das einzige Programm welches gerade läuft und kann daher per Definition nicht einem anderen in die Quere kommen. Eine Analogie: Wenn du einen 1-Mann Betrieb hast, ist es kein Problem, wenn du einfach ins Lager gehst und dir dort ein Werkzeug holst. In einer größeren Firma gibt es aber einen Lagerverwalter, der das Lager unter seiner Fuchtel hat. Wenn du was brauchst, dann gehst du zu ihm und er gibt es dir, wenn das Teil vorrätig ist. Bzw. er kann dir sagen wer das Teil gerade in Beschlag hat und bietet dir an, dich zu benachrichtigen, wenn es wieder zurückkommt. Holst du dir dein Werkzeug aber selber aus dem Lager, ohne jemandem Bescheid zu sagen, dann gibts eine auf die Finger. Anarchie war gestern. Als Programmierer heißt es mit dem Betriebssystem zu arbeiten und nicht dagegen.
Es ist eigentlich nicht Betriebssystemabhängig, die Befehle sind prinzipiell auf allen x86-Prozessoren dieselben. Du kannst diese Befehle auch weiterhin benutzen, entsprechende Vorarbeit vorausgesetzt (Rechte besorgen und so weiter); allerdings müsstest du dann halt auch selbst darauf achten, dass du nicht in Konflikt mit anderen Dingen kommst, die gerade um dich herum passieren (Druckerdämon z.B.). Das 'outb' unter Linux ist schon hardwarenah, näher gehts nicht mehr:
1 | static __inline void |
2 | outb (unsigned char value, unsigned short int port) |
3 | {
|
4 | __asm__ __volatile__ ("outb %b0,%w1": :"a" (value), "Nd" (port)); |
5 | }
|
Du siehst, 'outb' entspricht unmittelbar dem Maschinenbefehl.
>Es ist eigentlich nicht Betriebssystemabhängig Also so kenn ich es jetzt auch Bei meiner damaligen suche bin ich mämlich noch auf sowas hier gestoßen. http://www.franksteinberg.de/4zeilen.htm Das war aber in Qbasic und da kenn ich mich nicht aus. Allerdings dürfte der Befehl "out" des Qbasik auf modernen Rechnern auch noch funktionieren(habs nie ausbrobiert). Wonach ich wieder am Anfang wäre warum das Betriebssystemabhängig ist. Wenn ich das richtig sehe braucht man bei Linux das #include <asm/io.h> Diese Datei ist doch aber auch in c geschrieben und nach dem Buch das ich habe gibt es nur eine sehr begrenzte anzahl von Schlüsselwörtern. Da würde es mich mal interresieren wie er es in der Datei löst. In meinem Hirn blinck gerade Paradoxon. Kurze Zwischenfrage "outb" ist doch in "#include <asm/io.h>" definiert. Ich hab mir mal bei einem anderen Beispil die include Datei angeschaut aber ich konnte den Befehl beim drüberfliegen nicht entdecken. Nach was muß ich suchen bzw wie wird das definiert. mfg
> Wenn ich das richtig sehe braucht man bei Linux das > #include <asm/io.h> > > Diese Datei ist doch aber auch in c geschrieben und nach dem Buch das > ich > habe gibt es nur eine sehr begrenzte anzahl von Schlüsselwörtern. Da > würde es mich mal interresieren wie er es in der Datei löst. In meinem > Hirn blinck gerade Paradoxon. Der Linux-Kernel ist komplett in C geschrieben, und die Teile die die Hardware-Ansteuerung machen, sind in Assembler. Du kannst also dem Linux-Kernel mit einem C-Programm sagen, dass es etwas auf die parallele Schnittstelle schicken soll. C selber ist stark begrenzt - aber dieser begrenzte Teil funktioniert praktisch überall. Aber dank mehr oder weniger betriebssystem/hardware-abhängigen Erweiterungen (Libraries) kann man mit C praktisch alles machen - bis auf ein paar sehr wenige Sachen, die wirklich nur in Assembler gehen. Wär auch ziemlich blöde, wenn jede denkbare Aufgabe eins PCs zur Grund-Definition von C gehören würde - eine solche Definition wäre gigantisch groß, wahnsinnig kompliziert, nicht umsetzbar und nicht verwendbar. Wenn eine Sprache nativ den Zugriff auf eine bestimmte Hardware - wie den LPT-Port - enthält, dann müsste sie doch auch direkt den Zugriff auf eine andere Hardware, z.B. die Soundkarte, integriert haben. Und die Netzwerkkarte. Und die Grafikkarte. Und den USB-Controller. Und die IDE-Bridge... Ganz davon abgesehen, dass dies Hardwareteile möglicherweise unter verschiedenen Betriebssystemen anders verwaltet werden... Es gibt Sprachen, die haben verschiedene Aufgaben (wie grafische Oberflächen, oder [Datei-]I/O-Funktionen) eingebaut - diese Sprachen sind unübersichtlich und laufen oftmals nur in einer einzigen Umgebung (VBA zum Beispiel). > Kurze Zwischenfrage > "outb" ist doch in "#include <asm/io.h>" definiert. Ich hab mir mal bei > einem anderen Beispil die include Datei angeschaut aber ich konnte den > Befehl beim drüberfliegen nicht entdecken. Nach was muß ich suchen bzw > wie wird das definiert. Vermutlich enthält die io.h wieder #includes , die wieder was #includen, und irgendwo ganz tief versteckt stehen die Befehle. Einfach mal den kompletten Linux-Kernel-Quellcode durchsuchen lassen... Und ja, die PC-Programmierung ist komplexer als die uC-Programmierung - ein PC kann aber dafür auch viel mehr: Komplexe RAM-Verwaltung (Speicherschutz, virtueller Adressraum), Multi-Tasking, Zugriff auf komplexe Hardware (wie z.B. Grafikkarten), usw... Damit sich die ganze Leistung eines PCs sinnvoll verwenden lässt, muss man die verfügbaren Funktionen halt gut strukturieren, was halt dazu führt, dass einige Sachen komplizierter sind. Ein Mercedes ist halt auch schwieriger zu fahren als ein Dreirad, kann dafür aber auch mehr. BTW: Wenn dein Programm unter Windows eine Datei mit dem Namen COM1 (o.ä.) (glaub ich zumindest) öffnet (egal in welcher Sprache es geschrieben ist!), öffnet sie in Wahrheit den parallelen Anschluss, und geschriebene Bytes landen eben dort. Auf sowas kommt man zwar nicht sofort, hat aber den Vorteil, dass man nur ein paar Funktionen braucht, um sowohl Datei-I/O und LPT-I/O (und Netzerk-I/O, und Inter-Prozess-Kommunikation, ...) zu verwenden. Dies ist aber kein Bestandteil von C, sondern von Windows - also dem Betriebssystem. Deswegen kannst du mal auf http://msdn.microsoft.com danach suchen, wie man mit dem Win32-API auf den LPT zugreift.
Ich weiß nicht, vielleicht habe ich mich da undeutlich ausgedrückt, aber das Quelltextfragment von mir oben, das stammt direkt aus der <asm/io.h> Daraus geht dann doch auch ziemlich eindeutig hervor, dass es sich bei der 'outb'-Funktion letztlich nur um eine C-Kapselung des Assembler-Befehles handelt, oder?
> Allerdings dürfte der Befehl "out" des Qbasik auf modernen Rechnern auch > noch funktionieren(habs nie ausbrobiert). Das tut er nicht, weil moderne Rechner in der Regel Betriebssysteme verwenden. Und diese lassen den direkten Hardware-I/O-Zugriff durch Usermode-Programme schlichtweg nicht zu. Nun ist QBASIC ein uraltes DOS-Programm, und für DOS-Programme war es üblich, die Hardware direkt zu befummeln. Daher emuliert die virtuelle DOS-Umgebung, die mit Windows NT* mitgeliefert wird, eine gewisse Teilmenge von Hardwarezugriffen und leitet diese über die betriebssystemeigenen Devicetreiber an die tatsächlich vorhandene Hardware weiter. Geräte, die auf diese Art und Weise angesprochen werden können, sind serielle und parallele Schnittstellen. Auch wenn es so aussieht, eine direkte Kommunikation mit der Hardware findet nicht statt. Und das ist auch gut so, so kann nämlich ein DOS-Programm auch mit einem USB-Seriell-Adapter kommunizieren, obwohl das Programm nichts von USB weiß. Der Nachteil dieser Vorgehensweise ist natürlich das gegenüber einem "nackten" DOS stark verzögerte Zeitverhalten. Allerdings gibt es nun wirklich keinen Grund mehr, DOS oder DOS-Programme einzusetzen. Und dann gibt es noch eine üble Frickellösung. Mit einem speziellen Devicetreiber (giveio.sys) lässt sich unter Windows die Überwachung von Hardware-I/O-Zugriffen aushebeln, so daß User-Mode-Programme doch direkte Hardwarezugriffe durchführen können. Das aber ist großer Pfusch, weil es a) voraussetzt, daß die vom Programm direkt befummelte Hardware wirklich so vorhanden ist und nicht anderweitig benutzt wird und b) weil damit auf gar keinen Fall irgendwelche Hardware befummelt werden darf, die Hardwareinterrupts erzeugt. Denn einen Interrupthandler kann man nicht in einem Usermode-Programm unterbringen, und die Konsequenz ist der beliebte blaue Bildschirm. Obendrein funktioniert diese Frickellösung in neueren Windows-Versionen nicht mehr, weder unter "Vista" noch unter "Windows 7", ganz zu schweigen von 64-Bit-Versionen. > Wenn dein Programm unter Windows eine Datei mit dem Namen COM1 (o.ä.) > (glaub ich zumindest) öffnet (egal in welcher Sprache es geschrieben > ist!), öffnet sie in Wahrheit den parallelen Anschluss, und geschriebene > Bytes landen eben dort. Das tun sie mit absoluter Sicherheit nicht. "COM1" ist der Devicename der ersten seriellen Schnittstelle. Die Druckerschnittstelle wird als "LPT1" angesprochen. *) Auch Windows 2000, XP, "Vista" sowie die Serverversionen sind Versionen von Windows NT. Die Marketingclowns bei MS haben irgendwann beschlossen, daß einheitliche Versionsnummern langweilig sind, deshalb wird bei denen so gezählt: 3.1 - 3.5 - 3.51 - 4.0 - 2000 (5.0) - XP (5.1) - 2003 (5.2) - Vista (6.0) - 2008 (?) - 7 (7.0)
@die die Behaupten, die Befehle wären unter alles OS+DOS gleich. Das stimmt nicht. Unter Linux "out(data,port);" unter DOS (und sicher win) "out(port,data)".
Nein. Das ist nur ein Implementierungsdetail der Libraries des verwendeten C-Compilers und hat mit dem verwendeten Betriebssystem nichts zu tun.
Jens B. schrieb: > @die die Behaupten, die Befehle wären unter alles OS+DOS gleich. Das > stimmt nicht. > Unter Linux "out(data,port);" unter DOS (und sicher win) > "out(port,data)". Was war deiner Meinung nach an folgendem Satz nicht verständlich? Sven P. schrieb: > Es ist eigentlich nicht Betriebssystemabhängig, die Befehle sind > prinzipiell auf allen x86-Prozessoren dieselben. Die Befehle sind prinzipiell auf allen x86-Prozessoren identisch. Punkt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.