RN-Wissen.de - Benutzerbeiträge [de]

TWI

2007-06-22T14:02:13Z

Freak: /* Merkmale */

TWI ('''T'''wo-'''w'''ire Serial '''I'''nterface) ist eine Bezeichnung von [[Atmel|Atmel]] für die auf vielen [[AVR|AVR]] Megas vorhandene [[I2C|I<sup>2</sup>C]]-Hardware.

In diesem Artikel soll nur auf Besonderheiten der [[AVR]]-[[Microcontroller]] eingegangen werden, Einzelheiten zu [[I2C|I<sup>2</sup>C]] finden sich in den entsprechenden Artikeln.

__TOC__

= Merkmale =

* Master- und Slavemodus
* Multimaster
* 7-Bit Adressierung (als Master auch 10-Bit Adressierung möglich)
* Übertragungsrate von bis zu 400kBit/s

= TWI verwenden =
Um TWI mit dem [[AVR]] verwenden zu können sind einige Einstellungen nötig, die hier in Abhängigkeit der Anwendung aufgezeigt werden.

== TWI-Register ==
Hier eine kurze Beschreibung der für den TWI Betrieb notwendigen Register

==== TWBR ====
:Bit Rate Register, alle 8 bit
:dient zum einstellen des Bus-Taktes als Master, siehe [[#Bit_Rate_Generator|Bit Rate Generator]]

==== TWCR ====
:Control Register
<div align="center">{{Registertabelle8BitFix|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE}}</div>
:die Hauptschaltstelle befindet sich hier,
:*'''TWINT''' TWI Interrupt Flag
::Nach Abarbeitung der letzten Aktion wird dieses Flag gesetzt, und ein Interrupt ausgelöst falls ''TWIE'' gesetzt ist.
::Es sollte anschliessend das Datenregister und das Statusregister ausgelesen werden und darauf entsprechend reagiert werden.
::Um das Flag zurückzusetzen muss es gesetzt werden.
::Mit dem zurücksetzen (löschen) von ''TWINT'' wird die nächste Aktion ausgelöst, es müssen deshalb vorher alle notwendigen Flags und Register (zB. ''TWDR'') entsprechend gesetzt werden.
:*'''TWEA''' TWI Enable Acknowledge Bit
::Sendet ein ACK nach einer Übertragung wenn
:::*als Slave die eigene Slaveadresse (''TWAR'') erkannt wurde,
:::*ein General Call erkannt wurde und das ''TWGCE''-Flag in ''TWAR'' gesetzt ist,
:::*ein ganz normales Byte als Slave oder als Master empfangen wurde.
:*'''TWSTA''' TWI Start Sequenz senden
::Die TWI-Hardware überprüft ob der Bus frei ist, und gibt die Startsequenz aus.
::Ist der Bus nicht frei, wartet das TWI-Modul bis eine Stopsequenz erkannt wurde und sendet die Startsequenz erneut.
::Dieses Flag muss per Software wieder gelöscht werden.
:*'''TWSTO''' TWI Stop Sequenz senden
::Als Master wird durch setzen eine Stopsequenz ausgegeben. Ist die Stopsequenz gesendet wird das Flag automatisch gelöscht.
::Als Slave kann dieses Flag zum zurücksetzen nach einem Fehler verwendet werden. Es wird keine Stopsequenz ausgegeben, aber das Modul beeinflusst anschliessend nicht mehr die Leitungen SCL oder SDA, das TWI-Modul befindet sich in einem definierten unadressierten Zustand.
:*'''TWWC''' TWI Write Collision Flag
::In das Datenregister ''TWDR'' sollte man nur schreiben, wenn ''TWINT'' High ist, ist ''TWINT'' Low, wird dieses Flag gesetzt und zeigt einen Fehler an.
:*'''TWEN''' TWI Enable
::Aktivieren des TWI-Moduls. Das TWI-Modul übernimmt u.a. die Steuerung über die Leitungen SCL und SDA.
:*'''TWIE''' TWI Interrupt Anforderung erlauben
::Interruptanforderung aktivieren, wenn eine Aktion durchgeführt wurde und global Interrupts erlaubt sind, wird ein Interrupt ausgelöst.

==== TWSR ====
:Status Register
<div align="center">{{Registertabelle8BitFix|TWS7|TWS6|TWS5|TWS4|TWS3|–|TWPS1|TWPS0}}</div>
:*'''TWSx''' TWI Status
::die oberen 5 Bit geben den Status der letzten Aktion wieder
:*'''TWPSx''' TWI Prescaler
::die zwei niederwertigen Bit zum einstellen des Prescaler als Master, siehe [[#Bit_Rate_Generator|Bit Rate Generator]]

==== TWDR ====
:Data Register, alle 8 bit
:Beim Senden: nächstes Byte, das auf den Bus ausgegeben werden soll
:Beim Empfangen: letztes Byte, das über den Bus gekommen ist
:Die Daten sind gültig, solange das Bit ''TWINT'' in ''TWCR'' gesetzt ist

==== TWAR ====
:Slave Address Register
<div align="center">{{Registertabelle8BitFix|TWA6|TWA5|TWA4|TWA3|TWA2|TWA1|TWA0|TWGCE}}</div>
:*'''TWAx''' Slave Adresse
::Wird der [[AVR]] als Slave eingesetzt, wird in den oberen 7 Bit die Adresse eingetragen, auf die reagiert werden soll.
:*'''TWGCE''' General Call Enable
::Setzt man Bit0, kann zusätzlich auf einen ''General Call'' reagiert werden.
:als Master ist es unbenutzt

==== TWAMR ====
:Slave Address Mask Register
:Zusätzlich zu den schon geannten Registern, kann es bei einigen ATMegas, wie dem [[ATMega168]], dieses Register geben, in der Regel hat es aber den Standardwert von $00, wobei sich das TWI-Modul verhält wie bei den anderen ATMegas.
:Mit dem setzen von einzelnen Bits werden beim vergleich der Slaveadresse (die vom Master gesendet wurde) mit ''TWAR'' diese Bits ausmaskiert, dH. treffen immer zu, was bedeutet, dass der ATMega auf mehr als nur einer bestimmten Slaveadresse (''TWAR'') angesprochen werden kann.
:Werden zB. alle Bits gesetzt, fühlt sich der [[AVR]] immer angesprochen, egal welche Slaveadresse über den Bus gesendet wurde.
<div align="center">{{Registertabelle8BitFix|TWAM6|TWAM5|TWAM4|TWAM3|TWAM2|TWAM1|TWAM0|–}}</div>
:Wird der [[AVR]] als Slave eingesetzt, kann in den oberen 7 Bit die Adressmaske eingetragen werden,
:als Master ist es unbenutzt

== Übertragungsarten ==
Bei TWI gibt es diese Übertragungsarten
* Master Transmitter (nur Senden)
* Master Receiver (nur Empfangen)
* Slave Transmitter (auf Abruf Senden)
* Slave Receiver (nur Empfangen)
Abhängig von der Anwendung kann der [[AVR]] alle Arten der Übertragung im gleichen Programm ausführen.

== Master ==
Ist der AVR Master, bestimmt er was und wie schnell es auf dem [[I2C|I<sup>2</sup>C]]-Bus zugeht. (Ausnahme: [[Clock_Stretching]] )

Zur Bestimmung der Bus-Geschwindigkeit ist der ''Bit Rate Generator'' zuständig.

=== Bit Rate Generator ===
Zur Übertragung gibt es die Bitraten ''Standard'', mit bis zu 100kBit/s, und ''FastMode'', mit bis zu 400kBit/s.
Der Master muss immer den Takt erzeugen, der bei Bedarf auf der Leitung SCL angelegt wird.
Der SCL-Takt ist beim AVR abhängig von der CPU-Frequenz.
Da [[I2C]], im Gegensatz zu [[RS232]], ein synchrones Protokoll ist, das mit dem Taktsignal SCL arbeitet, muss man nicht exakt auf eine Frequenz von 100kHz bzw. 400kHz kommen.

Im TWI-Modul des AVR gibt es zwei Stellen, an denen man die Teilung der Frequenz einstellen kann:
* die ''Prescaler Bits'' (TWPS), diese 2 Bits befinden sich im ''TWI Status Register'' (TWSR)
* für die genauere Einstellung das ''TWI Bit Rate Register'' (TWBR)

'''Formel zur Berechnung der SCL-Frequenz:'''
<div align="center">
<math>\mathrm{SCL{-}Frequenz = \frac{CPU{-}Frequenz}{16 + 2 \cdot TWBR \cdot 4^{TWPS} } }</math>
</div>

Da ein AVR zur Zeit max. mit 20MHz getaktet werden kann, ist es nicht nötig, den Prescaler zu benutzen, bzw. er wird auf den Teiler 1 gestellt, was keiner Teilung entspricht. Mit diesem Teiler können alle CPU-Frequenzen und TWI-Takte abgedeckt werden.

<div align="center">
{| {{Blauetabelle}}
|+ '''Mögliche Prescaler-Werte'''
|- {{Hintergrund1}}
!| Bit-Wert || Teiler
|- align="center"
|00 ||1
|- align="center"
|01 ||4
|- align="center"
|10 ||16
|- align="center"
|11 ||64
|}
</div>
Die Werte von TWBR gehen von theoretisch 0 bis 255. Laut [[Atmel]] soll der Wert aber mind. 10 Betragen, da es sonst zu Problemen bei der Übertragung kommen kann.

'''Beispiel-Berechnung''':

Es soll eine SCL-Frequenz von 100kHz erzeugt werden, die CPU-Frequenz beträgt 8MHz, der Teiler (Prescaler) ist – wie oben erwähnt – auf 1 (TWPS = 0).

Laut der Formel ergibt das dann:
<pre>
100kHz = 8.0MHz / (16 + 2 * x * 4^0 ) / 1 fällt weg
100kHz = 8.0MHz / (16 + 2 * x ) / *(16 + 2 * x )
100kHz * (16 + 2 * x ) = 8000kHz / kürzen / : 100
16 + 2 * x = 80 / -16
2 * x = 64 / :2
x = 32
</pre>
;Ergebnis: Der Wert für TWBR muss 32 sein, damit die SCL-Frequenz 100kHz ergibt, bei 8MHz CPU-Frequenz.

'''Es Ergibt sich somit folgende Formel zum Berechnen von TWBR:'''
<div align="center">
<math>\mathrm{TWBR = \frac{ \frac {CPU{-}Frequenz}{SCL{-}Frequenz} - 16}{2}}</math>
</div>

Kommt ein Wert kleiner 10 heraus, kann ein höherer CPU-Takt gewählt werden, oder falls das nicht möglich ist, wird der Bus mit einem geringeren Takt betrieben, was trotzdem innerhalb der Spezifikation liegt. Wird eine krumme CPU-Frequenz verwendet, die kein ganzzahliges Ergebnis zur Folge hat, kann man mit der ersten Formel überprüfen, ob der Wert auf- oder abgerundet wird. Auf der sicheren Seite ist man, wenn der Wert aufgerundet wird. Das entspricht einer grösseren Teilung, also eine geringfügig kleinere Bitrate und liegt deshalb im Standard.

== Slave ==
Um den AVR als Slave zu konfigurieren sind nur diese wenigen Schritte notwendig:
*gewünschte Slaveadresse im ''Address Register'' (TWAR) setzen
*im ''Control Register'' (TWCR)
**mit TWEN das TWI Modul aktivieren
**mit TWEA das Senden des Bestätigungsbits (ACK) zulassen

anschliessend als Slave
*warten, bis im ''Control Register'' (TWCR) das Bit TWINT gesetzt ist, welches anzeigt, daß auf dem Bus was los ist
*das ''Status Register'' (TWSR) abfragen und entsprechend darauf reagieren

=== Anmerkung zur CPU-Frequenz ===

Da der Master den Takt vorgibt, muss der Slave nur mit dessen Takt am Bus mitlauschen. Um zu gewährleisten, daß der Slave dem Takt folgen kann sollte laut [[Atmel]] die CPU-Frequenz eines ATMega-Slave mind. das 16-fache der Bus-Frequenz betragen.

das ergibt folgende Werte :
<div align="center">
{| {{Blauetabelle}}
|- {{Hintergrund1}}
!| Bus-Frequenz || minimale CPU-Frequenz
|-
|100 kHz || 1,6 MHz
|-
|400 kHz || 6,4 MHz
|}
</div>

= Quellen =
[http://www.atmel.com/dyn/products/devices.asp?family_id=607 Atmel-AVR-Datenblätter]

= Siehe auch =
* [[I2C|I<sup>2</sup>C]] - Details zu I2C
* [[RS232]] - serielle Schnittstelle
* [[RS485]] - serieller (asynchroner) Bus
* [[TWI Praxis]] - Programmbeispiele
* [[TWI_Slave_mit_avr-gcc|TWI-Slave mit avr-gcc]]
* [[USI (Avr)]] - USI Modul mit dem TWI nachgebildet werden kann, ist bei den meisten ATTinys und einigen ATMegas vorhanden.
* [[RN-Slave ID Übersicht]]

--[[Benutzer:Linux 80|Linux 80]] 00:52, 6. Jan 2006 (CET)

[[Kategorie:Abkürzung]]
[[Kategorie:Grundlagen]]
[[Kategorie:Kommunikation]]
[[Kategorie:Microcontroller]]
[[Kategorie:Elektronik]]
[[Kategorie:Praxis]]

AVR Assembler Einführung

2007-03-24T17:36:01Z

Freak: /* Beispiel */

==AVR Assembler Einführung==
Es gibt mehrere Gründe, sich mit dem AVR-Assembler zu beschäftigen:
* reines Interesse
* Man hat eben keinen anderen Compiler, Bascom kostet ja was und GCC-C kann man möglicherweise genausowenig, also warum nicht gleich.
* Endlich Programmieren ohne Sprach-Restriktionen
* (theoretisch) sagenhaft schneller und kurzer Code

Dadurch ergeben sich aber auch verschiedene Haupt-Zielgruppen für eine Einführung. Die eine ist in einer oder mehreren anderen Sprachen durchaus versiert, und möchte endlich auch mal richtig in die Tiefen der Hardware steigen. Die andere ist totaler Neueinsteiger und hat gehört, daß man Micro-Controller am besten mit Assembler programmiert.

Es soll hier nur eine Starthilfe zum Einstieg gegeben werden. Viele Details und Varianten werden hier bei weitem nicht erschöpfend behandelt.

==Unterschiede zu anderen Sprachen==
Man kann Assembler nicht direkt mit anderen Hochsprachen vergleichen. Es ist falsch gesagt Assembler ist viel besser als C, oder C ist viel besser als Assembler.
Hochsprachen haben generell ihren Vorteil in kürzerer (Programmier-) Zeit viel mehr erreichen zu können. Während man in Assembler jedes Detail programmieren muss schreibt man in der Hochsprache was man genau möchte und der Compiler erledigt das dann für einen, indem er den Code dann in Assembler übersetzt.
Der Vorteil liegt also klar auf der Hand, man spart sich eine Menge (unnötiger) Arbeit in dem man schneller sagen kann was man eigentlich machen möchte. Wie das jetzt genau funktioniert und was man dabei beachten muss übernimmt der Compiler.
Da gibts dann aber auch schon den ersten Nachteil. Fängt man mit einer Hochsprache an, braucht man sich hardwaremäßig kaum mit dem µC auseinander zu setzen und weiß deshalb auch nicht genau drüber Bescheid. Funktioniert dann etwas nicht sitzt man auf dem Schlauch.
Die Compiler werden aber immer besser, so kommen immer seltener Fehler zustande.

Ein weiterer Nachteil ist eine Glaubens Frage, da man sich kaum mehr mit der Hardware auseinander setzt und nicht wissen muss wie ein µC eigentlich funktioniert geht die "Kultur" verloren. Man lernt gar nicht zu schätzen was das Ding jetzt eigentlich leistet. Die Ansprüche werden immer höher gesetzt und jeder Aussetzer ist umso schlimmer.

Ein extremes Beispiel:
Ein eiserner Geschäftsmann geht nach Spanien und braucht Arbeiter, er schickt einen Gehilfen auf die Suche nach Arbeiter und schickt diese dann aufs Feld arbeiten. Ohne auch nur irgend etwas über deren Kultur zu wissen verlangt er das hart gearbeitet wird.
Doch schon in der ersten Woche gibt es Probleme, die Arbeiter möchten Mittags eine Pause. "Was, eine 3 Stündige Siesta? Seit ihr verrückt? Die in Japan arbeiten die Mittagszeit ja auch durch! Wie kommt ihr auf die Idee 3 Stunden Pause zu machen?"

Vorteile von Assembler sind also dass man weiß, was der µC genau macht (bzw. für Anfänger "was er tun sollte").
Man hat die volle Kontrolle und fast jeder Befehl wird bei einem AVR mit einem Takt ausgeführt.
Man kann immer noch auf eine andere Hochsprache umsteigen, diese beherrscht man dann um so besser.

Einziger Nachteil, man muss alles genau definieren, so wie es der µC haben möchte und kann nicht direkt auf fertige Funktionen zurück greifen.
Man schafft in der selben Zeit zwar genau so viel Code, der Code macht dann aber weniger als in C.

Bildhaft ist der Unterschied der: Beim Assembler hat man ein weißes Stück Papier (ohne Linien) und ein Alphabet von A-Z. Aus diesen Buchstaben soll man nun erstmal Worte suchen und dann damit einen sinnvollen Text verfassen.

Bei "höheren" Sprachen ist das Papier zumindest mal liniert, und dazu kriegt man auch ein Wörterbuch und die Grammatik. Teile des Textes sind schon vorgeschrieben und ich muß nurmehr bei den ..... Punkten was einsetzen.

Anders kann man auch sagen, Hochsprachen sind wie ein Baukasten, man muss nur nach seinen Bedürfnissen sich die Teile zusammen "stecken", ab und zu fertigt man sich auch eigene Teile. Aber das meiste ist vorgefertigt und nach eigenen Bedürfnissen schnell angepasst.
In Assembler muss man sich alles selber anfertigen, fertige Module gibt es nicht, es sei denn man hat es schon einmal gemacht und zufällig da.

* Daten
Höhere Sprachen kennen alle möglichen Datentypen in allen möglichen Längen, integer, floating point, Strings. Dadurch sind aber auch gleich die möglichen und zulässigen Operationen schon eingeschränkt.

Beim (AVR) Assembler gibt auch einige Datentypen. Sie unterscheiden sich aber nur durch die Größe, d.h. die Anzahl der Bytes, die sie belegen. Es gibt aber keine Einschränkungen bezüglich der Befehle, die man darauf anwenden kann.

* Vor- und Nachteile
Wenn man den Assembler mit höheren Sprachen vergleicht, um vielleicht Vor- und Nachteile herausarbeiten zu können, kommt man schnell drauf, daß in jedem Vorteil für eine der Seiten auch schon der Nachteil drinnen steckt. Was ich beim Assembler an Performance heraushole, weil ich z.B. "Goodies" eines Controllers ausnutze, bezahle ich, wenn ich mir einen anderen kaufe und dann das ganze Programm umbauen muß.

==Installation AVR-Studio==
Die Installation des ATMEL AVR Studios ist herzergreifend einfach.
* Man bekommt von Atmel das AStudio4b01.exe (oder was halt gerade aktuell ist) , das man einfach startet und schon ist es passiert.
* Wenn man nun das Käferchen doppelklickt und startet,
**erzeugt man am besten gleich mal ein neues Project.
**Man wählt den Pfad des Projects, und
**Wenn man seinen Brennadapter im Menü nicht findet, wählt man eben den Simulator und verwendet dann halt das PonyProg, oder was man halt hat.
**avrstudio erzeugt ein leeres Projekt und eine leere Assemblersource, die so heißt wie das Projekt. Das Gewurstel mit der Make-file nimmt uns AvrStudio ab.
==Struktur eines AVR-Maschinenprogrammes==
Bei höheren Sprachen wird diese Struktur vom Compiler/Linker erzeugt, beim Assembler muß man sich selbst darum kümmern.

[[Bild:Asm_Flow.jpg]]

Der Controller beginnt mit der Abarbeitung links oben bei der Programmspeicheradresse 0000. Wenn man Interrupts verwenden will, muß man gleich das nächste Bereich (ISR-Vectoren) überspringen (mit "JMP"). Wenn nicht, kann man sich diese Vektoren aber auch wegdenken.

Man landet so oder so bei den Befehlen, die der Initialisierung dienen (Setzen der Startbedingung). Das ist zumindest die Festlegung des Stack-Pointers, sonst kann man keine "CALLS" oder Interrupts durchführen.

Danach kommt man von oben in die Haupt-Programm-Schleife, die (üblicherweise) immer wieder ohne Ende durchlaufen wird.

Das "End" ist bei Microcontrollern daher auch kaum wirklich notwendig. Wenn es da ist, ist das eine ewige Wiederholung eines einzigen Befehls.

==Source-Code Muster==
Das folgende Codebeispiel ist eine reine Basis-Initialisierung ohne irgendeine erkennbare Funktion. Für den Einstieg ist es am besten, das einfach abzuschreiben, wie es ist, und dann an den bezeichnenten Stellen mit eigenen Befehlen nach und nach zu erweitern.

<pre>
.NOLIST ; List-Output unterdrücken
.INCLUDE <m8def.inc> ; das gibt es für jeden Controllertyp
.LIST ; List-Output wieder aufdrehen
.CSEG ; was nun folgt, gehört in den FLASH-Speicher

;------------------------------------------------------
; Start Adresse 0000
;------------------------------------------------------
RESET:
jmp INIT ; springen nach "INIT"

;------------------------------------------------------
; ISR VECTORS
;------------------------------------------------------
; ..... hier kommen dann die Sprungadressen für die Interrupts rein
; dazu kommen wir noch

.ORG INT_VECTORS_SIZE ; dadurch haben wir für die Vektoren Platz gelassen
INIT:
;------------------------------------------------------
; INITIALIZE
;------------------------------------------------------
ldi r24,high(RAMEND) ;Stack Pointer setzen
out SPH,r24 ; "RAMEND" ist in m8def.inc (s.o.) festgelegt
ldi r24,low(RAMEND) ;
out SPL,r24 ;

;------------------------------------------------------
; eigene Initialisierungen
;------------------------------------------------------
;....
;....
;....

;------------------------------------------------------
; HAUPTSCHLEIFE
;------------------------------------------------------
Hauptschleife:
;.... eigene befehle
;.... eigene befehle
;.... eigene befehle
rjmp Hauptschleife ; immer wiederholen

;------------------------------------------------------
; ENDE
;------------------------------------------------------
Ende:
rjmp Ende
</pre>
===Der Ablauf der Übersetzung===
Der Assembler ist ja selbst auch nur ein Programm und zu Beginn recht spartanisch ausgestattet: Er hat einen Daten-Buffer zur Verfügung, in den er den Maschinencode hineinschreiben soll, einen Pointer (Zeiger) dazu, damit er immer weiß, wo er grad ist, und eine allgemeine Tabelle, wo er Texte mit Zahlen verknüpfen kann. Alles ist zu Beginn leer bzw. auf NULL.
Mit diesen Voraussetzungen fängt er an, unseren Source-Text zeilenweise zu lesen. Und in jeder Zeile (die nicht leer ist) erwartet er eine Anweisung, was zu tun ist
====Assembler Direktiven/Präprozessor====
Das sind Anweisungen an den Assembler selbst und erzeugen keine Maschinenbefehle. Im obigen Source-Beispiel sind einige enthalten.
.NOLIST
Normalerweise schreibt der Assembler ja eine Übersetzungsliste. Nach dieser Anweisung läßt er das bleiben
.INCLUDE <m8def.inc> ; das gibt es für jeden Controllertyp
sagt ihm, er soll jetzt erstmal die (text) datei "m8def.inc" lesen und genauso behandeln, als wäre diese Datei mit dem Editor hier reinkopiert worden.
.LIST
Ab nun wird wieder alles in der Übersetzungsliste protokolliert.
.CSEG
was danach folgt, bezieht sich auf den FLASH-Programm-Speicher

Gleich ein Hinweis: Der "AVR Assembler 2" geht dazu über, die C-Syntax für
Präprozessoranweisungen zu verwenden. Diese haben dann als Kennzeichen ein "#" vorangestellt.

====Bemerkungen / Kommentare====
;------------------------------------------------------
Alles, was NACH einem Strichpunkt steht, schreibt er einfach nur in die Übersetzungsliste, sonst macht er nix.
====Label (Sprungmarke)====
RESET:
Was gleich ganz links in der Zeile beginnt (und mit einem Doppelpunkt abgeschlossen ist) schreibt er einfach in die genannte Tabelle und den momentanen Wert des Instruction Pointers (IP) dazu. Sonst hat das im Moment keine weitere Bedeutung. Natürlich, wenn er den gleichen Text schon mal hatte, gibt es eine Fehlermeldung, denn '''ein Label muss eindeutig sein'''

====Commands====
jmp INIT ; springen nach "INIT"
Alles, was nicht ganz links steht und auch nix anderes ist, betrachtet der Assembler als "Command". Normalerweise ist das eben eine AVR-Instruktion aus dem "Instruction Set". Hier ist das "JMP", also im Programm einfach woanders weitermachen. Gut, aber wo ? Der Rechner braucht nun unbedingt eine Zahl, denn "INIT" sagt ihm ja nichts. Also sieht er nun in der Tabelle nach, ob er den Text "INIT" schon mal hatte. Hatte er nicht, den zu der Stelle weiter hinten, wo "INIT:" als Sprungmarke steht (s.o) ist er ja noch garnicht gekommen.

Ich kann leider nicht genau sagen, welche Strategie der AVR-Assembler nun anwendet, dazu gibt es keine Doku. Manche Assembler lesen erstmal überhaupt nur den Sourcetext von vorn bis hinten durch, um alle "Sprungmarken" zu sammeln (Pass I) und fangen dann nochmal von vorne an (Pass II), diesmal mit schon gefüllter Tabelle. Andere machen das etwas gefinkelter. Ist uns aber eigentlich egal.

Jedenfalls findet er letztlich den Text "INIT" und daneben steht die Nummer der Speicherstelle, wo wir eben "INIT:" hingeschrieben haben. Und nun schreibt der Assembler also den Maschinencode für "JMP" in den Buffer und dazu die Zahl aus der Tabelle. Das war mal ein Befehl, also addiert er auf seinen Zeiger eins drauf und ist mit diesem Befehl fertig.

====ORG / JMP====
Das, was für den Controller beim Ablauf dann ein "JMP" ist, ist das ".ORG" für den Compiler. Wenn also bislang der Assembler den FLASH-Speicher von 0 - nn mit Befehlen befüllt hat, macht er durch
.ORG INT_VECTORS_SIZE
mit der Stelle weiter, die er über die gleiche Tabelle unter "INT_VECTORS_SIZE" gefunden hat. Dieser Tabelleneintrag, genauso wie "RAMEND" an anderer Stelle, entsteht aus der Datei "m8def.inc". Wie im vorliegenen Fall macht man diese "Assembler-Jumps", um Speicherstellen freizuhalten.

==Merkwürdiges==
===Befehlsadressen / Byteadressen ===
[[Atmel Controller Mega16 und Mega32#Maschinen-Code|Ein Maschinenbefehl besteht aus maximal drei, bit-mäßig verschachtelten Teilen]]. Die meisten Befehle brauchen dafür genau 16 Bit (also zwei Byte), manchmal reicht das nicht, da gehören dann nochmal 16 Bit dazu. Kleiner als 16 Bit ist aber keiner. Aus diesem Grund wäre es natürlich sinnlos, Adressen für Befehle in Bytes auszudrücken, wenn es eh immer Vielfache von 2 sein müssen, das kleinste Bit einer solchen Adresse wäre ja immer null.

Also adressiert man Commands in "Worten" von 16 - Bit bzw. 2 Bytes

Beim Ablegen eines Labels (Sprungmarke) werden also Wortadressen in der Tabelle angelegt. Solange der Wert auch als Befehls-Adresse verwendet wird (z.B. "JMP ''Label''"), braucht das nicht zu kümmern, denn genauso will es der AVR ja dann auch haben. '''Wenn dort aber Daten stehen''' und wir wollen diese adressieren, müssen wird '''den Wert mal 2 nehmen''' (oder einmal nach links schieben, was dasselbe ist), sonst landen wir im Nirwana.
===3 ist nicht gleich 3 ===
Eine Zahl bedeutet also bei der Maschinensprache unter Umständen ganz was anderes, je nachdem, in welchem Zusammenhang sie verwendet wird. Bei allen Befehlen, die nur für die Register 16 - 31 gehen, steht im Maschinencode für das Register 16 nicht 16 drin, sondern 0. die "16" addiert er dann bei der Befehlsausführung drauf (für den Techniker: er braucht ja nur das Bit 2<sup>4</sup> hochzuziehen)
===GPR ist nicht gleich GPR===
Was auch beim Einstieg leicht irritieren kann ist der Umstand, daß die 32 sogenannten "'''G'''eneral '''P'''urpose '''R'''egister" irgendwie so gar nicht generell und gleich sind. Manche Befehle kann ich mit allen 32 Registern machen, einige nur mit R16-R31, andere von R24 aufwärts und dann sind da noch R26 bis R31, die heissen dann manchmal auch noch X, Y und Z
===SFR ist gar nicht gleich GPR===
'''S'''pecial '''F'''unction '''R'''egister sind überhaupt seltsam, die meisten GPR-Befehle gehen da gleich garnicht, dafür gibt es andererseits ein paar Bit-Manipulationen, die gehen wiederum nur mit diesen. Dann gibt es auch Bit-Abfragen, die gehen da wie dort und bewirken auch das Gleiche, aber dafür heissen sie dann anders.
===Assembler-Befehle===
Viele dieser Probleme nimmt uns der Assembler ab, viele aber nicht. Dort erscheinen die Instruktionen immer so
{| {{Blauetabelle}}
| ''' '''
| '''CMD'''
| '''ARG<sub>1</sub>'''
| '''ARG<sub>2</sub>'''
|}
wobei die Argumente 1 u. 2 optionell, d.h. bei Bedarf erscheinen. Command ist natürlich immer da.
Trotz der Hilfe des Assemblers durch "Warnings" und "Errors" ist bei den Argumenten aber immer Vorsicht geboten. Wir haben gehört, daß Arg 1 und Arg 2 im Grunde einfach nur zwei Zahlen sind, die dann zusammen mit dem Command-Code zum Maschinenbefehl werden. Wenn es dem Assembler also auch nur irgendwie gelingt, aus dem, was wir da hinschreiben, Zahlen zu machen die er umwandeln kann, nimmt er sie auch.

===Zwischenbilanz===
Einige dieser sonderbaren Dinge lassen sich leicht erklären, manche schwer, manche mangels Unterlagen darüber gar nicht. Deswegen versuch ich es hier auch gleich gar nicht.

So oder so sind es Fakten, an die man sich am besten einfach gewöhnt. Das scheint und ist am Anfang sicher schwer, solange man noch mit den einzelnen Befehlen kämpft. RISC-Befehle werden aber erst in bestimmten Gruppierungen überhaupt wirklich sinnvoll, und durch diese sich immer wieder wiederholenden Gruppen wird es sehr schnell leichter.

Beim Briefe schreiben denkt man ja auch nicht in Buchstaben, das wäre mühsam, sondern in Worten oder in ganzen Sätzen.

==Load & Store==
Die meisten Befehle für den AVR laufen nach dem Load & Store (Laden und Speichern) Prinzip ab. Das heißt, die Daten werden zuerst aus dem SRAM-Speicher (oder den I/O bzw. SFR Registern) in die allgemeinen Register (GPR) geladen, dort verarbeitet, und danach wieder in den SRAM oder die SFR zurückgestellt.

[[Bild:Asm_cmd.jpg]]

Das ist natürlich eine recht allgemeine Darstellung, aber es hilft, das Instruction Set des AVR schon ein wenig besser zu verstehen.

Es bedeutet, um z.B. ein Byte aus der einen Ecke des SRAM in eine andere zu kopieren, brauchen wir wenigstens 2 Maschineninstruktionen, einmal Load und einmal Store. Und wenn wir was an dem Byte ändern wollen, kommt diese Befehle natürlich dazu.

Es gibt zu (fast) jeder Art "Load"-Befehl ein Äquivalent als "Store", und zum Finden genügt es meist, statt "L" an der selben Stelle ein "S" zu nehmen.
<pre>
LDS GPR, adresse ; lade das Byte von der Adresse in ein GPR
STS adresse, GPR ; speichere den Inhalt von GPR in der Adresse
</pre>
Wenn es um die I/O Register (SFR) geht:
<pre>
IN GPR, I/O-Register ; GPR <-----I/O Register
OUT I/O-Register, GPR ; I/O Register <---- GPR
</pre>
Für feste Werte (Literals) gibt es natürlich keine Store-Variante, denn diese Werte stehen ja im FLASH (Programm) Speicher, und da kann man nicht einfach einzelne Bytes verändern.
<pre>
LDI GPR, wert
</pre>

===Beispiel===

An PORTC haben wir (mit Vorwiderständen) ein paar LEDs angeschlossen. Und die sollen einfach nur zeigen, welche 0-er und 1-er am PORTB anliegen.
<pre>
; Eigene Initialisierungen
LDI R24, 0 ; der wert "0" ins allgemeine Register R24
OUT DDRB, R24 ; das kommt ins Controll-register f. PortB
; dadurch sind diese PINs als INPUT festgelegt
LDI R24, 255 ; der wert "255" = FF ins allgemeine Register R24
OUT DDRC, R24 ; das kommt ins Controll-register f. PortC
; dadurch ist das Port auf OUTPUT gestellt
</pre>

<pre>
; Eigene Befehle (in der Hauptschleife)
IN R24, PINB ; die Bits vom PortB ins allgemeine Register R24
OUT PORTC, r24 ; schreiben wir nach PortC
; wo ein 1-er ist, leuchtet nun die LED
</pre>

Wenn wir diese Befehle in das Programm-Schema oben einfügen, haben wir also das erste Assemblerprogramm schon geschrieben.
====Programm-Map====
Eine interessanter Output, wenn wir dieses Programm mit F7 übersetzen lassen, ist die Map-File. Sie ist ein Abbild der oben genannten "Text <--> Adresse"-Tabelle

(gekürzt)
<pre>
AVRASM ver. 2.0.28 D:\avr_c\avrstudio\Dokutest\Dokutest.asm Sat Dec 10 11:23:45 2005
....
EQU sram_start 00000060
EQU sram_size 00000800
EQU ramend 0000085f
......
EQU sph 0000003e
EQU spl 0000003d
EQU portb 00000018
EQU ddrb 00000017
EQU pinb 00000016
EQU portc 00000015
EQU ddrc 00000014
EQU pinc 00000013
EQU int_vectors_size 0000002a
CSEG reset 00000000
CSEG init 0000002a
CSEG hauptschleife 00000032
CSEG ende 00000035
</pre>
Wir finden darin alle Sprungadressen und alle sonstigen Werte, die wir verwendet haben. Tatsächlich in den Maschinencode eingesetzt werden vom Assembler immer die Zahlen, die daneben stehen

===Pointer-Register===
In vielen Fällen ist es nicht sinnvoll, für Load & Store explizit jedesmal die Speicheradresse dazuschreiben zu müssen. Es können auch die Pointer Register X, Y und Z verwendet werden. Das sind die Register
R26:R27 = X
R28:R29 = Y
R30:R31 = Z
Da wir ja oft mehr Speicher haben als 256 Byte, werden immer zwei Register zusammengefaßt und können dadurch die Bereiche 0 - 65535 abdecken (64k). Gut, aber wie kriegen wir so große Zahlen da rein ? Wir haben ja nur einen 8-Bit Processor und nicht 16.

Wir müssen also die Adresse 8-Bit-weise übergeben, aber der Assembler hilft uns ja dabei.
<pre>
LDI R26, LOW(Adresse) ; R28 für "Y" u. R30 für "Z"
LDI R27, HIGH(Adresse) ; R29 für "Y" u. R31 für "Z"
</pre>
Mit diesem "LOW" und "HIGH" teilt uns der Assembler die Adresse genau in die richtigen 8-Bit Portionen, die wir also so in den "X" Pointer laden können.

Noch eine Hilfe gibt es: Wir können, besser zu merken, auch schreiben:
<pre>
LDI XL, LOW(Adresse) ; YL für "Y" u. ZL für "Z"
LDI XH, HIGH(Adresse) ; YH für "Y" u. ZH für "Z"
</pre>
Also "LOW" für "L" und "HIGH" für "H"

====Indirekte Adressierung====
Mit den Pointer-Register kann man also Indirekte Adressieren(=einmal um die Ecke). Statt:
<pre>
LDS GPR, adresse ; lade das Byte von der Adresse in ein GPR
</pre>
Schreiben wir
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
LD GPR, X ; '''Indirekt''': lade das Byte, wo der Pointer X hinzeigt
</pre>
beziehungsweise
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
ST X, GPR ; '''Indirekt''': speichern, wo der Pointer X hinzeigt
</pre>
Warum sollte man sowas kompliziertes tun ? Nun, zum Beispiel dann,
* wenn man an einer Stelle im Programm die Adresse festlegt, aber ganz woanders braucht (Subroutinen)
* wenn man für mehrere Folge-Befehle die gleiche Adresse wieder braucht
* wenn man mit der Adresse (als Zahl) rechnen will

====Post-Increment/Pre-Decrement====
Wenn ich zum Beispiel 4 Byte hintereinander im Speicher auf "0" löschen will
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
LDI GPR, 0
ST X+, GPR ;speichern, wo X hinzeigt, und dann 1 auf X addieren
ST X+, GPR ;das 2.Byte dahinter
ST X+, GPR ;das 3.Byte dahinter
ST X+, GPR ;das 4.Byte dahinter
</pre>
Durch das automatische Addieren brauche ich nichts weiter zu tun. Als Gegenstück dazu kann man auch jedesmal 1 abziehen lassen, das aber immer '''vorher'''
<pre>
ST -X, GPR ;1 von X abziehen und dann speichern, wo X hinzeigt
</pre>

All das gibt's für X, Y und Z. Es geht aber immer nur
* Load & Store und '''dann''' addieren
* '''erst''' subtrahieren und '''dann''' Load & Store
Diese Kombinationen werden einfach am häufigsten gebraucht

====Displacement====
Für die beiden Pointer Y und Z kann man auch mit Displacement arbeiten
<pre>
LDD GPR, Y+4 ; wo Y hinzeigt, aber 4 Byte dahinter
</pre>

==Welches Register ?==
Bei den Load & Store Befehlen könnten als GPR alle 32 Allgemeinen Register beliebig verwendet werden, um das entsprechende Byte aufzunehmen oder abzugeben. Aber als Zwischenspeicher oder Arbeitsregister ist es am besten, Registern wie r26->r31, die möglicherweise als Pointer gebraucht werden, eher auszuweichen.

Wird das Assemblerprogramm durch inline oder libraries in eine Hochsprache
eingebunden, muß man bei sich natürlich an die Register-Konventionen dieser
Umgebung halten.

Schreibt man ein "stand-alone" Programm, kann (und sollte) man sich seinen eigenen
Konventionen und Regeln schaffen. Das ist das, was der Assembler-Fan so liebt.

==Benutzerdaten==
Daten wie Variable oder Felder werden üblicherweise im SRAM abgelegt und (s.o) von dort auch geholt. Bei allen Compilern und natürlich auch beim Assembler können zum Programmierzeitpunkt nur die Adressen davon festgelegt werden, aber keine Inhalte. Erst zur Laufzeit des Programmes kommen hier Werte rein. Manche Compiler gaukeln es zwar vor, aber (ein C-Beispiel):
<pre>
char MeinName[] = "Sepp Meier"
</pre>
bewirkt in Wirklichkeit drei Dinge: Im SRAM wird die nächste, noch nicht benutzte Adresse dem Text "MeinName" in der oben genannten Tabelle abgelegt, der String "Sepp Meier" wird im FLASH Programmspeicher bereitgestellt, und es wird eine Transfer-Routine generiert, die beim tatsächlichen Start des fertigen Programmes diesen String in das Feld "MeinName" transferiert.

Im Assembler ist es eben genauso: Wir können durch die Anfangsadressen und einen Namen dazu Felder festlegen, die dann zur Laufzeit benützt werden. Mehr eigentlich nicht. Und erst, wenn wir Befehle schreiben, die diese Daten verwenden, ergibt sich daraus ein Datentyp. Vorher sind das einfach nur Bytes.

Das ist bei Hochsprachen anders: Schon in der Source legen wir durch verschiedene Angaben den Datentyp (char, integer, etc.) fest und daraus entscheidet dann der Compiler, welche Maschinen-Instruktionen er dafür verwenden wird. Wir können das nurmehr eingeschränkt beeinflussen.

===Daten im SRAM===
<pre>
.DSEG ; Das ist eine Datensegment, d.h. es werden SRAM-Adressen festgelegt
CharBuf: .byte 24
OtherData: .byte 4
....
</pre>
'''Anmerkung:''' Standardgemäß beginnt der Assembler mit der kleinsten SRAM Adresse. Bei den meisten AVRs ist das die tatsächliche Byte-Adresse 0x0060 (d.i. 96 dezimal).
[[Atmel_Controller_Mega16_und_Mega32#Adressen_Mapping|Siehe Adress-Mapping]]

Dadurch, daß wir geschrieben haben ".byte 24" bestimmen wir, daß als nächste Datenadresse automatisch dann 96 + 24 = 120 gilt. Also ist mit "OtherData" dann 0x0078 (dez. 120) verknüpft.

'''Noch eins:''' Wir haben ja gesagt, für den Assembler ist alles letztlich eine Zahl. Wir können daher auch damit rechnen. Wenn wir also die "24" nicht selbst wo hinschreiben wollen, verwenden wir einfach den Ausdruck
LDI R10 , Otherdata - CharBuf
und laden damit das Register 10 mit der Zahl 24

===Daten im FLASH (Literale)===
Literale sind Werte, die schon in der Source festgelegt werden können. Das geht im Prinzip ähnlich, nur müssen wir nun auch Datentypen festlegen
<pre>
OneByte: .db 1 ; ein byte mit dem inhalt 0x01
MeinName: .db "Sepp Meier" ; mehrere Bytes mit Text
OneWord: .dw 1,2 ; zwei WORDs (16 Bit) mit dem inhalt 0x0001 u. 0x0002
....
</pre>

Diese Definitionen können wir auch direkt in den Programmcode reinmischen. Wir müssen aber natürlich schauen, daß der AVR zum Laufzeitpunkt nicht versucht, diese Zeichen als Befehl auszuführen.

===Daten im EEPROM (ERAM)===
genauso geht es, wenn man für den EEPROM feste Werte vorgeben will:
<pre>
.ESEG ; Das ist ein EEPROM-Segment
OneByte: .db 1 ; ein byte mit dem inhalt 0x01
MeinName: .db "Sepp Meier" ; mehrere Bytes mit Text
OneWord: .dw 1,2 ; zwei WORDs (16 Bit) mit dem inhalt 0x0001 u. 0x0002
....
</pre>

==Verzweigungen==
Es gibt zwei Arten, bedingte Programm-Sprünge zu formulieren:
* Durch irgendwelche Befehle, meistens durch Vergleichsoperationen, erst die Bits im Statusregister (SREG) zu setzen, und diese Status-Bits abzufragen und je nachdem einen Programmsprung durchzuführen oder nicht.
* Man kann aber auch abhängig von Datenbits in GPRs und SFRs den Folgebefehl überspringen (Skippen) lassen. Dieser Folgebefehl kann, muß aber nicht, ein Sprung- oder Callbefehl sein.

==Zusammenfassung==
Da dieser Artikel kein Assembler Tutorial sein kann und soll, soll hier auf die "eigentlichen" Instruktionen nicht eingegangen werden. Ich wollte nur versuchen, die "Denkweise" des Assembler und der AVR-Micros ein wenig näherzubringen und einige ermuntern, doch die ersten Operationen direkt am offenen Herzen des Kontrollers zu wagen.

In manchen Fällen habe ich aber sicher einige Leser endgültig verschreckt.

==Noch ein Tip==
Gut abgeschrieben ist am Anfang besser als schlecht ausgedacht. Gerade die verschiedenen Geräte-Initialisierungen (SFR) in den zahlreichen GCC Codeschnipsel können fast direkt abgeschrieben werden (Baudrate, Input/Output, etc), da der C-Compiler das ja auch nicht anders machen kann.

==Autor==
[[User:PicNick|PicNick]]

==Weblinks==
[http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11488 Ausführlicher Foren-Beitrag zum Thema Assembler-Programmierung] – Lang aber lehrreich
==Siehe auch==
*[[AVR]]
*[[Sourcevergleich]]
*[[GNU Assembler]]
*[[Assembler_Einf%C3%BChrung_f%C3%BCr_Bascom-User|Assembler Einführung für Bascom-User]]
[[Kategorie:Microcontroller]]
[[Kategorie:Robotikeinstieg]]
[[Kategorie:Software]]
[[Kategorie:Quellcode Assembler AVR]]

Diskussion:Pulsweitenmodulation

2007-03-24T17:05:52Z

Freak:

Folgendes Fragment hab ich vom Artikel hierhin verschoben, weil die Aussage so nicht zutreffend ist.
:''"Damit sich dieser Mittelwert einstellen kann, muss eine entsprechende Glättung des Signals vorliegen. Beim Motor ist das die Wicklung des Ankers, bei Schaltnetzteilen sind das die Kondensatoren am Ausgang."''
Was genau damit gemeint sein soll ist unklar. Der Mittelwert der Spannung stellt sich immer ein, unabhängig davon, ob geglättet wird oder nicht. Im Artikel ist zudem nur angedeutet, auf was geregelt wird (Leistung/Strom via Spannung) und dem, was gestellt wird (das Tastverhältnis der PWM).

--[[Benutzer:SprinterSB|SprinterSB]] 16:40, 26. Jan 2006 (CET)

Du hast recht. Kann gelöscht werden.

--[[Benutzer:Ogni42|Ogni42]] 20:09, 26. Jan 2006 (CET)

Nicht gleich löschen, wir sind keine Perfektionisten. Kann ja einfach jemand entsprechend bearbeiten falls er eine bessere Darstellung hin bringt.

--[[Benutzer:Frank|Frank]] 01:22, 27. Jan 2006 (CET)

Schwierig wird es, wenn man nicht weiß, was überhaupt gemeint sein sollte oder das Gesagte so versimpelt, daß es falsch wird...

Bei einem Motor mit PWM-Ansteuerung ist einem die Effektivspannung je relativ egal, was eher interressiert ist der effektive Strom. Der wiederum ist nicht nur abhängig vom der Spannung. Ohne Freilaufdiode etwa bringt PWM nicht das gewünschte Resultat, wie träge ein Motor auch sein mag.

Ein Schaltnetzteil, bei dem die Spannung anderes Vorzeichen haben kann als die Eingangsspannung, oder dessen Ausgangsspannung betragsmässig grösser sein kann, ist mit einer PWM-Erklärung so nicht zu verstehen. Im Resultat ist die Ansteuerung meist eine PPM (keine PWM), und wenn man die Effektiv-Eingangsspannung als Gleichspannung anlegte, würde nix passieren, ausser evtl was durchzukokeln.

Und LEDs über PWM anzusteuern bringt nicht weniger Verluste (bei gleichem Effektivstrom, also gleicher Helligkeit). Wer's nicht glaubt, rechne nach: Die Verlustleistung ist ''unabhängig'' vom Tastverhältnis.

--[[Benutzer:SprinterSB|SprinterSB]] 09:36, 30. Jan 2006 (CET)

Fehler im Bild!!!

Der Text betreffend des ersten Bildes stimmt; nur passt das Bild nicht ganz dazu.
Die Grundfrequenz der Schwingungen bleibt gleich (mit Pfeilen dargestellt <== Fehler?? Die Grundfrequenz bezieht sich auf den Anfang jedes Impulses(oder auch das Ende; aber immer auf den selben Punkt jedes Impulses); beim ersten Impuls geht der Pfeil aber von Anfang des 1. bis zum Ende des 2.Impulses (die andren 2 Darstellungen sind richitg))
Soll ich das ausbessern, oder macht das der Verfasser dieses Artikels?

--[[Benutzer:Freak|Freak]] 18:05, 24. Mär 2007 (CET)

Diskussion:Pulsweitenmodulation

2007-03-24T17:05:06Z

Freak: