www.mikrocontroller.net

Forum: PC-Programmierung Schnitstellen des pcs Verständnisfrage


Autor: Alf Tenner (rumkugeln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alf Tenner (rumkugeln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
static __inline void
outb (unsigned char value, unsigned short int port)
{
  __asm__ __volatile__ ("outb %b0,%w1": :"a" (value), "Nd" (port));
}


Du siehst, 'outb' entspricht unmittelbar dem Maschinenbefehl.

Autor: Alf Tenner (rumkugeln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Niklas Gürtler (erlkoenig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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)

Autor: Jens B. (sio2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)".

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein. Das ist nur ein Implementierungsdetail der Libraries des 
verwendeten C-Compilers und hat mit dem verwendeten Betriebssystem 
nichts zu tun.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.