 |
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:
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.
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.
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.
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.
Anzeigen:
|
