Die Programmierung des Seriellen Ports
Programmierung der Seriellen Schnittstelle und Basteleien dafür

Einleitung

Wie der Name schon sagt, ist die serielle Schnittstelle für den seriellen Datenaustausch beispielsweise mit älteren Mäusen und Modems. Der hierfür verwendete Standard beim PC ist RS-232C, meist kurz RS232 oder V.24 genannt. Von diesem Stardard wird die Schnittstelle mechanisch, elektrisch und logisch spezifiziert. Im Gegensatz zum Parallelport sind die Datenprotokolle hier schon im Standard spezifiziert, der die Mechanik und Elektrik festlegt. Ebenso wie der Parallelport ist auch die serielle Schnittstelle mehrfach interrupt-fähig.
Für den Hobby-Elektroniker ist diese Schnittstelle attraktiv, da er sich um das Protokoll wenig Gedanken machen muss und neben der Massen-Ader nur noch eine Empfangs- und eine Sende-Ader für eine bidirektionale Verbindung nötig sind.

Die serielle Schnittstelle im Detail

Die serielle Schnittstelle gibt es sowohl 9- als auch 25-polig. Da aber bei der 25-poligen Variante die meisten Pins ungenutzt sind und die Pins ansonsten gleichen Signale wie bei der 9-poligen Variante haben, ist sie sehr selten.
Eine gute Übersicht über die Pins findet man unter http://de.wikipedia.org/wiki/RS-232
.
Da die serielle Schnittstelle mit 10 Registern viel mehr Register als der Standard-Parallelport hat und diese Register praktisch nie direkt angesteuert werden, wird für die komplette Beschreibung auf Fachliteratur wie das PC-Hardwarebuch verwiesen. Ein weiterer Grund ist auch, dass anderen Plattformen als PC meist andere Register verwenden.

In der Praxis gibt es mit der seriellen Schnittstelle einige Probleme, beispielsweise weil die Logik-Pegel von -12 und +12 V nicht sauber sind, z. B. weil mit einem Optokoppler, der von der Schnittstelle versorgt wird, als Low-Pegel nur 0 V ausgegeben werden kann oder bei einem Notebook, das nur -5 und +5 V ausgibt.
Ein anderes Problem ist das Timing, also das zeitliche Einlesen/Ausgeben der Daten, das theoretisch leicht ist, aber insbesondere auf billigen Mainboards nicht sauber funktioniert.
Diese beiden Probleme, also bezüglich Amplitude und bezüglich Phase, zeigen sich meist erst bei höheren Datenraten, also ab 9600 Baud (Baud = Bit/s), so dass viele Geräte, insbesondere Digitalmultimeter, mit niedrigen Baudraten von 1200 oder 2400 betrieben werden.
Zu der Baudrate ist noch anzumerken, dass sie nicht frei gewählt werden kann, sondern nur welche aus einer Liste ausgewählt werden kann. Diese Liste reicht von 50 bis 4.000.000 Hz und ist der entsprechenden Include-Datei zu entnehmen, beispielsweise unter Linux die (die von includiert wird, so dass nur diese im Programm nötig ist). Zudem kann nicht jedes Programm jede Baudrate verwenden; beispielsweise arbeiten die Terminal-Programme nur bis 115,2 kBaud, auch wenn 4 MBaud problemlos möglich sind.
Wichtig ist auch noch, dass die zulässige Leitungslänge umgekehrt proportional der Baudrate ist und bei 57.600 Baud 1,5 m beträgt (laut c't), aber meist ist noch etwas mehr Leitungslänge verwendbar. Zur Verlängerung können Konverwerter mit differentiellen seriellen Schnittstellen verwendet werden; diese verwenden andere Standards wie RS485.

Ansteuerung der seriellen Schnittstelle mit Software

Direkte Ansteuerung

Zu über 99 % wird die seriell Schnittstelle als USART verwendet und daher werden die Pins fast nie direkt angesteuert.
Trotzdem wird zunächst die direkte Pin-Ansteuerung behandelt, da man auch damit einiges nützliche machen kann. Die Ausgangsspannung der Pins beträgt -12 oder +12 V, je nachdem ob 1 oder 0 anliegt. Sie ist mit wenigen Milliampere belastbar, reicht also z. B. zum Ansteuern einer LED. Dies wird beispielsweise zur Stromversorgungs von kleinen Geräten wie einem DCF-77-Empfänger (Funkuhr-Empfänger) verwendet und auch zum direkten einlesen des DCF-77-Signals, das bezüglich der Amplituden-Modulation nur 1 Baud hat. Wichtig ist es auch für Lichtschranken, da die Versorgungsspannung für die Empfangs-Seite von der Schnittstelle versorgt werden muss. Für Details des direkten Ansteuerns verweise ich wegen der seltenen Verwendung der direkten Pin-Ansteuerung bei der seriellen Schnittstelle auf das benachbarte Tutorial zum Parallelport, da die direkte Pin-Ansteuerung dort ausführlich behandelt ist.

Trotzdem als kurzes Beispiel, wie man die Pins direkt ansteuern kann, über die 8-Bit-I/O-Ports, einmal in C/Linux:

sbase = 0x2f8; // 0x2f8=760 usually for the second serial port, 0x3f8=1016 for first,
sregister = inb (sbase + 4); // cache the port value
outb (sregister & 0xfc, sbase + 4); // clear RTS and DTR
outb (sregister | 3, sbase + 4); // clear RTS and DTR

und einmal in Pascal/DOS/MS-Win (u. deutschen Kommentaren):

sbase := 0x2f8; // Basisadresse der zweiten seriellen Schnittstelle, 0x3f8 für die erste
sregister := port[sbase + 4]; // Einlesen des Port-Werts
port[sbase + 4] := sregister AND 0xfc; // RTS und DTR auf 0 setzen
port[sbase + 4] := sregister OR 3; // RTS und DTR auf 1 setzen

Diese funktioniert nicht bei nicht direkt erreichbaren seriellen Schnittstellen z. B. am USB-RS232-Adapter, aber im ersten Beispiel unten wird gezeigt, wie man auch dort RTS und DTR setzen kann.

Indirekte Ansteuerung

Nun zur üblichen indirekten Verwendung der seriellen Schnittstelle als UART.
UART ist die Abkürzung für Universal Asynchrnous Receiver Transmitter, bedeutet also asynchroner Empfänger und Sender. Hierbei synchroniert sich die Hardware automatisch und zwar auf das Start-Bit, von dem die steigende Flanke als Start-Zeitpunkt verwendet wird. Zusätzlich wird das Ende durch ein bis zwei Stop-Bits gekennzeichnet.
Aufgrund der eingestellten Parameter steht fest, zu welchen Zeitpunkten welche Bits vorhanden sind und auch, wie lang ein Byte ist. Ein Byte ist hier ein einzelnes übertragenes Zeichen; es ist die Bitfolge zwischen Startbit und Stopbit. Falls ein Paritätsbit vorhanden ist so steht es vor dem ersten Stopbit und das Zeichen (Byte) endet schon dort.
Durch eine kleine Pause von mindestens einem Takt ist das Start-Bit des nachfolgenden Bytes eindeutig erkennbar.
Da so nur einzelne Zeichen (=Bytes) übertragen werden, gibt es hierbei keine Endianess, so dass die Übertragung plattformunabhängig ist. Erst wenn man grössere Daten übertragen und daher in Bytes zerlegen muss, ist die Reihenfolge der Bytes wichtig.

Schnittstellen-Parameter

Für die serielle Übertragung müssen zuerst die Parameter eingestellt werden, also Geschwindigkeit (=Baudrate=Bits/s, 50...4.000.000), Bits pro Byte (5..8, auf Mikrocontrollern bis zu 9), Parität (N=keine (fehlt), E=grade, ...) und Anzahl der Stopbits (1..2).
Diese Parameter werden meist in dieser Reihenfolge zusammengefasst, also z. B.
9600 8N1
für 9600 Baud, 8 Bit/Byte, kein (no) Paritäts-Bit und ein Stop-Bit.

USB-RS232-Adapter

Da die seriellen Schnittstellen zunehmen durch USB-Schnittstellen verdrängt werden, es aber viele Geräte wie Digitalmultimeter und RLC-Meter weiterhin nur mit RS232-Schnittstelle gibt, sollen hier die USB-RS232-Adapter nicht unerwähnt bleiben.
Diese Adapter enthalten zu gut 50 % den IC FT232BM: http://www.ftdichip.com/Products/FT232BM.htm . Dieser IC ist verwendbar bis 4 Mbit/s, die aber die meisten Mikrocontroller nicht schaffen.
Nach der Installation des Treibers, die unter Linux meist entfällt, da der Treiber meist dabei ist und automatich geladen wird, verhält sich so ein Adapter wie eine serielle Schnittstelle, die man unter Linux ab /dev/ttyUSB0 findet, während man die klassischen seriellen Schnittstellen ab /dev/ttyS0 findet.
Zusätzlich eignet sich ein USB-RS232-Adapter auch zum direkten Anschliessen eines Mikrocontrollers, da das Interface-IC, dass zwischen USB und RS232 wandelt, die RS232-Signale nur als TTL-Pegel an eine Pegelwandler-IC weitergibt.
Entfernt man den Pegelwandler-IC, so kann man einen Mikrocontroller direkt an den Interface-IC anschliessen. Wie dies aussieht, zeigt das folgende Bild, bei dem RxD, TxD und Masse an eine Buchsen-Leiste oben gehen:

USB-RS232-Adapter, geöffnet und mit
UART-Verbindung
Die 5 V Versorgungsspannung vom USB-Bus wurden hier nicht verwendet, da diese für den von mir verwendeten Mikrocontroller, MSP430, zu viel wären, aber mit einem Spannungsregler wäre auch das kein Problem.
Alternativ kann man ICs wie den FT232BM auch in die eigene Schaltung eindesignen, aber für Protypen und alte Schltungen mit Mikrocontroller ohne Pegelwandler ist so ein reduzierter Adapter hilfreich. Zudem ist so ein Adapter erfahrungsgemäss zuverlässiger als ein Pegelwandler wie MAX232 an einer seriellen Schnittstelle, insbesondere bei sehr hohen Baudraten (>=115,2 kBaud).

Daten-Protokolle

Obwohl der Standard die Schnittstelle logisch beschreibt, muss man sich auch ein paar Gedanken um das Protokoll machen, da es meist nicht reicht, Bytes zu senden und zu empfangen. Da normalerweise mehr als ein Byte zu transferieren ist, muss ein solcher Block vom Empfänger identifiziert werden. Hierzu gibt es zwei Verfahren, die auch gleichzeitig verwendet werden können:

A) Zeit-Strukturierung: Zwischen den Daten-Paketen (=gesendete Byte-Folgen) wird eine Pause gelassen und im Daten-Pakete gibt es praktisch keine Pause.

B) Steuer-Zeichen: Ein Steuer-Zeichen wie 0x00 oder 0xff kennzeichnet Anfang und/oder Ende eines Daten-Paketes.

Die Variante A hat den Vorteil, dass man die Daten unverändert ausgeben und einlesen kann, während bei der Variante B die Steuerzeichen aus den Daten verschwinden müssen. Für dieses Verschwinden wird Bit-Stuffing verwendet, für das auf die Fachliteratur verwiesen wird.
Bei der Variante B hat man auf dem PC den Nachteil, dass man ohne harte Echtzeit relativ lange Pausen von einigen hundertstel Sekunden verwenden muss.
In der Praxis wird deshalb meist A) zusammen mit bekannten Paket-Längen verwendet, wobei sich die Paket-Länge aus dem ersten Byte ergibt oder ganz einfach immer konstant ist.
Die Pausen Zwischen den Paketen werden mittels Funktionen wie usleep beim Senden und select beim Empfangen realisiert; beim Mikrocontroller werden hierfür Timer-Interrupts und Zähl-Variablen genommen.

Als nächst Protokoll-Schicht kann noch eine Fehler-Korrektur auf die vorhandenen Protokolle aufgesetzt werden, beispielsweise die 2-von-3-Funktion, die byteweise angewendet alle 1-Bit-Fehler korrigiert und sogar ein einzelnes verlorengegangenes Byte korrigiert.

Vor den beschriebenen Protokollen muss man sich auch häufig überlegen, in welcher Reihenfolge die Daten übertragen werden, denn über die serielle Schnittstelle können Daten gleichzeitig gesendet und empfangen werden, aber ein kleiner Mikrocontroller (kurz MC) hat meist nicht genügen Resourcen (RAM, ROM) um gleichzeitig Daten zu senden und zu empfangen - von dem Aufwand für die parallelen Threads auf dem MC ganz zu schweigen. Meist wird deshalb der Halfduplex-Betrieb verwendet, in dem zu jedem Zeitpunkt von jedem Gerät nur Daten empfangen oder gesendet werden. Zudem wird häufig der Master-Slave-Modus verwendet: Der Master, meist der PC, sendet an den Slave, meist der MC, eine Anforderung und der Slave antwortet - ansonsten gibt der Slave nichts aus. Hierdurch ist die PC-Software sehr einfach.

Bei der Programmierung ist auch zu berücksichtigen, dass die Datenübertragung meist ohne harte Echtzeit erfolgt und immer mit Puffern erfolgt, so dass ein in einem Stück zum Senden ausgegebenes Daten-Paket in mehreren Stücken gesendet werden kann. Zudem wird das Ausgeben vom Treiber im Hintergrund vorgenommen, so dass ohne eine Funktion, die auf das Ende des Sendens der Daten wartet, z. B. tcdrain(device_file_descriptor), die Software weiterläuft und unter Umständen schon die nächsten Daten versenden will oder gar auf eine Antwort darauf wartet, während der Ausgangs-Puffer nicht leer ist und der Empfänger der Daten noch gar nicht alle empfangen haben kann. Ebenso falsch ist es, ohne Warten auf das komplette Senden der Daten den Sendepuffer zu leeren, beispielsweise mit tcflush, da hierdurch die letzten Bytes des Daten-Paketes im Puffer gelöscht und damit nicht gesendet werden.

Beim Empfangen werden umgekehrt werden in einem Stück empfangene Daten nicht immer in einem Stück in den Empfangs-Puffer abgelegt, auch weil die Daten Bit für Bit nacheinander ankommen und schon die ersten Bytes in den Empfangspuffer geschrieben werden, während die letzten Bytes des Datenpaketes noch empfangen werden oder noch nicht eingetroffen sind. Ein häufig auftauchender Fehler ist daher beim Empfangen der Daten den Eingangs-Puffer nur einmal einzulesen. Dagegen hilft die empfangenen Bytes zu zählen und mit einer Schleife mehrmals einzulesen, bis das timeout (für das Daten-Paket-Ende) erreicht ist. Bei unbekannter Paket-Länge muss daher zwangsläufig bis zum Timeout gewartet werden.

Als Fazit ergibt sich, dass die Pufferung und serielle Übertragung der Daten den Hardware-Aufwand reduziert, aber die Programmierung etwas kompliziert macht. Der Programmierer sollte sich daher ein klares Bild vom Daten-Fluss und dazu ein Zeit-Diagramm machen. Die Software muss dieses Diagramm dann sauber umsetzen, also beispielsweise auf das komplette Senden der Daten z. B. mit tcdrain(device_file_descriptor) warten.

Programme für die serielle Schnittstelle

Es gibt kostenlose Terminal-Programme für die Serielle Schnittstelle, die meist zur Kommunikation mit anderen Rechnern verwendet werden und auch für "Remote Controll" des Bios verwendet werden können (sofern Vorhanden; meist nur auf Server-Mainboards). Das ist besonders bei Rechnern ohne Monitor sinnvoll. Es gibt diese Programme beim MS-Windows (hyperterm) und Linux (minicom).
Diese Programmm können auch verwendet werden, um mit der selber gebastelten Hardware zu kommunizieren. Dafür müssen aber die Binär-Daten nach ASCII, möglichst 7-Bit-ASCII, gewandelt werden. Ein Beispiel hierfür ist das LCR-Meter LCR 612 von Tecpel, das es auf Ebay um 110 EUR neu gibt.


Beispiel 1: Digitalmultimeter-Daten einlesen

Dieses Beispiel liest die Daten ein, die das Digitalmultimeter (kurz DMM) VC 820 (rund 45 EUR bei conrad.de) oder auch das VC 840 ständig ausgibt. Die serielle Schnittstelle ist beim DMM über einen Optokopler vom PC isoliert bis mind. 2000 V.
Da das DMM keinen Daten-Eingang hat, bzw. dieser im Gerät unbestückt ist, kann nur eingelesen werden, was das Gerät aktuell misst, so dass man zum Steuern des DMM selbser Hand anlegen muss. Es gibt andere DMMs, bei denen dies nicht nötig ist, da man sie über die Schnittstelle komplett steuern kann, aber auch deutlich mehr kosten.
Zur Spannungsversorgung für Dauermessungen kann man auch die 5 V vom USB-Bus nehmen, da die LowBat-Anzeige erst unterhalb von 4 V erscheint und das DMM nur wenige mA verbraucht.



Bild 1: Digitalmultimeter VC 820 von Conrad

Das Programm vc840.c im Detail

Das Programm ist in C für Linux, aber leicht portierbar, da nur die Schnittstellen-Funktionen angepasst werden müssen. Es sollte aber unter jedem Posix-konformen Betriebssystem ohne Modifikation funktionieren, also auch unter FreeBSD, Unix usw..
Da nur Daten eingelesen werden und die Schnittstellen-Parameter feststehen, wird als Kommandozeilen-Parameter nur die Geräte-Datei der angeschlossenen Schnittstelle benötigt.
Eingelesen werden die Daten, indem die Gerätedatei, beispielsweise /dev/ttyS0 (erste serielle Schnittstelle), mit open geöffnet wird und anschließend werden die Daten mittels read eingelesen:

...
// open the file descriptor with the read+write mode and not waiting (blocking) mode
fd = open (device, O_RDWR | O_NOCTTY | O_NDELAY);
...
read (fd, &buffer[n], 1); // write one byte into the buffer
...

Dies ist der Kern des Treibers und hierfür sind keine root-Privilegien nötig, da nur der Treiber der seriellen Schnittstelle direkt auf die Hardware zugreift.
Im Programm, steht neben dem Code zum Dekodieren der Daten noch das Setzen der nötigen Schnittstellen-Parameter, beispielsweise der Schnittstellen-Geschwindigkeit und exklusiver Zugriff auf die Schnittstelle, damit nicht mehrere Programme gleichzeitig auf die Schnittstelle zugreifen können.
Gemäß dem Serial Programming Howto wird zum Empfang der Daten select verwendet und es sind noch einige Überprüfungen eingebaut, da die Datenübertragung über die serielle Schnittstelle nicht allzu zuverlässig ist. Hierbei wird auch ausgenutzt, daß Mikrocontroller die Daten mittels einer Interrupt-Service-Routine versenden, so daß die Daten in lückenlosen Pakten mit langen Pausen übertragen werden, wenn keine Fehler auftreten.
Im Programm ist auch ein Timeout-Posix-Thread, der nötig ist für einige serielle Schnittstellen und USB-RS232-Adapter, die sich zwar öffnen, aber nicht initialisieren lassen und den betreffenden Thread an dieser Stelle anhalten, selbst wenn die Schnittstelle nicht-blockierend geöffnet wird.

Hier ein Kommanodzeilen-Beispiel zu dem Programm, das die empfangenen Werte und aufgetretenen Fehlermeldungen/Statusmeldungen sowohl zusammen in der Konsole anzeigt, als auch die Meßwerte separat in "data" speichert und die Fehlermeldungen/Statusmeldungen separat in "log.err" speichert:

{ ./vc840 /dev/ttyS0 | tee data ; } 3>&2 2>&1 1>&3 | tee log.err

Die Datei data enthält die Werte (Zeit in s seit Start und Meßwert)
durch Leerzeichen getrennt:
0.4 -297.200 mV ()
0.8 -297.300 mV ()
1.1 -297.300 mV ()
...

Addon

Neben dem Programm ist noch das Skript plotting.sh, das die Messdaten sekündlich mittels Gnuplot plottet. Damit kann man den Zeitverlauf der Messdaten grafisch und quasi in Echtzeit verfolgen. Verwendet wird das Skript mit einer Pipe (|) auf der Kommandozeile:
./plotting.sh | gnuplot


Einen Artikel zu anderen, älteren Digitalmultimetern findet man im Linuxmagazin, Heft 8/1998, den es unter www.linuxmagazin.de auch online gibt.

Beispiel 2: Schaltbare Steckdosenleiste

Das zweite Beispiel dient nicht dem Messen sondern dem Steuern und es verwendet die mit unter 40 EUR relativ billige Relaiskarte 8fa, mit der man acht Steckdosen mit bis zu 6 Ampere schalten kann (nachdem man die Leiterbahnen der Relais entsprechend verstärkt hat).
Verwendet wird diese Relaiskarte in einer schaltbaren Steckdosenleiste mit geräumigem geerdeten Eisen-Gehäuse (Power-Manager, 40 EUR bei conrad.de), damit die Streufelder gut abgeschirmt werden und im Fehlerfall der FI-Schutzschalter möglichst schnell ausgelöst wird.
Zur Stromversorgung ist ein Restposten-Steckernetzteil für 12 V eingesetzt, aber man kann die Karte auch mit den 12 V vom Firewire-Bus des PC versorgen (falls vorhanden).
Da der Power-Manager nur 7 Steckdosen hat, die Karte aber 8 Relais, ist ein Ausgang extra nach Aussen geführt, zum Schalten von Niederspannung.
Damit die Masse der Karte nicht frei driftet, ist sie mit einem mittelohmigen Widerstand (hier 560 Ohm) an den Schutzleiter angeschlossen, da man bei einem Null-Ohm-Widerstand unnötig grosse Brummströme fließen würden, die einen FI-Schutzschalter auslösen können; d. h. Brummspannungen werden durch diese passive Terminierung gedämpft.

Powerbox (schaltbare Steckdosenleiste)
Bild 1: Relaiskarte 8fa in der Powerbox, beide von conrad.de, beide rund 40 EUR. Angeschlossen ist ein Eierkocher.

Das Programm relais.c im Detail

Wie beim Beispiel 1 ist das Programm in C für Linux, aber leicht portierbar.
Dieser Treiber ist im Wesentlichen wie beim vorherige Beispiel, aber mit der Erweiterung, daß auch Daten geschrieben werden mittels

write (fd, wbuf, 4);

Zudem wird hier noch das Exklusiv-Oder der Bytes eines Pakets an das Paket als Prüfsumme angehängt. Diese Prüfsumme ist sehr kurz, einfach, benötigt wenig Code und zeigt alle 1-Bit-Fehler sowie die meisten mehrbit-Fehler.
Zum Steuern wird als weiterer Parameter natürlich noch der Steuer-Befehl benötigt; beispielsweise -off zum Ausschalten:

./relais /dev/ttyUSB0 -off

Weiteres hierzu steht im Header und der Dokumentation der Karte, die man von Conrad downloaden kann.

Unter http://www.relaiskarte.thomas-dohl.de/ gibt es ein weiteres Open-Source-Programm, das mehrere dieser Karten über eine Schnittstelle ansteuert, denn diese Karten können kaskadiert werden, so dass bis zu 255 Stück von einer seriellen Schnittstelle gesteuert werden können!

Addon

Neben dem Programm ist noch das Skript demo0.sh, das alle zwei Sekunden alle Ausgänge, bis auf Nr. 2, ausschaltet/einschaltet.
Man kann es leicht anpassen um damit den PC nebenbei als 8-fache Zeitschaltuhr zu verwenden, beispielsweise indem man solche Skripte in die /etc/crontab enträgt.

Links

I/O-Ports unter Linux:
http://www.linux-magazin.de/Artikel/ausgabe/1999/10/IO/io.html

Linux I/O port programming mini-HOWTO:
http://www.tldp.org/HOWTO/IO-Port-Programming.html

ANSI/ISO-C:
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+9899%2D1999

Serial Programming HOWTO:
http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html

Serial Programming Guide for POSIX Operating Systems:
http://www.easysw.com/~mike/serial/serial.html

Buch "Linux-Treiber entwickeln, Eine systematische Einführung in Gerätetreiber für den Kernel 2.6, kostenlos und komplett online:
http://ezs.kr.hsnr.de/index.php?id=35&type=1

Buch Linux Gerätetreiber (Engl. Linux Device Drivers):
http://www.linux-magazin.de/Service/Books/Buecher/HW-Treiber/book1.html

Harte Echtzeit-Erweiterung RTAI für den Linux-Kernel:
http://www.rtai.org/

Linuxmagazin 3/2003: Artikel "Hexapoden-Steuerung: Kernelmodul für den Prüfstand":
http://www.igh-essen.com/pdf/hexapod-linuxmagazin.pdf

Posix-Threads: Buch "Pthreads Programming"

Posix-Threads-Tutorial:
http://www.llnl.gov/computing/tutorials/pthreads/

Buch "I/O-Projekte für den PC", ISBN 3-89576-129-X, mit einfachen DOS/MS-Win-Treibern für viele Schnittstellen am PC.

Ausblick

Bisher wurden nur einfache Anwender-Programme behandelt, also Programme im User-Space.
Um Redundanz zu vermeiden, veweise ich bezüglich Kernel-Space und harter Echtzeit auf das benachbarte Tutorial zum Parallelport.

Neueste Artikel
Anzeigen:
Aktuelle Newsbeiträge
Sie sind Besucher Nr. 1089395