Diskussion:Ports benutzen (GCC)

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Bevor man auf irgendeinen IO-Port vom Userspace zugreifen kann, muss man ioperm(2) aufrufen. Dazu benötigt das Programm allerdings root- oder SUID-Root-Privilegien.

A1: <- Nicht korrekt, geht ohne

A2: Ich programmiere seit 7 Jahren unter Linux und anderen Unix-Systemen (in C). Mir ist noch nie aufgefallen, dass Zugriffe direkt über IO-Ports ohne einen Aufruf von ioperm(2) oder ähnlichem gehen. Wäre nämlich ne ziemliche Sicherheitslücke! Da kannst die Sicherheit gleich vergessen ... Zugriffe über Files in /dev sind natürlich was anderes, die laufen ja auch durch den Kernel, während der Kernel bei Direktzugriffen (nach vorherigem Aufruf eben von ioperm) keine Überprüfung der Daten vornimmt!

A1: Und ich programmiere seit 14 Jahren, seit 7 in C++ und seit 5 unter Linux, mir ist die Funktion von ioperm durchaus bekannt. Und das "nicht korrekt, geht ohne" sollte sich dabei auf den Schnittstellenzugriff beziehen. Wenn Du aber schon seit 7 Jahren unter Linux programmierst dann wirst Du zu der Behauptung, dass der Zugriff auf IO-Ports von userspace aus schlampiger ist als der gesamte Windowskernel, sicher zustimmen. Aber Du hättest spätestens dann gesehen dass diese Sache hier nichts mit ioperm am Hut hat als ich sagte dass man damit auch USB-RS232 Adapter ansteuern kann. Ausserdem vermeide ich den direkten Hardwarezugriff wo es geht, daher mag ich ioperm überhaupt nicht.

?: Ist schon klar, dass das mit ioperm übelst ist. Mit USB-Hardware ist da mal nix. ioperm ist nur was für X-Server und Konsorten (auch wenn's da AFAIK noch einen anderen Mechanismus gibt).


Was hier noch fehlt ist die Beschreibung, wie man Baudrate und Protokoll einstellt?!

Kommt noch ;) Gefällt Dir denn der Artikel?

Mir gefällt der Artikel bis jetzt ganz gut; bin aber nicht die/der Autor/in von da oben. Meine Frage ist vielmehr, warum bei meinem Debian Sarge es standardmäßig kein /dev/parport0 gibt und avrdude erstmal dran verzweifelt. Persönlich habe ich es jetzt händisch erstmal mit mknod angelegt, was aber sicherlich nicht der beste Weg ist.

Wenn Du garkeine /dev/parport? hast dann wurden sie warscheinlich nicht installiert. Fehlt aber bloß parport0 wurde es vielleich(versehentlich) gelöscht. Schau Dir mal /dev/MAKEDEV oder /sbin/MAKEDEV an, das ist für die Existenz der "/dev/*"-dinger da.


Hallo,

ich könnte Kritik zu diesem Artikel brauchen:
- Ist er verständlich/nachvollziehbar gehalten?
- Ist das hier beschriebene Zeug nützlich?
- Gibt es spezielle Wünsche?
- ...

Meine "Kritik" ist eigentlich keine, sondern eine Frage: Warum ist der Artikel als nicht editierbar (_NOEDITSECTION_) gekennzeichnet? Es sind ja durchaus noch Lücken (z.B. Spezialitäten bei anderen Distributionen, USB-Devices) drin, die man nach und nach ergänzen könnte. Stefan 12:27, 6. Mär. 2008 (CET)

(_NOEDITSECTION_) hat sich mir auch nicht erschlossen, und weil ich was ändern will und das Ändern section-weise übersichtlicher ist, hab ich 's gelöscht.
Insgesamt ist der Artikel ne tolle Einführung gewesen. Programmiere danach ein i2c-display am Parallel-Port. Leider gehört i2c-pport _nicht_ zum kernel 2.6, siehe auch [1]. -s


http://www.mikrocontroller.net/articles/Ports_benutzen_%28GCC%29#Die_Pins_RTS.2CDTR_setzen.2Fl.C3.B6schen

Das kann ja nicht stimmen? oder doch? Wenn ich eine 0 mit irgendwas veroder kommt doch auf jeden fall wieder Null raus...


Super Artikel, aber was mir noch fehlt ist wie man einzeln die RX-Leitung abfragen kann. Dazu habe ich leider bisher noch nichts gefunden und in deinem Artikel wird diese Leitung auch nur als "möglicher" Input mit aufgezählt. 01.12.2010 KS