Übung 2: Programmierung des Hardware-Timers

Transkript

1 Institut für Technische Informatik und Kommunikationsnetze Prof. Dr. B. Plattner ETH Zentrum, ETZ G-89, Gloriastrasse 35, CH-8092 Zürich Telefon: , Fax: , Internet: plattner@tik.ee.ethz.ch Zürich, Übung 2: Programmierung des Hardware-Timers 1 Einleitung 1.1 Ziel Technische Informatik 2 Das Ziel dieser Übung ist es, den Umgang mit Devicetreibern im Betriebssystem TOPSY (A Teachable Operating System) kennenzulernen und mit der Programmierung des Hardware Timers Intel 8254 auf dem Praktikumsrechner eine Grundlage für die Übungen 4 (Implementierung eines Protokolls für die zuverlässige Datenübertragung auf gestörten Leitungen) zu schaffen. 1.2 Voraussetzungen C-Programmierung: Umgang mit Pointern, Strukturen und type cast. Topsy Dokumentation Kapitel 5 ( I/O Subsystem and Driver Interface ) sowie Kenntnisse des Thread Managements mit Hilfe von Messages aus Übung 1. Die Grundlage für diese Übung ist der folgende Absatz aus Kapitel der Topsy Dokumentation: So, what has to be done when writing your own device driver? A new device number has to be created in IO.h (e.g. '#define MY_DEVICE 2'), the constant IO_DEVCOUNT must be incremented (IO.h) and a new IODeviceDesc structure has to be added to the iodevicetable. At least the functions for reading and writing have to be implemented (and filled in), a message handler is optional. Also an interrupt handler may be supplied or set to NULL (see appendix) if it should be ignored. Last but not least the fields name, base (defines the base address for memory-mapped I/O) and interrupt (if used) have to be specified. 2 Thematik 2.1 Device-Treiber in Topsy Die Dokumentation von Topsy beschreibt in Kapitel 5 I/O Subsystem and Driver Interface den Umgang mit Treibern für Hardware Bausteine (s.a. Fig. 1). Zuoberst ist das eigentliche Userprogramm, welches via der User-Schnittstelle "Syscall" (Topsy/ Syscall.c) mit entsprechenden Funktionsaufrufen ioopen(), ioclose(), ioinit(), ioread(), iowrite() Daten von/zum Treiber übermitteln kann. Der Thread "IOMain" (Topsy/IO/IOMain.c) existiert nur ein einziges Mal für alle Device-Treiber und wird vom System gestartet. Der Thread "IODeviceMain" (Topsy/IO/IODevice.c) ist ein generischer Treiber. Er setzt Messages, welche von der User-Schnittstelle "Syscall" kommen, in die Aufrufe der Treiberfunktionen um und beantwortet die User-Aufrufe mittels Meldungen seinerseits. "IODeviceMain" wird für jeden Device-Treiber vom System gestartet. Die Thread-ID, welche man beim Öffnen eines Treibers erhält, ist die ID des entsprechenden "IODeviceMain" Threads. Eidgenössische Technische Hochschule Zürich Swiss Federal Institute of Technology Zurich Ecole polytechnique fédérale de Zurich Politechnico federale di Zurigo

2 functions User Thread threads Übung 2: timer_stop Message timer_start Message Function calls: ioopen ioread ioclose iowrite ioinit files primary message flow function calls Messages: IO_INIT IO_READ IO_WRITE IODeviceMain device driver threads Syscall Message: IO_DRIVERCLOSE Messages: IO_OPEN IO_CLOSE IOMain IO driver main thread IO.h device numbers IDT385_IOMap.h base addresses Function calls: Driver_Init Driver_Read Driver_Write Driver_Close Driver_messageHandler (other drivers) intel8254 driver functions Function calls: Driver_Init SCN2681_DUART driver functions Fig. 1 Zusammenhänge der Quelltexte und Threads beim Umgang mit Device Treibern 2.2 Der Timerbaustein und die Topsy-Anbindung Der Timerbaustein auf dem Praktikumsrechner kann als einmaliger count-down Zähler programmiert werden. D.h., dem Timer wird ein Zeitintervall in [ms] vorgegeben, nachdem er sich mit einem Interrupt meldet, sofern er nicht vorher angehalten wurde. Der Timerbaustein Intel 82C54 bietet drei 16 bit Counter an. Es kann lediglich Counter 1 frei programmiert werden. Counter 0 wird in Topsy vom Scheduler benutzt, Counter 2 ist auf dem Praktikumsboard als Prescaler zu Counter 0 und Counter 1 verdrahtet. Genauere Informationen, die aber für die Durchführung des Praktikums nicht zwingend notwendig sind, befinden sich in Abschnitt 4. Counter 1 ist als IO-Device anzusprechen, d.h. über die System Calls (Syscall.c) ioinit(threadid id), ioopen(int devicenumber, ThreadId* id) und ioclose(threadid id). Die System Calls ioread() und iowrite() sind für den Timer ohne Funktion. Die Treiberfunktionen befinden sich in Topsy/IO/Drivers/intel8254.c: void timer1_interrupthandler(iodevice this); Error timer1_init(iodevice this); Error timer1_stop(iodevice this); void timer1_messagehandler(iodevice this, Message* msg); Seite 2

3 Die Treiberfunktionen setzen auf den Funktionen Error setclockvalue( ClockId cid, int period, ClockMode cmode); void tmresetclockinterrupt( ClockId cid); auf, welche sich in Topsy/Threads/mips/TMClock.c befinden. Der Interrupt Handler soll aufgerufen werden, wenn ein programmiertes Zeitintervall abgelaufen ist und der Intel-Baustein einen Interrupt ausgelöst hat. timer1_init() wird bei einem ioinit() Syscall, timer1_stop() bei einem ioclose() Syscall ausgeführt. Der Message Handler ist notwendig, da der Timer über eine Message an den Timer-Treiber Thread auf eine Zeitdauer in [ms] gesetzt und gestartet werden soll. Für diesen Fall gibt es einen eigenen Message-Typ iotimer und eine spezielle Message-Id (s.a. Topsy/Topsy/Messages.h): msg.from = < User-ThreadId >; /* current thread */ msg.id = IO_TIMER_START; /* specific message id */ msg.msg.iotimer.period = 1500; /* period in ms, e.g ms */ &msg IOTimerMsg { from id period Ist der Timer abgelaufen, ohne dass er vorher über einen ioclose()-aufruf abgebrochen wurde, so wird ein Interrupt ausgelöst. Der Interrupt Handler soll dafür sorgen, dass der Thread, welcher den Timer gesetzt hat, eine Message folgenden Typs erhält: msg.from = < Timer-ThreadId >; /* timer device driver thread */ msg.id = IO_TIMERREPLY; /* specific message id */ Das from Feld ist auf den Timer-Treiber Thread gesetzt. Dies ist zur Zeit die einzige Art von Message, die vom Timer selbst verschickt wird. Die Message wird an den Thread versendet, der vorher in der IO_TIMER_START -Message im from Feld angegeben worden ist. Diese Thread-Id sowie die Thread-Id des Treiber-Threads werden in einer dynamisch auf dem Heap allozierten Struktur vom Typ timer_temp (s. Topsy/IO/Drivers/intel8254.c) : typedef struct { ThreadId callerid; /* ThreadId of calling thread */ ThreadId timerid; /* ThreadId of Timer-driver thread */ }timer_temp; vom Message Handler abgelegt und vom Interrupt Handler benutzt. 3 Aufgaben In dieser Übung werden Sie an folgenden Files Änderungen vornehmen: Topsy/IO/IO.h Topsy/IO/IOMain.c Topsy/IO/Drivers/intel8254.c Topsy/User/testtimer.c 3.1 Inbetriebnahme des Timers Wir gehen jetzt Schritt für Schritt nach Kapitel der Dokumentation vor, um den Device-Treiber für den Intel-Baustein zu vervollständigen und das Verhalten nach Abschnitt 2.2 zu erhalten: Seite 3

4 In der Datei Topsy/IO/IO.h ist Ihnen bereits eine Devicenummer für den Timer vorgegeben worden. Entfernen Sie die Kommentarzeichen, so dass das entsprechende #define wirksam wird, und passen Sie die Konstante IO_DEVCOUNT an. Notieren Sie sich, mit welcher Devicenummer Sie den Timer später in Ihrem User-Programm ansprechen müssen. Vervollständigen Sie in Topsy/IO/IOMain.c den iodevicetable-eintrag des Datentyps IODeviceDesc (Topsy/IO/IODevice.h) für den Timer (Sie müssen wiederum einige Kommentarzeichen entfernen). Die Treiberfunktionen, die Sie dafür benötigen, befinden sich in Topsy/IO/Drivers/intel8254.h. In allen Treiberfunktionen in Topsy/IO/Drivers/intel8254.c steht Ihnen über das this Argument ein Zeiger auf den gerade von Ihnen ausgefüllten iodevicetable-eintrag zur Verfügung. Schauen Sie sich in intel8254.c daher an, wie das extension Feld genutzt wird, um Zusatzinformationen unterzubringen, die zwischen Message Handler und Interrupt Handler ausgetauscht werden. Füllen Sie nun die fehlenden Einträge im Interrupt Handler in intel8254.c aus. Schliesslich müssen Sie noch das Testprogramm, das ist der User-Thread test_timer in Topsy/User/testtimer.c, in Betrieb nehmen. Dazu sind wiederum die fehlenden Einträge in testtimer.c zu ergänzen. Schauen Sie in Topsy/User/Shell.c nach, mit welchem Thread-Namen die Funktion test_timer() als User Thread eingetragen worden ist. Lässt sich dann Topsy fehlerfrei compilieren und auf den Praktikumsrechner herunterladen, so wird in der Topsy Shell mit dem entsprechenden Thread-Aufruf von test_timer der Counter auf 1,5 Sekunden gesetzt, nach denen er sich mit einer Message meldet. Sollte sich Topsy nicht mit den Ausgaben timer set, waiting for an answer und nach 1,5s mit count down finished auf der Console melden, dann verschicken Sie wahrscheinlich Messages in Topsy falsch. 3.2 Erweiterung des Message Handlers Wenn der Timer über eine Message konfiguriert wurde, beginnt er, die angegebene Zeit in [ms] zu zählen. Möchte man ihn anhalten, bevor das Intervall beendet ist, muss man einen ioclose() System Call benutzen. In dieser Aufgabe werden Sie nun den Message Handler des Timers in intel8254.c so ergänzen, dass der Timer alternativ auch durch Empfangen einer Message angehalten werden kann. Studieren Sie erneut den Message Handler des Timers. Fügen Sie einen Abschnitt hinzu, der bei Empfang einer Message mit der Message-Id IO_TIMER_STOP (Messages.h) den Abbruch des Timers erzwingt. Machen Sie sich dazu klar, was bei einem ioclose() System Call passiert. Testen Sie den erweiterten Message Handler, indem Sie im User Thread test_timer() den Timer mit einer Message anhalten, direkt nachdem er konfiguriert wurde. Wenn Sie die Funktionalität des Timers getestet haben, entfernen Sie die debug-ausgaben (ioconsoleputstring()) in den Treiberfunktionen. Das Endergebnis dieser Aufgabe ist nicht besonders spektakulär. In Übung 4 werden Sie allerdings eine Anwendung kennenlernen, bei der Sie den Timer bei der Implementierung eines Protokolls für die zuverlässige Datenübertragung auf gestörten Leitungen permanent benötigen. Seite 4

5 3.3 Ausblick und Vertiefung Bisher wird nicht verhindert, dass mehrere Threads gleichzeitig den Timer benutzen und damit die Zählintervalle anderer Threads überschreiben können. Welchen Mechanismus aus Topsy könnte man benutzen, um die kritische Ressource zu schützen? Nehmen Sie an, dass Sie mehrere virtuelle Timer mit einem physikalischen Timer simulieren möchten. Dazu wird ein User Thread gestartet, der die Verwaltung der Timer-Anfragen (Angabe einer Zeitdauer, nach deren Ablauf der Thread benachrichtigt werden möchte) von unterschiedlichen Threads übernimmt, die entsprechenden Messages an den Timer-Treiber schickt sowie die Antworten des Timers an die entsprechenden Threads zurückgibt. Sie könnten die Anfragen z.b. in einer verketteten Liste verwalten, indem Sie die Zeitdauern zur nächsten Unterbrechung relativ zum Vorgänger in der Liste ablegen. Welche Service-Funktion(en) müsste Ihnen der Timer-Treiber dafür anbieten, die bisher nicht implementiert ist(sind)? 4 Literatur Es folgen noch Literaturangaben, die für die Durchführung des Praktikums nicht notwendig, aber hilfreich sind, wenn man den Timer genau verstehen möchte, insb. auch die Funktionen setclockvalue() und tmresetclockinterrupt() in Topsy/Threads/mips/TMClock.c, die für die Konfigurierung des Timers verantwortlich sind: Datenblatt Intel Corp.: 82C54, CHMOS Programmable Interval Timer, October 1994, erhältlich unter Auszug aus dem Handbuch des Praktikumsrechners: There are two programmable timers in the system. They are implemented in the Intel 8254 timer device on the system board and are addressed as described in the address decode table Tab. 1. Each of the two timers may be programmed as an independent real-time interrupt occurring at regular intervals. The arrangement of the timers of the 8254 is outlined in Fig. 2. oscillator 3,6864 MHz counter 2 counter timer Fig. 2 Timer arrangement counter 1... control logic CINT0 CINT1 There are actually three 16-bit counters in the 8254, designated as counters 0, 1, and 2. The arrangement used is for counter 2 to be a prescaler for each of the other counters. Counter 2, in turn, is clocked by a crystal oscillator running at 3,6861 MHz. The outputs of the timer logic, CINT0 and CINT1, are free-running signals which may be connected to any of the interrupt inputs of the R3051. Each of the timer interrupts are synchronized signals which are asserted by the counter output and deactivated by a dummy read of the timer address as indicated in Tab. 1. Tab. 1: 8254 memory mapped register addressing hex addr. function read write 1F read counter 0 write counter 0 1F read counter 1 write counter 1 1F read counter 2 write counter 2 Seite 5

6 Tab. 1: 8254 memory mapped register addressing hex addr. function read write 1F80 00C NO OP write control reg. 1F reset CINT0 NO OP 1F reset CINT1 NO OP Seite 6