Praktikum SMR Versuch 4 - uni-due.dehl271st/Lehre/SMR/smr_prakt_v4.pdf · 2009-01-26 · 3 Unterstützung der 1-Wire-Funktionalität durch den Codevision-Compiler Zur einfachen Nutzung

Praktikum: Struktur von Mikrorechnern (SMR-P)

Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 1/23

Versuch 4

Versuche Lehrinhalte "Hardware" Lehrinhalte "Software" 1. Einführung

Vertraut werden mit STK500/501-Board, AVR-Studio (Assembler, Simula-tor) und Codevision AVR (C-Compiler)

- Struktur der Kits; Aufbau - Handhabung der Hardware - Ressourcen des AT-Mega128 - Lage und Nutzung der Ports - Adressraum und Lage von

SFRs und Interruptvektoren - Ansteuerung einer LED

- GUI und Handling AVR-Studio - GUI und Handling Codevision;

Nutzung Code-Wizard - Makros zur Port- und Pin-

Steuerung - Unterschied Assembler-Code/C-

Code - Einsatz des Simulators bei As-

sembler-und C-Projekten - Dimensionierung von Warte-

schleifen 2. Parallele Ein-/Ausgänge

Scannen eines 3x3 Tasten-feldes und Signalisierung der erkannten Taste über eine zugehörige LED

- Benutzung von PORTs als Sig-naleingänge

- Typen der Port-Ausgangsbe-schaltung

- Nutzung von schaltbaren Pull-Up-Widerständen der Port-Pins

-

- Grundlegende Handhabung der PORT Pins mit spezieller Aus-gangsbeschaltung

- Technik zum Pinsparenden Ab-tasten von Schalterereignissen durch Scanning-Verfahren; Tas-tenentprellen

- Ansprechen von PORTs über PORT- und PIN-Deklaration

3. Timer und Interrupts

Realisierung einer Blink-leuchte mit fester Blink-frequenz; Erzeugen quasi-analoger harmonischer Sig-nale; Umsetzung eines DTMF-Wähltongenerators auf Basis des Tastenfeldes

- Behandlung von Interrupts im Controller

- Timermodi (u. a. PWM) - Verknüpfung von Timerereig-

nissen mit Signalausgängen und Interrupts

- Konfiguration und Steuerung mittels SFRs

- Erzeugen analoger Spannun-gen mittels PWM

- Timernutzung zur Erzeugung eines Signalwechsels mit defi-nierter Frequenz

- Interruptserviceroutinen - dynamische Konfiguration von

PWM-Signalen - Realisieren von Berechnungen

mittels "lookup table" - Vorteilhafte Umsetzung von Re-

chenfunktionen 4. 1-Wire-Bus

Identifizieren, ansprechen, abfragen und steuern von Busteilnehmern am Beispiel von Temperatursensoren DS18S20 (Dallas)

- Bus-Kommunikationskonzepte (hier: Master-Slave)

- Protokollrahmen - Busankopplung/Bustiming - Nutzung des USART0

- Teilnehmeridentifikation mittels ID-Suchbaum

- CRC-Handling zur Detektion von Übertragungsfehlern

- Codierung und Umwandlung von Temperaturwerten


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 2/23

Inhalt 1 Hardware- und Timing-Konzepte eines 1-Wire-Bussystems 2 Basisfunktionen von 1-Wire-Komponenten 3 Unterstützung der 1-Wire-Funktionalität durch den Codevision-Compiler 4 Praktischer Teil zum Termin 9 4.1 Initial-Konfiguration von 1-Wire-Komponenten mit dem Code-Wizard 4.2 Aufgabe: Erstellen eines Programms, über das mit allen am Bus angeschlossenen 1-

Wire-Komponenten ein Kontakt hergestellt wird, wobei die Anzahl der Bus- teilnehmer und ihr jeweiliger Komponententyp ermittelt und auf geeignete Weise über die LED-Zeile des STK500-Boards periodisch signalisiert wird

5 Praktischer Teil zum Termin 10 5.1 Spezifische Funktionen des 1-Wire-Temperatursensors DS18S20 5.2 Konfiguration des USART0 mit dem Code-Wizard und Nutzung für die Datenausgabe 5.3 Aufgabe: Erstellen eines Programms, durch das mit einem am Bus angeschlossenen

1-Wire-Temperatursensor vom Typ DS18S20 Temperaturmesswerte erfasst und über die serielle Schnittstelle (RS-232) als "Klartext" an einen PC übertragen werden können

6 Praktischer Teil zum Termin 11 6.1 Initial-Konfiguration des DS18S20 mit dem Code-Wizard 6.2 Fehlerprüfung mit Hilfe von CRC-Werten 6.3 Aufgabe: Erstellen eines Programms, mit dem die Temperaturmesswerte aller am

Bus angeschlossenen und mittels CRC-Prüfung fehlerfrei identifizierten Temperatursensoren vom Typ DS18S20 periodisch abgefragt und zusammen mit der jeweiligen Sensoradresse über die serielle Schnittstelle (RS- 232) als "Klartext" an einen PC übertragen werden können

Anhang: A Flussdiagramme zum Kommunikationsablauf


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 3/23

1 Hardware- und Timing-Konzepte eines 1-Wire-Bussystems Bussysteme sind Leitungssysteme mit ihren zugehörigen Steuerungskomponenten, die den Zweck haben Daten zwischen elektronischen Komponenten eines Systems, aber auch Systemübergreifend auszutauschen. Ein Kernaspekt ist dabei, dass über Bussyste-me in der Regel mehr als zwei Busteilnehmer miteinander kommunizieren und sich somit der Verkabelungsaufwand gegenüber einer diskreten Einzelverbindung von jeder Kompo-nente mit jeder anderen Komponente erheblich verringert. Entsprechend der Vielfalt an Anwendungsgebieten für Bussysteme (z. B. Komponentenvernetzung im PC, Feldbus-Vernetzung von Maschinen und Komponenten in Fahrzeugen, Vernetzung von Kompo-nenten der Gebäudeinstallationstechnik etc.) sind die Anforderungen an ein geeignetes Bussystem hinsichtlich z. B. Topologie (Stern, Baum, Linie), Zahl der Verbindungsleitun-gen, max. Teilnehmerzahl, max. Leitungslängen, max. Übertragungsraten, Störfestigkeit bzw. Fehlertoleranz etc. sehr unterschiedlich. Bei dem in diesem Praktikumsversuch verwendeten 1-Wire-Bus handelt es sich um ein einfaches Bussystem zur Vernetzung von elektronischen Komponenten wie Sensoren, kleinen Festwert-Speicherbausteinen, Echtzeituhren-ICs, etc. die auf einer gemeinsamen Platine untergebracht sind oder leitungsgebunden über wenige Meter räumlich getrennt voneinander vernetzt sind. Die Kommunikation der Komponenten erfolgt dabei seriell und bidirektional im Halbduplex-Verfahren (d. h. Senden und Empfangen erfolgt sequentiell) und asynchron (ohne Übertragungstakt) über eine gemeinsame Leitung (daher "1-Wire"). Das folgende Bild zeigt die Blockstruktur einer typischen Vernetzung eines Mikrocontrol-lers (als Bus-Master) mit mehreren 1-Wire-Komponenten.

Wie beim Bus-Master oben erkennbar, kann jeder Busteilnehmer die gemeinsame Buslei-tung DQ treiben (Daten senden, entsprechend Tx) oder alternativ an der Busleitung "hor-chen" (Daten empfangen, entsprechend Rx). Da Port-Anschlüsse eines Mikrocontrollers bidirektional verwendbar sind, reicht ein Port-Pin für beide Funktionen (Rx und Tx) aus. Jeder 1-Wire-Bus besitzt genau einen Bus-Master (z. B. ein Mikrocontroller) und einen oder mehrere Bus-Slaves (den 1-Wire-Komponenten). Eine Buskommunikation findet da-bei zu einer Zeit immer nur zwischen dem Master und einer Slave-Komponente statt. Der Master initiiert dabei jede Verbindung durch Senden eines Reset-Pulses, woraufhin jede

Bus-Master

Rx

Tx

4,7 kΩ

VDD 1-Wire-Kom-ponente 1 GND DQ VDD

VDD

1-Wire-Kom-ponente n GND DQ VDD

VDD


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 4/23

Slave-Komponente mit einem Präsenz-Puls antwortet. Das nachfolgende Timing-Diagramm zeigt die Abläufe beim Verbindungsaufbau.

Die im Bild angegebenen Mindest-Signalzeiten sind beim Treiben von Signalen unbedingt einzuhalten bzw. bei zu lesenden Signalen entsprechend abzuwarten. Im Anschluss an die Initialisierungssequenz können vom Master durch gezielte Adressie-rung einer betreffenden Slave-Komponente ein Befehls-Wort und gegebenenfalls erforder-liche weitere Datenworte an diese Komponente übertragen werden. Die angesprochene Komponente reagiert dann entsprechend dem Befehls-Wort, d. h. sie führt den Befehl aus und/oder sendet ein Datenwort (z. B. Quittungssignal, Statusinformation, Messwert etc.) an den Master zurück. Nachfolgend sind die Timing-Sequenzen für das Schreiben und Lesen eines Datenbits je nach Bitpegel dargestellt.

Bus-Master treibt "0"-Pegel

1-Wire-Komponenten treiben "0"-Pegel

Pull-Up-Widerstand bestimmt Buspegel

Bus-Master treibt "0"-Pegel

1-Wire-Komponenten treiben "0"-Pegel

Pull-Up-Widerstand bestimmt Buspegel


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 5/23

Auch hierbei sind die im Bild angegebenen Mindest- und Höchst Signalzeiten beim Trei-ben von Signalen unbedingt einzuhalten bzw. bei zu lesenden Signalen entsprechend ab-zuwarten. Durch die unterschiedlichen Signalzeiten, je nach Bitpegel und die großen zu-lässigen Zeittoleranzen, ist eine spezifische Datenübertragungsrate für den 1-Wire-Bus nicht angebbar. Typische erzielbare Werte liegen bei ca. 50kBit/s.

2 Basisfunktionen von 1-Wire-Komponenten Jede 1-Wire-Komponente (Slave) besitzt neben den für ihre spezifische Funktion (als Sensor, Speicher, etc.) erforderlichen Schaltungskomponenten und den zur Busankopp-lung und Energieversorgung dienenden Funktionseinheiten als allgemeine Komponenten auch einen 64 Bit großen ROM-Bereich, in dem eine vom Hersteller vergebene individuel-le 64 Bit umfassende Registrierungsnummer enthalten ist. Diese besteht aus einem 8-Bit-Familiencode, der den Typ der 1-Wire-Komponente beschreibt (z. B. der hier verwendete Temperatursensor DS18S20 besitzt die Typkennzeichnung 0x10), gefolgt von der indivi-duellen 48-Bit-Seriennummer und einer 8-Bit-Prüfsumme (CRC-Code) zur Fehlererken-nung. Auf Basis dieser Registrierungsnummer ist eine eindeutige Identifikation jedes ein-zelnen Busteilnehmers und damit ein gezieltes Ansprechen (Adressieren) von Teilneh-mern durch den Bus-Master möglich. Dies setzt jedoch voraus, dass der Bus-Master die Adressen aller am Bus angeschlossenen Teilnehmer kennt. Für das Ermitteln der Teil-nehmeradressen und das gezielte Ansprechen der Busteilnehmer (Slaves) durch den Bus-Master gibt es verschiedene sog. ROM-Kommandos. Nachfolgend werden die wichtigsten dieser ROM-Kommandos hinsichtlich ihrer Funktion kurz beschrieben. "Search-ROM"-Kommando (Befehls-Code: 0xF0) Mit diesem Befehl verbunden ist ein komplexer Suchalgorithmus, der es dem Bus-Master erlaubt alle Busteilnehmer-Adressen zu ermitteln. Eine Beschreibung der Funktion dieses Algorithmus würde den Rahmen dieses Praktikumsversuchs sprengen. Eine detaillierte Beschreibung findet sich in der "Application-Note 187" zu den 1-Wire-Komponenten der Firma Maxim/Dallas (siehe Download-Bereich zum Praktikum). Der Algorithmus zur Teilnehmersuche unter Nutzung des "Search-ROM"-Kommandos ist in einer speziellen C-Funktion des Codevision-Compilers implementiert (s. Beschreibun-gen später), so dass die genaue Kenntnis der Kommando-Funktion hier nicht zwingend erforderlich ist. "Read-ROM"-Kommando (Befehls-Code: 0x33) Als Antwort auf diesen vom Bus-Master gesendeten Befehl an alle eventuellen Busteil-nehmer (Slaves) sendet jeder Slave seinen individuellen 64-Bit-ROM-Code (Adresse) an den Master zurück. Dieser Befehl sollte sinnvollerweise nur benutzt werden, wenn sicher-gestellt ist, dass außer dem Bus-Master nur ein weiterer Bus-Teilnehmer (Slave) am Bus angeschlossen ist, da es sonst zu Signal-Kollisionen kommt, wodurch die empfangenen Adressinformationen verfälscht werden. "Match-ROM"-Kommando (Befehls-Code: 0x55) Mit diesem Kommando und einer nachfolgend übertragenen 64-Bit-Adresse spricht der Bus-Master gezielt einen Busteilnehmer an. Nur der Busteilnehmer, dessen 64-Bit-ROM-Code exakt der vom Master gesendeten Adresse entspricht, ist für nachfolgende Befehle


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 6/23

selektiert. Alle anderen Busteilnehmer reagieren auf weitere Befehle bis zur nächsten Initi-alisierungssequenz nicht. "Skip-ROM"-Kommando (Befehls-Code: 0xCC) Mit diesem Kommando adressiert der Bus-Master alle Teilnehmer des Busses gleichzeitig und setzt damit für die nachfolgenden Befehle bis zur nächsten Initialisierungssequenz die spezifische Adressierung außer Kraft. Dieses Kommando kann sinnvoll zum Übertragen eines Trigger-Kommandos (im vorliegenden Praktikum z. B. zum gleichzeitigen Starten der Messungen aller angeschlossenen Temperatursensoren) eingesetzt werden. Außer-dem kann mit diesem Kommando bei nur einer einzigen 1-Wire-Komponente am Bus die in diesem Fall nicht erforderliche spezifische Adressierung für die Übermittlung nachfol-gender Befehle übersprungen werden.

Darüber hinaus gibt es je nach Funktion der jeweiligen 1-Wire-Komponent noch weitere Kommandos (Befehle) mit denen spezifische Steuerungs-, Status- und Ergebnisdaten zwischen Master und Slave übermittelt werden. Der Ablauf der Kommunikation zwischen dem Bus-Master und einem oder allen 1-Wire-Komponenten (Slaves) am Bus erfolgt im-mer nach dem gleichen Schema, in den Schritten: 1. Initialisierung (s. Beschreibung unter Punkt 1) 2a. Senden eines ROM-Kommandos (adressiert einen oder mehrere Busteilnehmer) 2b. Empfangen der Rückmeldungen des/der Slaves (optional, je nach Kommando) 3a. Senden eines spezifischen weiteren Befehls (optional, je nach Komponentenfunktion) 3b. Empfangen der Rückmeldungen des/der Slaves (optional, je nach Befehl)

Eine Übersicht über die Kommunikations-Abläufe, bei den verschiedenen Kommandos des im Praktikum verwendeten 1-Wire-Temperatursensors vom Typ DS18S20, in Form von Flussdiagrammen findet sich Anhang zu dieser Versuchsbeschreibung.

3 Unterstützung der 1-Wire-Funktionalität durch den Codevision-Compiler Zur einfachen Nutzung von 1-Wire-Komponenten sind im Codevision-Compiler sowohl eine Bibliothek 1wire.h mit Funktionen für allgemeine Aufgaben im Zusammenhang mit der Kommunikation zwischen einem Master und einem oder mehreren Slaves implementiert, als auch in weiteren Bibliotheken Funktionen für spezielle Komponenten wie den 1-Wire-Temperatursensor DS18S20. Um diese Funktionen nutzen zu können, müssen per Label-Zuweisung auf Assembler-Ebene die Label __w1_port und __w1_bit deklariert und mit den betreffenden Werten belegt werden. Auf diese Weise erfahren alle 1-Wire-Funktionen über welchen Port und Pin die Kommunikation erfolgt. Im vorliegenden Praktikumsversuch ist dies der Pin 0 von Port D. Nachfolgend werden die wichtigsten Funktionen der Bibliothek 1wire.h hinsichtlich ihrer Anwendung kurz beschrieben. "w1_init()"-Funktion Diese Funktion führt eine Initialisierungssequenz (s. Punkt 1) am Bus durch und ermittelt dabei, ob überhaupt eine 1-Wire-Komponente am Bus angeschlossen ist. Der zurückge-gebene Wert ist entsprechend '1', wenn Busteilnehmer gefunden wurden und '0', wenn kein Busteilnehmer auf die Initialisierungsanfrage reagiert hat.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 7/23

"w1_search(<Code eines Suchbefehls>, <Zeiger auf ROM-Code-Tabelle>)"-Funktion Diese Funktion führt die komplexe Suche nach den Adressen aller am Bus verfügbaren Teilnehmer (Slaves) mit dem spezifizierten Suchbefehl aus. Die gefundenen Adressen werden dann in der angegebenen ROM-Code-Tabelle abgelegt. Neben dem bereits be-schriebenen Suchbefehl "Search-ROM" (Befehlscode 0xF0), der alle Bus-Teilnehmer an-spricht, gibt es bei einigen 1-Wire-Komponenten auch spezielle Suchbefehle, die nur Bus-Teilnehmer ansprechen, die sich in einem spezifischen Zustand (z. B. einem "Alarmzu-stand") befinden. Auch diese lassen sich durch Angabe des entsprechenden Befehls-Codes mit dieser Funktion verwenden. Die ROM-Code-Tabelle sollte zuvor als Feld ("Array") mit an die erwartete Busteilnehmer-zahl angepasster Größe deklariert werden. Je Teilnehmer-Adresse werden hierbei 9 Ein-tragsfelder (8 Felder für den 64-Bit ROM-Code und 1 Feld für ein optional übertragenes Status-Bit) benötigt. Der Rückgabewert der "w1_search"-Funktion entspricht der Anzahl der aufgefundenen Busteilnehmer. "w1_read()"-Funktion Diese Funktion liest ein komplettes Daten-Byte vom Bus. Sie wird dort sinnvoll eingesetzt, wo zuvor durch den Bus-Master ein Slave adressiert und per Befehl zur Übertragung von Informationen aufgefordert wurde. Je nach Anzahl der erwarteten Daten-Bytes müssen dann entsprechend viele "w1_read"-Funktionen ausgeführt werden. Der Rückgabewert der Funktion entspricht dem Byte-Wert von 8 gelesenen Bits in Folge. "w1_write(<zu übertragendes Daten-Byte>)"-Funktion Diese Funktion schreibt ein komplettes Daten-Byte auf den Bus. Sie wird dort sinnvoll ein-gesetzt, wo beispielsweise ein ROM-Kommando, ein anderer Befehls-Code oder Daten an einen Busteilnehmer (Slave) gesendet werden sollen. Der Rückgabewert der Funktion ist entsprechend '1', wenn die Wertübertragung fehlerfrei ausgeführt werden konnte und '0', wenn Übertragungsprobleme aufgetreten sind.

4 Praktischer Teil zum Termin 9 4.1 Initial-Konfiguration von 1-Wire-Komponenten mit dem Code-Wizard Der Code-Wizard-Konfigurator unterstützt die Verwendung von 1-Wire-Komponenten durch das automatische einbinden der erforderlichen Funktions-Bibliothek 1wire.h, die menügestützte Auswahl des für die 1-Wire-Kommunikation verwendeten Ports und Pins und die zugehörige Konfiguration des betreffenden Ports, sowie durch die automatische Deklaration der Label __w1_port und __w1_bit auf Assembler-Ebene. Das Timing für alle 1-Wire-Übertragungen auf dem Bus erfolgt ohne die Nutzung von Inter-rupt-gestützten Timerfunktionen allein durch die Verwendung von Delay-Funktionen. Da-her müssen während der Buskommunikation unbedingt alle Interrupts deaktiviert werden, damit das Bus-Timing nicht unterbrochen bzw. gestört wird. Das folgende Bild zeigt die für den ersten Teilversuch notwendigen Einstellungen des Konfigurators.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 8/23

Die spezifischen Funktionen des 1-Wire-Temperatursensors DS18S20 sollten für den fol-genden Teilversuch noch nicht aktiviert bzw. konfiguriert werden.

4.2 Aufgabe: Erstellen eines Programms, über das mit allen am Bus angeschlossenen 1-Wire-Komponenten ein Kontakt hergestellt wird, wobei die Anzahl der Busteilnehmer und ihr jeweiliger Komponententyp ermittelt und auf geeignete Weise über die LED-Zeile des STK500-Boards periodisch signalisiert wird

Die für die Beantwortung der nachfolgenden Fragen und die Ausführung des Programm-entwurfs zur folgenden Aufgabenstellung notwendigen Informationen können den Unterla-gen zu den Praktikumsversuchen 1, 2 und 3, den vorangegangenen Kapiteln, den Daten-blättern des AT-Mega128 und des DS18S20 sowie dem Handbuch zum Programm Code-vision-AVR entnommen werden. Vorbereitende Fragen zur Klärung:

• Welcher Port des AT-Mega128 und welcher Pin dieses Ports werden als Kommunikati-onsleitung DQ für den 1-Wire-Bus verwendet? ___________________

• Mit welcher C-Anweisung werden die 1-Wire-Funktionen des Codevision-Compilers für die eigene Verwendung verfügbar gemacht? ___________________

• Wie lautet die Deklaration eines Feldes ("Array") mit Namen w1_devices_rom_codes, das für die Aufnahme der durch die Funktion w1_search(..) ermittelten Komponenten-Adressen (ROM-Codes) für maximal 4 Busteilnehmer geeignet ist, in C-Notation? ______________________________________________________________________

1-Wire-Grundeinstellungen: Wahl von Port und Anschluss-pin für die Busleitung DQ

Spezifische Einstellungen: Aktivierung und Konfiguration zusätzlicher Funktionen für spezifische Komponenten


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 9/23

• Mit welcher C-Anweisung werden einer Variablen w1_devices die durch die Funktion w1_search(..) ermittelte Anzahl aller verfügbaren Busteilnehmer zugewiesen? ______________________________________________________________________

• Mit welcher C-Quellcodezeile lässt sich die ermittelte Anzahl der Busteilnehmer (s. vor-herige Frage) in eine äquivalente Folge von '1'-Bits, beginnend mit der Bitstelle 0, um-wandeln und für die LED-Anzeige in eine Variable LED_code schreiben (Bsp.: LED_code = 0b00000111 steht für 3 gefundene Teilnehmer)? ______________________________________________________________________

Praktische Programmieraufgabe: Entwickeln Sie ein C-Programm mit dem Namen SMR_Termin9, das – einen durch den Code-Wizard erzeugten Initialisierungsteil besitzt, in dem die 1-Wire-

Funktionalität für den gewünschten Port-Pin aktiviert wird und die allgemeinen 1-Wire-Funktionen des Codevision-Compilers verfügbar gemacht werden.

– ein Hauptprogramm besitzt, das aus einem Initialisierungsteil und einer Endlosschleife besteht, wobei die Endlosschleife für die periodische LED-Signalisierung von unter-schiedlichen Informationen über die gefundenen Busteilnehmer genutzt wird.

– die Zahl der am Bus verfügbaren Komponenten ermittelt und als blinkende LED-Balkenanzeige mit jeweils einem LED-Element je gefundenem Busteilnehmer darstellt. Das Blinken soll dabei 5x je Anzeigeperiode mit jeweils 2 Hz Blinkfrequenz erfolgen.

– die ROM-Codes aller am Bus verfügbaren Komponenten ermittelt, aus ihnen die jewei-ligen Komponenten-Codes extrahiert und diese mit Hilfe der LEDs als Binärwerte im Wechsel darstellt. Der Komponenten-Code jedes Busteilnehmers soll dabei für 2 s sichtbar sein, mit einer "Dunkelpause" von 0,5 s zwischen den Codes.

– die Anzahl der Komponenten und ihre Typencodes im periodischen Wechsel per LED-Anzeige darstellt.

Überprüfen Sie die Funktion des von Ihnen entwickelten Programms auf dem Praktikums-Board.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 10/23

5 Praktischer Teil zum Termin 10 5.1 Spezifische Funktionen des 1-Wire-Temperatursensors DS18S20 Bei dem 1-Wire-Baustein DS 18S20 der Firma Maxim/Dallas handelt es sich um einen Temperatursensor mit drei Anschlusspins (Versorgungsanschlüsse VDD und Gnd, Bus-kommunikationsanschluss DQ), der in einem Standard-Transistorgehäuse (Typ TO-92) untergebracht ist. Mit ihm lassen sich Temperaturen im Bereich -55°C ≤ T ≤ +125°C mit einer mittleren Genauigkeit von ∆T = ±0,5°C messen. Das folgende Bild zeigt die Block-struktur des DS18S20.

Neben dem 64-Bit-ROM-Speicher, der den eindeutigen Identifikationscode des Tempera-tursensors enthält, verfügt der D18S20 über einen RAM-Speicherbereich von 9 Byte, der als "Scratch-Pad" bezeichnet wird, und über einen 2 Byte großen EEPROM-Speicherbe-reich. Im RAM-Speicherbereich wird u. a. der zuletzt gemessene Temperaturwert fest-gehalten und sein Inhalt kann durch entsprechende Befehle über den Bus abgefragt wer-den. Der EEPROM-Speicher ermöglicht das Setzen von nicht flüchtigen Temperatur-Grenzwerten, deren Überschreiten zu einer detektierbaren Alarmbedingung führt. Die Be-deutung der "Scratch-Pad"- und EEPROM-Inhalte zeigt das folgende Bild.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 11/23

Für die Teilversuche im vorliegenden Praktikum werden von den "Scratch-Pad"-Inhalten nur die Bytes 0 und 1 mit den Temperaturmesswerten benötigt. Neben den bereits unter Punkt 2 erläuterten ROM-Kommandos zur allgemeinen "Anspra-che" von Busteilnehmern versteht der DS18S20 darüber hinaus weitere, seine spezielle Funktion als Temperatursensor betreffende, Befehle. Die beiden wichtigsten, für das vor-liegende Praktikum relevanten, Befehle dieser Gruppe von speziellen Kommandos werden im Folgenden hinsichtlich ihrer Funktion kurz beschrieben. Eine vollständige Beschreibung findet sich im Datenblatt zum DS18S20 der Firma Maxim/Dallas (siehe Download-Bereich zum Praktikum). "Convert T"-Befehl (Befehls-Code: 0x44) Mit diesem Befehl kann eine erneute Messung der aktuell am Ort des Sensors vorherr-schenden Temperatur ausgelöst werden. Dies ist erforderlich, da der DS18S20 nicht stän-dig misst, sondern nur auf Anforderung (mittels "Convert T"-Befehl) durch den Bus-Master. Die Zeitdauer tConv vom Start der Temperaturmessung bis zum Vorliegen des Ergebnisses beträgt maximal tConv = 750 ms. Danach befindet sich der gemessene und digitalisierte Temperaturwert an den o. g. Speicherstellen im "Scratch-Pad". Während der Messphase antwortet der DS18S20 auf alle Leseanforderungen durch den Master mit dem Bitwert '0'. Erst nach vorliegen eines neuen Temperaturmesswertes werden alle folgenden Lesean-forderungen mit dem Bitwert '1' quittiert. Auf diese Weise kann der Master erkennen, wann gültige Temperaturmesswerte vorliegen. Das Datenformat der im "Scratch-Pad" abgelegten Temperaturwerte zeigt folgendes Bild:

Beide Byte-Werte bilden zusammen einen 16-Bit-Wert, der als binärer, vorzeichenbehafte-ter Zahlenwert in 2'er-Komplement-Darstellung zu lesen ist. Die mit "S" bezeichneten Bit-Werte entsprechen dabei dem Vorzeichen des Temperaturwerts (positiv bei S = 0; negativ bei S = 1). Durch Division der 16-Bit-Zahl durch den Wert 2 ergibt sich der gemessene Temperaturwert in der Einheit °C. Die Zahlenwertangabe erfolgt somit in 0,5°C Schritten. "Read Scratchpad"-Befehl (Befehls-Code: 0xBE) Durch Senden dieses Befehls lassen sich, in der Folge Byte 0 bis Byte 8, alle 9 Byte des RAM-Speicherbereichs ("Scratch-Pad") eines zuvor adressierten DS18S20 durch sukzes-sive nachfolgende Leseanforderungen abfragen. Der Master kann die Lesesequenz jeder-zeit durch Senden einer Initialisierungssequenz abbrechen, z. B. dann, wenn alle interes-sierenden Bytes bereits gelesen wurden und die weiteren "Scratch-Pad"-Inhalte nicht be-nötigt werden. 5.2 Konfiguration des USART0 mit dem Code-Wizard und Nutzung für die Daten-

ausgabe Mit zunehmender Anzahl und Komplexität der von einem technischen System an den Be-nutzer zu übermittelnden Informationen, reichen einfache optische Signalisierungsmetho-den, wie sie bei den vorherigen Versuchen mit Hilfe von einzelnen bzw. Gruppen von


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 12/23

LEDs angewendet wurden, nicht mehr aus. Sinnvoll sind in diesen Fällen z. B. Sprachin-formationen in Textform, die für den Benutzer auf einer geräteseitigen Anzeige oder auf dem PC-Bildschirm erscheinen. Für die sequentielle Übertragung von Daten (z. B. auch Textzeichen) an andere Systeme (z. B. den PC des Entwicklungssystems) besitzt der AT-Mega128 u. a. zwei sogenannte USARTs (Universal Serial Asynchronous Receiver Transmitter), USART0 und USART1, die für den Aufbau einer seriellen Schnittstelle nach dem RS-232-Standard geeignet sind. Auf dem STK500-Board befinden sich dazu entsprechende Treiberbausteine und Schnitt-stellenstecker mit denen die signal- und hardwareseitigen Spezifikationen nach dem RS-232 Standard erfüllt werden können. Für den Anschluss an den PC kann dabei das bereits für die Programmierung des Boards verwendete Schnittstellenkabel verwendet werden, das für die serielle Kommunikation mit dem PC vom mittleren auf den rechten Steckplatz (Schnittstellenstecker 2 im nachfolgenden Bild) umgesteckt werden muss.

Im Mikrocontroller übernimmt jeder USART als nebenläufiger Prozess die bitserielle Über-tragung jedes Bytes einer Nachricht (Nutzinformation), ergänzt um ein führendes "Start-Bit" und abschließend um ein optionales "Parity-Bit" zur Fehlererkennung und ein oder mehrere "Stop-Bits" als Nachrichtenrahmen ("Frame"). Die "Bestandteile des "Frames" dienen der Synchronisation von Sender und Empfänger und der Sicherstellung einer kor-rekten Datenübertragung. Der Übertragungstakt wird, wie bei den Timerfunktionen des AT-Mega128, durch eine Taktteilereinheit vom Systemtakt abgeleitet und kann, wie auch die o. g. Frame-Parameter, in definierten Stufen über zugehörige SFRs eingestellt werden. Die komplexen Vorgänge der seriellen Datenübertragung werden durch den USART weit-gehend automatisiert und darüber hinaus, für das einfache Handling in C, durch vom Co-de-Vision-Compiler zur Verfügung gestellte Funktionen unterstützt. Da im vorliegenden Praktikum die serielle Schnittstelle nur in einfachster Form und unidi-rektional zu Protokollzwecken genutzt wird, soll an dieser Stelle auf eine eingehende Be-schreibung aller Funktionen und Zusammenhänge verzichtet werden. Durch die Verwen-dung des Code-Wizard für die Konfiguration des hier genutzten USART0 werden die not-wendigen Einstellungen auf die Eingabe weniger Parameter reduziert. Weitergehende In-formationen können dem Datenblatt des AT-Mega128 und dem Handbuch zum Programm Codevision-AVR entnommen werden.

Schnittstellenstecker 1: Über diesen Anschluss erfolgt die Programmierung

Schnittstellenstecker 2: Über diesen Anschluss erfolgt die serielle Kommunikation


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 13/23

Die im Bild unten gezeigten Einstellungen für den USART0 sollten für die beiden folgen-den Teilversuche zum Versuch 4 gewählt werden.

Zum Empfang und zur Darstellung der über die serielle Schnittstelle vom Mikrocontroller an den PC gesendeten Text-Informationen, ist in die CodeVision-Entwicklungsumgebung ein sogenanntes "Terminal"-Fenster integriert, das empfangene Daten-Bytes als ASCII-codierte Textzeichen interpretiert (American Standard Code for Information Interchange) und entsprechend auf dem Bildschirm als "Klartext" darstellt. Das "Terminal"-Fenster kann über das Menü Tools→Terminal aufgerufen werden und die Übertragungsparameter für die serielle Übertragung auf der PC-Seite lassen sich über das Menü Settings→Terminal einstellen. Die dort eingestellten Parameter sollten mit den im bild oben gezeigten, für den Mikrocontroller gewählten, Parametern für die serielle Übertragung korrespondieren. Auf der Mikrocontroller-Seite stehen komfortable Ausgabefunktionen für die USART-Schnittstelle 0 zur Verfügung, wenn zuvor aus der Funktionsbibliothek die Header-Datei stdio.h in den Quellcode eingebunden wurde. Für die beiden folgenden Teilversuche des Praktikums wird aus dieser Funktionsbibliothek lediglich die Funktion printf(..) benötigt, die eine formatierte Ausgabe von ASCII-codierten Zeichenketten ("Strings") erlaubt. Die folgenden typischen Anwendungsbeispiele sollen die Nutzung von printf(..) aufzeigen: signed int i=31; printf("Hallo Welt\r\n"); // Die durch den Compiler im Flash-Speicher abge-

legte Zeichenkette "Hallo Welt", aus 10 ASCII-Zeichen, wird sequentiell in der Folge 'H'→'a'→'l'→'l'→'o'→' '→'W'→'e'→'l'→'t' an den USART0 übergeben, der die jeweiligen Zeichen-Codes um den "Frame" ergänzt und zusammen bitweise, beginnend mit dem "Start"-Bit, über die Schnitttelle an den PC überträgt. Gleiches gilt für die Steuerzeichen '\r' (Zeilenrücksprung) und '\n' (neue Zeile).

Sender-/Empfänger-Aktivierung: Verwendet wird lediglich die Sen-de-Funktion des USART0

Übertragungsart und –para-meter: Gewählt werden die asynchrone Übertragung, und die Standard-Parameter für Daten-"Frames"

Übertragungsrate: Als Übertragungsrate wird der Standardwert von 9600 Baud (Bit/s) gewählt


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 14/23

printf("Dez. %-d = Hex. %X", i, i); // Im Argument der Ausgabefunktion können sich außer den festen Textanteilen auch variable Ausgabewerte (hier: Variable "i") befinden, die an den durch '%' markierten Stellen in formatier-ter Form (z. B. '-'= linksbündige Wertfolge, '+' = linksbündige Wertfolge mit Vorzeichen, 'd' = signed Integer als Dezimalzahl, 'X' = signed In-teger als Hexadezimalzahl mit Großbuchstaben) als Textzeichen eingefügt werden. Im Beispiel lautet die ausgegebene Zeichenkette: "Dez. 31 = Hex. 1F"

Wegen der Vielfalt der Syntaxvarianten und Formatierungsmöglichkeiten der printf(..)-Funktion wird an dieser Stelle auf eine weitere detaillierte Beschreibung verzichtet und, bei Bedarf, auf die Erläuterungen in der Hilfefunktion des CodeVision-Entwicklungssystems verwiesen. 5.3 Aufgabe: Erstellen eines Programms, durch das mit einem am Bus ange-

schlossenen 1-Wire-Temperatursensor vom Typ DS18S20 Tempera- turmesswerte erfasst und über die serielle Schnittstelle (RS-232) als "Klartext" an einen PC übertragen werden können

Die für die Beantwortung der nachfolgenden Fragen und die Ausführung des Programm-entwurfs zur folgenden Aufgabenstellung notwendigen Informationen können den Unterla-gen zu den Praktikumsversuchen 1, 2 und 3, den vorangegangenen Kapiteln, den Daten-blättern des AT-Mega128 und des DS18S20 sowie dem Handbuch zum Programm Code-vision-AVR entnommen werden. Vorbereitende Fragen zur Klärung:

• Welcher Befehl aus der Bibliothek 1wire.h muss am Beginn jeder Kommunikations-Sequenz mit dem DS18S20 aufgerufen werden? ___________________

• Mit welcher C-Anweisungszeile wird eine 1-Wire-Funktion aufgerufen, die für einen nachfolgenden Befehl alle am Bus verfügbaren 1-Wire-Komponenten adressiert? ___________________

• Mit welchen beiden C-Anweisungszeilen wird ein bereits adressierter Temperatursensor vom Typ DS18S20 zum Starten einer neuen Temperaturmessung aufgefordert und der weitere Programmablauf bis zum Vorliegen des Messergebnisses unterbrochen? ___________________ ___________________


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 15/23

• Wie lautet die Deklaration eines Feldes ("Array") mit Namen scratchpad, das für die Aufnahme aller Werte des RAM-Speichers eines DS18S20 geeignet ist, in C-Notation? ______________________________________________________________________

• Mit welchen beiden C-Anweisungszeilen werden ein bereits adressierter Temperatur-sensor vom Typ DS18S20 zum übertragen seines RAM-Speicher-Inhalts aufgefordert und nachfolgend alle empfangenen Bytes in der richtigen Reihenfolge in das Feld scratchpad (s. oben) eingetragen? ___________________ ___________________

• Mit welcher C-Quellcodezeile wird einer Variablen temp vom Typ signed integer der aus den beiden, den aktuellen Temperaturmesswert enthaltenden, Bytes des Feldes scratchpad zusammengesetzte und auf ganze Grad-Celsius-Werte umgerechnete Temperaturwert vorzeichenrichtig zugewiesen (2'er-Komplement-Darstellung)? ______________________________________________________________________

• Wie ist nachfolgende C-Ausgabeanweisung zu ergänzen, damit der Inhalt der Variablen temp als Dezimalzahl mit Vorzeichen im "Terminal"-Fenster des PC dargestellt wird? printf("Temperaturwert (umgerechnet): %________ Grad Celsius\r\n\r\n",temp);

Praktische Programmieraufgabe: Entwickeln Sie ein C-Programm mit dem Namen SMR_Termin10, das – einen durch den Code-Wizard erzeugten Initialisierungsteil, wie in der vorherigen Teil-

aufgabe spezifiziert, besitzt, in dem zusätzlich der USART0 für das Senden von Daten mit einer Übertragungsrate von 9600 Baud, 8 Datenbits, einem Startbit, keinem Stopp-bit, keinem Paritätsbit und ohne Interruptgenerierung konfiguriert wird.

– ein Hauptprogramm besitzt, das aus einem Initialisierungsteil und einer Endlosschleife besteht, wobei die Endlosschleife für das periodische Abfragen von Informationen des DS18S20 und Senden der aufbereiteten Informationen über die serielle Schnittstelle an den PC genutzt wird.

– periodisch ca. alle 2 s eine neue Temperaturmessung des DS18S20 startet und den weiteren Programmablauf solange unterbricht, bis die Messung beendet ist und ein gül-tiger aktualisierter Temperaturwert im Sensor vorliegt.

– nach jeder erfolgten neuen Temperaturmessung den kompletten aktualisierten Inhalt des "Scratch-Pad" vom Temperatursensor abfragt und in ein Variablen-Feld ("Array") speichert.

– die beiden Bytes des Variablen-Feldes ("Array") aus denen der Temperaturmesswert besteht in korrekter Reihenfolge in hexadezimaler Notation und mit erklärendem Text in


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 16/23

jeder Messperiode einmal als Textzeichenfolge über die serielle Schnittstelle an den PC überträgt.

– die beiden Bytes des Variablen-Feldes ("Array") aus denen der Temperaturmesswert besteht zu einer vorzeichenrichtigen Integerzahl zusammenfasst, in einen Grad-genauen Temperaturwert umrechnet und diesen Temperaturwert mit Vorzeichen und mit erklärendem Text in jeder Messperiode einmal als Textzeichenfolge über die serielle Schnittstelle an den PC überträgt.

Überprüfen Sie die Funktion des von Ihnen entwickelten Programms auf dem Praktikums-Board. Verändern Sie dazu durch Berühren des Temperatursensor-Gehäuses die Tempe-raturmesswerte und überprüfen Sie die im "Terminal"-Fenster angezeigten Wertänderun-gen auf Plausibilität.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 17/23

6 Praktischer Teil zum Termin 11 6.1 Initial-Konfiguration des DS18S20 mit dem Code-Wizard Der Code-Wizard-Konfigurator unterstützt neben der Verwendung von allgemeinen 1-Wire-Funktionen auch komponentenspezifische Spezialfunktionen, z. B für den Tempera-tursensor DS18S20 durch das automatische einbinden der Funktions-Bibliothek ds1820.h. Das folgende Bild zeigt die für den folgenden Teilversuch notwendigen Einstellungen des Konfigurators.

Die Programmbibliothek enthält drei spezifische Funktionen für den DS18S20. Im folgen-den Teilversuch wird eine dieser Funktionen benötigt, deren Funktion und Anwendung nachfolgend kurz erläutert ist. "ds1820_temperature_10(<Zeiger auf Teilnehmer-Adresse (ROM-Code)>)"-Funktion Diese Funktion setzt voraus, dass zuvor die ROM-Code-Inhalte mindestens eines Busteil-nehmers vom Typ DS18S20 als Adresse ermittelt und in ein Variablen-Feld ("Array") ge-schrieben wurde. Sie ermittelt den aktuellen Temperaturwert des durch den Zeiger auf den Beginn einer Adresse spezifizierten Temperatursensors mit einer Temperaturauflösung von 10 Bit. Der Zurückgegebene Wert der Funktion vom Typ signed Integer entspricht vorzeichenrich-tig dem Temperaturwert in der Einheit °C/10 als 2'er-Komplement-Zahl. Im Fehlerfall wird der Zahlenwert -9999 zurückgegeben. Mit obiger Funktion wird die Adressierung spezifischer Temperatursensoren am Bus und das Abfragen und Umrechnen von Temperaturinformationen mit hoher Auflösung stark vereinfacht. Eine vollständige Beschreibung aller Funktionen der DS1820-Funktionsbiblio-thek findet sich in der Hilfefunktion des CodeVision-Compilers.

1-Wire-Grundeinstellungen: Wahl von Port und Anschluss-pin für die Busleitung DQ

Spezifische Einstellungen: Aktivierung der zusätzlichen Funk-tionen für den Einsatz mehrerer DS18S20 Temperatursensoren


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 18/23

6.2 Fehlerprüfung mit Hilfe von CRC-Werten Zur Detektion und gegebenenfalls auch zur Korrektur von Fehlern in übertragenen Daten-paketen werden den Nutzdaten auf der Sendeseite der Übertragung eine Folge von Prüf-bits hinzugefügt, mit deren Hilfe sich der Datenstrom auf der Empfangsseite nach vorge-gebenen Regeln untersuchen lässt. Häufig wird hierzu eine zyklische Redundanzprüfung CRC (Cyclic Redundancy Check) als Fehlerdetektionsverfahren angewendet. Im Vorle-sungs-Kapitel zum CAN-Bus wurde die Funktionsweise der sendeseitigen bitsequentiellen Berechnung von CRC-Prüfbits mit Hilfe des zugehörigen Generator-Polynoms und der empfangsseitigen bitsequentiellen Durchführung der Fehlerprüfung mit Hilfe des gleichen Polynoms vorgestellt und am Beispiel erläutert. Im Fall der 1-Wire-Komponenten von Maxim/Dallas wird eine spezifische Form des CRC als 8-Bit DOW-CRC auf die im 64-Bit ROM-Code enthaltene Komponentenadresse bzw. beim Temperatursensor DS18S20 auch auf den kompletten "Scratch-Pad"-Inhalt ange-wendet. Entsprechen ist bei beiden Datenpaketen jeweils ein CRC-Byte angefügt. Beim DOW-CRC lautet das Generator-Polynom G:

1458 +++= xxxG Mit der zugehörigen Prüfung lassen sich - Einzelbit-Fehler von beliebiger ungerader Anzahl, an beliebiger Stelle des Datenpakets, - Zwei-Bit-Fehler, an beliebigen Stellen des Datenpakets und - Fehlerketten mit einer Länge von bis zu 8 Bit an beliebiger Stelle des Datenpakets erkennen. Zur Beschleunigung und Vereinfachung der CRC-Durchführung kann vorteilhaft ein Tabel-len-gestütztes Verfahren eingesetzt werden, bei dem die Prüfung nicht auf Basis des Ge-nerator-Polynoms Bit für Bit, sondern Byte-weise durchgeführt wird. Dies ist insbesondere auch deshalb für die Praxis gut geeignet, da die Kommunikation über den Bus mit den Be-fehlen w1_read() und w1_write(..) ohnehin Byte-weise erfolgt bzw. da die zu überprüfen-den Datenpakete (ROM-Code und "Scratch-Pad") in Variablen-Feldern vom Typ unsigned char, also Byte-weise abgelegt sind. Die DOW-CRC-Tabellenwerte sollten als Konstanten-Feld im Flash-Speicher des Mikro-controllers abgelegt werden. Dabei ist für jede mögliche Bitkombination eines 8-Bit-Da-tenwortes ein Eintragsfeld erforderlich, im vorliegenden Fall also für 256 mögliche Bitkom-binationen. Der Wert des Datenworts, dessen CRC-Prüfwert zu ermitteln ist, stellt dabei gleichzeitig den Index für den Zugriff auf die zugehörige Zelle des Konstanten-Felds dar, in der sich der gesuchte Prüfwert befindet. Für das gesamte Datenpaket läuft die CRC-Prüfcode-Berechnung dann Byte für Byte, beginnend mit dem niederwertigsten Byte, durch wiederholte Anwendung der folgenden Schritte ab: <aktueller Tabellen-Index> = <vorheriger CRC-Wert> EXOR <aktuelles Byte> <neuer CRC-Wert> = Tabellenwert [<aktueller Tabellen-Index>] Die nachfolgende Tabelle enthält die entsprechenden DOW-CRC-Prüfcodes für alle 256 möglichen Bitkombinationen eines Bytes, das durch die Summation von "Index low" und "Index high" spezifiziert wird. Beispielsweise würde sich nach dieser Tabelle für den Byte-Wert 100 = 96 + 4, wie in der Tabelle markiert, der CRC-Prüfcode 4 ergeben.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 19/23

Index low

Ind. high

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 0 94 188 226 97 63 221 131 194 156 126 32 163 253 31 65 16 157 195 33 127 252 162 64 30 95 1 227 189 62 96 130 220 32 35 125 159 193 66 28 254 160 225 191 93 3 128 222 60 98 48 190 224 2 92 223 129 99 61 124 34 192 158 29 67 161 255 64 70 24 250 164 39 121 155 197 132 218 56 102 229 187 89 7 80 219 133 103 57 186 228 6 88 25 71 165 251 120 38 196 154 96 101 59 217 135 4 90 184 230 167 249 27 69 198 152 122 36 112 248 166 68 26 153 199 37 123 58 100 134 216 91 5 231 185 128 140 210 48 110 237 179 81 15 78 16 242 172 47 113 147 205 144 17 79 173 243 112 46 204 146 211 141 111 49 178 236 14 80 160 175 241 19 77 206 144 114 44 109 51 209 143 12 82 176 238 176 50 108 142 208 83 13 239 177 240 174 76 18 145 207 45 115 192 202 148 118 40 171 245 23 73 8 86 180 234 105 55 213 139 208 87 9 235 181 54 104 138 212 149 203 41 119 244 170 72 22 224 233 183 85 11 136 214 52 106 43 117 151 201 74 20 246 168 240 116 42 200 150 21 75 169 247 182 232 10 84 215 137 107 53

Eine Fehlerprüfung eines Datenpakets auf Basis von CRC-Werten ist im Ergebnis nur dann Fehlerfrei, wenn die zyklische Abfolge obiger Schritte, angewendet auf alle Bytes des Datenpakets, den Wert 0 ergibt. Zur Vereinfachung der programmtechnischen Umsetzung im folgenden Teilversuch sind obige Tabellenwerte unter dem Namen "dow_crc_table.dat" als Datei auf dem Desktop des Praktikums-PCs verfügbar. 6.3 Aufgabe: Erstellen eines Programms, mit dem die Temperaturmesswerte aller

am Bus angeschlossenen und mittels CRC-Prüfung fehlerfrei identifizierten Temperatursensoren vom Typ DS18S20 periodisch abgefragt und zusammen mit der jeweiligen Sensoradresse über die serielle Schnittstelle (RS-232) als "Klartext" an einen PC übertragen werden können

Die für die Beantwortung der nachfolgenden Fragen und die Ausführung des Programm-entwurfs zur folgenden Aufgabenstellung notwendigen Informationen können den Unterla-gen zu den Praktikumsversuchen 1, 2 und 3, den vorangegangenen Kapiteln, den Daten-blättern des AT-Mega128 und des DS18S20, dem Vorlesungsskript zur Veranstaltung "Struktur von Mikrorechnern" sowie dem Handbuch zum Programm Codevision-AVR ent-nommen werden.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 20/23

Vorbereitende Fragen zur Klärung:

• Welcher DOW-CRC-Prüfwert ergibt sich aus der Anwendung des CRC-Verfahrens auf die Wertfolge 0x23, 0xE0, 0x01, 0xFF (in der Reihenfolge der Nennung)? ___________________

• Welcher Wert müsste als 5. Wert obiger Wertfolge angehängt werden, damit die DOW-CRC-Prüfung, angewendet auf alle 5 Werte, den Datenblock als fehlerfrei erkennt? ___________________

• Welche bzw. welche beiden C-Anweisungszeile(n) muss/müssen unter Nutzung der DOW-CRC-Tabelle (Feldname dow_crc_table) 8-mal periodisch ausgeführt werden (Laufvariable n), damit für den i-ten Temperatursensor in der Liste der gefundenen Teil-nehmer (Feldname w1_devices_rom_codes) das jeweilige Ergebnis der CRC-Prüfung in die Variable crc_value geschrieben wird? ______________________________________________________________________ ______________________________________________________________________

• Mit welcher C-Anweisungszeile wird eine Temperaturmessung des i-ten, in der Liste der gefundenen Teilnehmer (Feldname w1_devices_rom_codes) aufgeführten, DS18S20-Temperatursensors gestartet, der Ergebniswert ermittelt und als Zahlenwert vom Typ signed integer in der Einheit °C/10 in die Variable temp geschrieben? ______________________________________________________________________

• Mit welcher C-Anweisungszeile wird obiger Temperatur-Ergebniswert in der Variablen temp als in °C skalierte Dezimalzahl mit Vorzeichen und einer Nachkommastelle als Textzeichenfolge über die serielle Schnittstelle an den PC gesendet? ______________________________________________________________________

Praktische Programmieraufgabe: Entwickeln Sie ein C-Programm mit dem Namen SMR_Termin11, das – einen durch den Code-Wizard erzeugten Initialisierungsteil besitzt, in dem die 1-Wire-

Funktionalität für den gewünschten Port-Pin aktiviert wird und zusätzlich die spezifi-schen 1-Wire-Funktionen des DS18S20 für mehrere Teilnehmer verfügbar gemacht werden, wobei ergänzend die USART0 Konfiguration wie im vorhergehenden Teilver-such gewählt werden soll.

– ein Hauptprogramm besitzt, das aus einem Initialisierungsteil und einer Endlosschleife besteht, wobei die Endlosschleife für das periodische Abfragen von Informationen aller am Bus angeschlossenen DS18S20 Temperatursensoren und das Senden der aufbe-reiteten Informationen über die serielle Schnittstelle an den PC genutzt wird.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 21/23

– einmalig im Initialisierungsteil des Hauptprogramms die ROM-Codes aller Busteilneh-mer ermittelt, mittels LUT-basierter CRC-Prüfung kontrolliert und nur fehlerfrei identifi-zierte Teilnehmer vom Typ DS18S20 für die folgende periodische Temperaturmessung selektiert.

– periodisch ca. alle 2 s eine neue Temperaturmessung aller selektierten DS18S20 durchführt und die ermittelten Temperaturwerte jeweils als auf 0,5 °C genauen Zahlen-wert mit Vorzeichen und erklärendem Text in jeder Messperiode einmal als Textzei-chenfolge über die serielle Schnittstelle an den PC überträgt.


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 22/23

Anhang A: Flussdiagramme zum Kommunikationsablauf: ROM-Kommandos


Datum:

Gruppe:

Versuch 4

SMR-P Viga/08

Blatt: 23/23

Anhang A: Flussdiagramme zum Kommunikationsablauf: Funktions-Befehle

Documents

Praktikum SMR Versuch 4 - uni-due.dehl271st/Lehre/SMR/smr_prakt_v4.pdf · 2009-01-26 · 3 Unterstützung der 1-Wire-Funktionalität durch den Codevision-Compiler Zur einfachen Nutzung