Mikrocontroller.net - Benutzerbeiträge [de]

8051 Timer 0/1

2014-04-23T09:36:46Z

213.61.222.21: Geiz ist Geil entfernt

==Timer 0/1 bei 8051-Controllern==
===Einleitung===
Die Timer 0 und 1 sind bei jedem 8051-Kompatiblen vorhanden, bei allen gleich, und sie unterscheiden sich nur gering (Mode 3). Der Timer 2 ist erst ab 8052 enthalten und kann abweichende Register und Funktionen haben.
Die Timer 0/1 sind Aufwärtszähler. Bei Zählerüberlauf wird ein Flag gesetzt (TF0 bzw. TF1), das aber nicht unbedigt ausgewertet werden muss (z.B Baudratengenerator). Die Timer laufen nach Überlauf einfach weiter.
Der Zählerstand kann jederzeit gelesen und auch geändert werden. Beim 16-Bit Mode muss der Zählerstand aus 2 Bytes TH0:TL0 gebildet werden. Im 8-Bit Mode erfolgt ein automatischer Reload aus dem TH-Register in das TL-Register.
Die Quelle der Timer ist umschaltbar zwischen Oszillator/12 (Maschinentakte) und externem Eingang. Dies geschieht mit dem Bit C/T im TMOD-Register. C/T auf 0 bedeutet Timer-Betrieb (bekannte Frequenz wird gezählt -> Zeit), C/T auf 1 bedeutet Counter-Betrieb (externe Ereignisse werden gezählt -> z.B. Abfüllen von Werkstücken, Besucherzähler etc.)
Die Timer müssen gestartet werden. Dazu muss das TR0 (bzw. TR1) Bit gesetzt werden. Sie können jederzeit angehalten und wieder gestartet werden. Der Zählerstand bleibt gespeichert. Mit gesetztem Gate-Bit läuft der Timer nur dann, wenn zusätzlich der Gate-Eingang auf 1 liegt. Damit können z.B: Impulslägen gemessen werden. Praktischerweise ist dieser Eingang auch gleichzeitig ein Interrupt-Eingang, so dass man die fallende Flanke (Puls zu Ende, Timer steht, Ergebnis kann gelesen werden) per Interrupt auswerten kann.
===Betriebsarten===
Das Einstellen der Betriebsart erfolgt in einem Register (TMOD) für beide Timer! Die unteren 4 Bit gelten für Timer 0, die oberen für Timer 1. Die Bedeutung ist für beide gleich (ausser Mode 3). 
Das TMOD-Register ist nicht Bitadressierbar und sollte daher mit UND/ODER-Maskierung verändert werden. 'Harte' Schreibzugriffe konfigurieren beide Timer gleichzeitig.
{| class="wikitable"
|+ '''TMOD-Register'''
|-
! Bit7 || Bit6 || Bit5 || Bit4 || Bit3 || Bit2 || Bit1 || Bit0
|-
| G || C/T || M1 || M0 || G || C/T || M1 || M0
|}

{| class="wikitable"
|+ '''Timer Betriebsarten'''
|-
! M1 || M0 || Betriebsart
|-
| 0 || 0 || Mode 0: 13-Bit Timer/Counter (!!)
|-
| 0 || 1 || Mode 1: 16-Bit Timer/Counter
|-
| 1 || 0 || Mode 2: 8-Bit Timer/Counter mit Auto-Reload
|-
| 1 || 1 || Mode 3: 2x 8-Bit Timer/Counter (nur Timer0, wenn Timer1 Baudrate erzeugt)
|}
Erklärung: 
Mode 0 existiert noch aus Kompatibilität zum 8048 und gehört daher ins Museum. Trotzdem schaltet man den Mode leicht unbeabsichtigt ein, wenn man TMOD falsch konfiguriert. 
Mode 1 konfiguriert einen 16-Bit Timer/Counter, der Zählerstand ist auf 2 Register aufgeteilt. 
Mode 2 konfiguriert einen 8-Bit Timer/Counter mit Auto-Reload, gezählt wird im Register TL0 bzw. TL1, der Reload erfolgt bei Überlauf aus TH0 bzw. TH1. 
Mode 3: hier wird der Timer 0 in 2 8-Bit Timer/Counter aufgeteilt. Überläufe von TL0 sezten TF0, Überläufe von TH0 setzen TF1 (nur für Timer 0, Timer 1 macht dann z.B. Baudrate. Nur bei CPUs ohne Timer 2 oder Baudratengenerator interessant -> Museum!!) 
Es bleiben also effektiv nur die beiden Betriebsarten 1 und 2 übrig.
==== Timer oder Counter ====
Mit den Bits C/T wird zwischen Timer-Betrieb und Counter-Betrieb umgeschaltet. Als Timer (C/T = 0) zählt die Baugruppe Maschinenzyklen, daher entspricht der Zählerstand einer Zeit. Als Counter (C/T = 1) wird ein Signal von einem externen Zähleingang (P3.4 für Timer 0 und P3.5 für Timer 1) gezählt.
==== Gate-Betrieb ====
Wenn das Bit 0 ist, läuft der entsprechende Timer, wenn das zugehörige Timer-Run-Flag gesetzt ist (TR0 bzw. TR1). Wenn das Bit 1 ist muss '''zusätzlich''' noch der Gate-Eingang auf 1 sein. Dies ist P3.2 für Timer 0 bzw. P3.3 für Timer 1. Damit kann man einfach Pulsdauern ausmessen oder auch Betriebsstunden (mit Hilfszählern für die Überläufe).
==== Timer-Kontroll-Register ====
Die Überlauf-Flags und die Run-Bits der beiden Timer befinden sich im Register TCON. Dort sind zusätzlich noch je 2 Bits für die Konfiguration der beiden externen Interrupts untergebracht (der reinste Gemischtwarenladen...) 
Dies ist nicht tragisch, weil das Register Bitadressierbar ist. Um einen Timer zu starten schreibt man also einfach:
<syntaxhighlight lang="c">TR0 = 1; // Timer 0 starten
TR1 = 1; // Timer 1 starten
bzw. in Assembler
setb TR0 ; Timer 0 starten
setb TR1 ; Timer 1 starten
</syntaxhighlight>
Beim Überlauf (im 8-Bit Mode nach 2^8 = 256 Maschinenzyklen, im 16-Bit Mode nach 2^16 = 65536 Maschinenzyklen) wird das Überlauf-Flag TF0 bzw. TF1 gesetzt. Damit erkennt man, dass der Timer überglaufen ist. Bei der Bearbeitung muss man das Flag zur Bestätigung löschen, im Interrupt-Betrieb werden die Flags automatisch gelöscht.

===Schnelleinstieg für ungeduldige===
Von den Timern beim 8051 nimmst Du am Anfang nur Timer0/1 im 16-Bit Mode.
=> TMOD = 0x11; setzt beide Timer in den Mode 1. Nur wenn du serielle
Schnittstelle verwendest, brauchst Du evtl. den Timer 1 für die
Baudrate.
Wenn Du keinen Startwert und keinen Reload-Wert setzt, dann läuft der
Timer 65536 Maschinenzyklen (also bei 12MHz ohne X2-Mode 65,5ms). Bei
jedem Timerüberlauf musst Du das Timer-Flag wieder löschen (entfällt im
Interrupt-Betrieb, aber zunächst erstmal ohne) und dann kann man etwas tun. 
====Grundgerüst====
<syntaxhighlight lang="c">
void main (void)
// Initialisierung
TMOD = 0x11; // setzt beide Timer in den 16-Bit Mode
// für andere Modi musst du doch noch oben lesen
TR0 = 1; // Timer 0 läuft jetzt, mit jedem Maschinenzyklus
// wird jetzt TH0:TL0 um 1 hochgezählt

while(1)
{
// in der Endlosschleife
if (TF0 == 1) // Flag wird beim Überlauf auf 1 gesetzt
{ TF0 = 0; // Flag erstmal löschen, der Timer zählt bereits munter weiter
Tu_Was( ); // für was wolltest Du die Zeit nochmal nutzen??
}
Weitere_Aktionen( );
}
}</syntaxhighlight>
Für den Timer 1 änderst/ergänzt Du TR0 -> TR1, TF0 -> TF1. 
Was soll jetzt mit dem Timer gesteuert werden? Lassen wir zunächst mal die LED an P2.0 blinken. Statt Tu_Was(); kommt jetzt also P2_0 = ~P2_0; hin. Wie groß ist jetzt die Blinkfrequenz? Der Timer läuft im 16-Bit Mode. Also ist die Zeit zwischen 2 Überlaufen 2^16 Maschinenzyklen. Der dauert bei den meisten 8051-Controllern 12 Oszillatortakte. Mit einem 12MHz Oszillator kommt man also auf genau 1µs pro Maschinenzyklus und damit auf 65536µs zwischen 2 Überläufen. 
Doch zurück zur LED. Die ist jetzt also für 65,5ms an und danach für 65,5ms aus. Die Periodendauer beträgt hier also die '''doppelte''' Timerzeit, die Frequenz ergibt sich also zu 
<math>f = \frac 1 T = \frac 1 {2 \cdot Timerzeit}</math> 
Hier also ein symmetrisches Rechtecksignal mit einer Periodendauer von 131,072ms und einer Frequenz von 7,63Hz.

====Variable Timerzeit====
Auf Dauer ist das Geblinke aber langweilig... Also müssen die Zeiten verändert werden. Länger geht beim 8051 nur mit einem Hilfszähler (der ATMega und andere Controller haben hier ja einen Vorteiler). Für kürzere Zeiten kann nur der '''Startwert''' verändert werden, weil der Überlauf immer nach dem Zählerstand 65535=0xFFFF stattfindet. Wenn man also bei 15536 beginnt zu zählen sind es nur noch 50000 Maschinenzyklen bis zum Überlauf. Dieser Startwert muss nun auf 2 8-Bit Zählregister THx und TLx aufgeteilt werden. Dafür gibt es verschiedene Möglichkeiten von der Berechnung im Kopf, Taschenrechner, Tabellenkalkulation etc... 
Der (meiner Meinung nach) eleganteste Weg ist aber, den Compiler die Berechnung erledigen zu lassen (wozu hat man denn einen PC). Es muss also die Differenz zwischen Maximalwert 65536 und gewünschter Dauer (hier 50000) gebildet und aufgeteilt werden. Dazu schreibt man einfach:
<syntaxhighlight lang="c">// Beispiel für Timer 0, für Timer 1 TH1 und TL1 einsetzen
TH0 = (65536 - 50000)/256; // gibt das High-Byte von 15536 => 0x3C
TL0 = (65536 - 50000)%256; // gibt das Low-Byte von 15536 => 0xB0
oder in Assembler:
mov TH0, #HIGH(65536-50000) ; ausprobieren, ob der eigene Assembler
mov TL0, #LOW(65536-50000) ; dies unterstützt!
</syntaxhighlight>
Durch diese Schreibweise sieht man sofort die erzeugte Timerzeit und die Umrechnung erfolgt durch den Compiler (es wird also auf dem Controller keine Berechnung mehr durchgeführt). Etwas anders ist es, wenn keine Konstanten sondern Variablen dastehen. Dann sollte man etwas anders schreiben:
<syntaxhighlight lang="c">unsigned short Timerzeit, Reloadwert;
Timerzeit = irgendeine_Berechnung( );
Reloadwert = 65536 - Timerzeit;
TH0 = Reloadwert / 256;
TL0 = Reloadwert % 256;
</syntaxhighlight>
Auf den ersten Blick etwas umständlich, aber so erkennt der Compiler, dass nur eine Aufteilung in Low- und High-Byte gewünscht ist und weist einfach die Register zu statt Division und Modulo zu berechnen. Bei der Programmierung in Assembler muss man hier 16-Bit Arithmetik berechnen, für Anfänger hört hier der Spass auf (=> erstmal bei konstanten Zeiten bleiben).

====Längere Wartezeiten erzeugen====
''(zum größten Teil aus meinen Beiträgen hier übernommen: http://www.mikrocontroller.net/topic/264647#2752818 )'' 
Dazu zählst du eine Variable hoch. Nimm mal <syntaxhighlight lang="c">unsigned int Ticks;</syntaxhighlight>
Bei jedem Überlauf wird Ticks erhöht und wenn die benötigte Anzahl
(=Zeit in s / 65,5ms) erreicht ist, machst Du was und setzt Ticks wieder
auf 0.

<syntaxhighlight lang="c">
void main (void)
{
// Timer-Initialisierung
TMOD = 0x11;
//TH0 = (65536 - Benoetigte_Zeit)/256; // für Startwert oder Reload
//TL0 = (65536 - Benoetigte_Zeit)%256; // für Startwert oder Reload
TR0 = 1; // Timer 0 starten - TR1 für Timer 1

while(1) // Endlosschleife
{
if (TF0 == 1) // Timer 0 ist überglaufen
{ Ticks++; // sonst braucht man erstmal nix.
TF0 = 0; // Flag löschen
}
if (Ticks == 0)
{ Schalte_Ein( ); //einschalten -> wird mehrfach ausgeführt
// oder du fügst ein Merker-Flag ein
}
if (Ticks == Ausschaltzeit)
{ Schalte_Aus( ); // ausschalten -> wird nur einmal ausgeführt
Ticks = 0; // wenn Ticks gelöscht wird
}
}
} </syntaxhighlight>

Damit kannst Du zunächst einen Vorgang realisieren. Wenn Du die Ticks
einfach weiterlaufen lässt, dann kann man auch sowas machen:
<syntaxhighlight lang="c">
if (Taster1 == 1)
{ Ausschaltzeit1 = Ticks + Dauer1; //zur aktuellen Zeit die Dauer addieren
Einschalten(1);
}
if (Ticks == Ausschaltzeit1)
{ Ausschalten(1);
}
if (Taster2 == 1)
{ Ausschaltzeit2 = Ticks + Dauer2; //zur aktuellen Zeit die Dauer addieren
Einschalten(2);
}
if (Ticks == Ausschaltzeit2)
{ Ausschalten(2);
}
</syntaxhighlight>
Das funktioniert mit (fast) beliebig vielen Signalen und es ist auch kein Problem, wenn es einen Überlauf gibt. Wenn Ticks z.B. auf 65000 steht und du willst eine Dauer von 60 Sekunden (= 60000ms/65,536ms = 915 Ticks), dann ergibt die Addition für die Ausschaltzeit 379 (gleicher Datentyp für alle Schaltzeiten!).

====kurze Zeiten erzeugen====
Die Timer zählen nach dem Überlauf sofort ab 0x0000 weiter. Also muss man wieder einen Startwert (Reload) laden, so dass der Timer nach einer kürzeren Zeit überläuft. Die Formeln im Quelltext kann man problemlos mit Konstanten füllen, die Division und Modulo wird dabei nicht wirklich berechnet, sondern der Compiler fügt die Ergebniswerte in den Code ein. (anders sieht es für variable Zeiten aus, dazu später mehr) Für einen Grundtakt von 1ms schreibt man also einfach nach jedem Überlauf wieder in die Zählregister:
<syntaxhighlight lang="c">TH0 = (65536 - 1000)/256; // 1ms = 1000MZ, davon das High-Byte in TH0
TL0 = (65536 - 1000)%256; // das Low-Byte in TL0
</syntaxhighlight>
Da der 8051 bei den Timern 0 und 1 keine getrennten Zähl- und Reload-Register hat, muss man diesen Wert nach jedem Überlauf möglichst schnell wieder in die Register schreiben (daher nimmt man da dann meist Interrupts). 
Programmausschnitt:
<syntaxhighlight lang="c">while(1) // Endlosschleife
{
if (TF0 == 1) // Timer 0 ist überglaufen
{ TH0 = (65536 - 1000)/256; // 1ms = 1000MZ, Hih-Byte
TL0 = (65536 - 1000)%256; // Low-Byte in TL0
TF0 = 0; // Flag löschen
Ticks++; // sonst braucht man erstmal nix.
}
// Rest des Programms
}</syntaxhighlight>
Bei einer Millisekunde läuft die Variable Ticks bereits nach 65536ms, also etwa einer Minute über. Wenn man längere Zeiten benötigt, dann entweder die Ticks alle 10, 20 oder 50ms einstellen oder (in C ja kein echtes Problem) unsigned long Ticks; verwenden. Damit kannst Du in ms-Auflösung Zeiten bis 1193 Stunden erzeugen, bevor der Zähler überläuft... Braucht aber natürlich mehr Speicher (auch für die Schaltzeiten!). Ohne Interrupts kann es aber passieren, dass die Bearbeitung des restlichen Programms länger als die Timer-Zeit dauert. Dann werden die Zeiten sehr ungenau. Also erstmal nicht wundern...

====Reload mit variablen Zeiten====
Für variable Zeiten (z.B. PWM für Modellbau-Servo mit 1-2ms Impuls und 20ms Periodendauer) darf man die (16Bit) Variablen nicht einfach in die obige Zeile einsetzen. Dabei wird sonst die Division und die Modulo-Operation wirklich ausgeführt (die sich ergebenden Zeiten sind dann für die Tonne...). Hier muss man (am besten eine Phase vorher, wenn der Timer gerade übergelaufen war) die Variable berechnen.
<syntaxhighlight lang="c">while(1) // Endlosschleife
{
if (TF0 == 1) // Timer 0 ist überglaufen
{ TH0 = (65536 - Pulszeit)/256; // Hih-Byte
TL0 = (65536 - Pulszeit)%256; // Low-Byte in TL0
TF0 = 0; // Flag löschen
Ticks++; // sonst braucht man erstmal nix.
Pulszeit = 1000 + 4 * Dip_Schalter; // ergibt 1-2ms
}
// Rest des Programms
}</syntaxhighlight>
===Timer-Interrupt ohne Schrecken===
Mit Interrupt vermeidet man die Ungenauigkeiten beim Timer-Reload. Sobald der Timer bei aktiviertem Interrupt überläuft, springt der Prozessor in die Interrupt-Service-Routine und führt den dortigen Code aus. Danach geht es an der alten Stelle im Hauptprogramm weiter. (der sollte daher möglichst kurz sein)
Interrupts aktiviert man erstmal einzeln für jede Quelle, danach noch den Hauptschalter EA. 
Zum Thema [[Interrupts]] gibt es ein extra Kapitel.
<syntaxhighlight lang="c">TMOD = 0x11;
TH0 = (65536 - 1000)/256; // für Startwert
TL0 = (65536 - 1000)%256; // für Startwert
TR0 = 1; // Timer 0 starten - TR1 für Timer 1
ET0 = 1; // Interrupt für Timer 0 aktivieren
EA = 1; // Globalen Interrupt aktivieren -- ab jetzt geht's rund
</syntaxhighlight>
Die Interrupt-Service-Routine ersetzt die if(TF0)-Abfrage aus dem Hauptprogramm. Das ist kein Hexenwerk, es kommt nur ein Schlüsselwort hinter den Funktionsnamen und eine Nummer, die die Quelle angibt. (gilt für den Compiler RC51 aus RIDE)
<syntaxhighlight lang="c">void ISR_Timer0 (void) interrupt 1
{
TH0 = (65536 - 1000)/256; // Reload
TL0 = (65536 - 1000)%256; // Reload
// TF0 = 0; // Flag löschen geht jetzt automatisch! Der reine Luxus!
Ticks++; // sonst braucht man erstmal nix.
}
</syntaxhighlight>
Ticks muss jetzt als globale Variable deklariert werden, damit sowohl
die ISR als auch main() darauf zugreifen können. Erbsenzähler rechnen natürlich noch aus, wieviele µs es bis zum Relaod dauert und korrigieren damit den Reload-Wert:
<syntaxhighlight lang="c">// wenn es z.B. 6us bis zum Sprung in die ISR dauert:
TH0 = (65536 - 1000 + 6)/256; // korrigiert um 6us
TL0 = (65536 - 1000 + 6)%256; // korrigiert
</syntaxhighlight>
Es ist aber nicht immer möglich, exakt auf 1µs genau zu arbeiten (ein
laufender ASM-Befehl kann nicht unterbrochen werden und dauert 1, 2 oder
4 MZ). Aber zuviel überlegungen nutzen eh nichts, weil der Quarztakt ja
auch nicht exakt ist. (eine Uhr mit Timer-Interrupt läuft aber trotzdem
mit einer Abweichung von wenigen Sekunden/Woche) 
=== Timer im 8-Bit Modus===
ToDo.
=== Counter-Betrieb===
ToDo.
===Kritische Betrachtung, Fallstricke===
Jetzt werden viele "Aber..." rufen. Wenn man genau hinschaut, gibt es natürlich den Fall, dass das Low-Byte übergelaufen ist, bis man das High-Byte geschrieben hat. Ebenso können die Timer-Zeiten daneben liegen, wenn in der Hauptschleife andere zeitaufwändige Aktionen drinstehen. Daher kann man in kritischen Fällen den Timer von dem Reload stoppen und anschliessend wieder starten. In dieser einfachen Einführung habe ich auf solche Details aber für die Übersicht verzichtet... 
'''Nachricht an den Autor'''
[http://www.mikrocontroller.net/user/show/b_spitzer B. Spitzer]
[[Kategorie:8051]]

AVR-Simulation

2012-10-29T07:16:24Z

213.61.222.21: /* Starten von SimulAVR */

[[Category:AVR]]
== SimulAVR ==

[http://www.nongnu.org/simulavr/ SimulAVR] ist ein Simulator, der einige Prozessoren der AVR-Familie auf einem PC-Hostsystem simulieren kann. Dieser Simulator ist im [[WinAVR]]-Paket enthalten (/WinAVR/bin/simulavr.exe).

SimulAVR wird über ein dazu passendes Frontend bedient. GDB und Insight sind zwei, ebenfalls in WinAVR enthaltene, Programme, die ein solches Frontend bilden.

Wer "textorientiertes" Debugging mag, oder beispielsweise ''emacs'' als Frontend verwenden möchte, der nutzt den [[GDB]], den GNU Debugger. Er ist im WinAVR-Paket enthalten (/WinAVR/bin/avr-gdb.exe). Wer gleich eine grafische Benutzeroberfläche (GUI) verwenden möchte, nutzt Insight (welches intern ebenfalls den GDB verwendet).

Beide Debugger, also GDB oder Insight, benötigen ein Backend. Entweder handelt es sich dabei um einen ICE/[[JTAG]]-Debugger wie z. B. [http://avarice.sourceforge.net/ AVaRICE] als Interface zu einem realen AVR-Mikrocontroller oder um einen Simulator.

=== Starten von SimulAVR ===

[[Datei:SimulAVR-Display.png|right|220px]]
Um SimulAVR mit default-Parametern zu starten, reicht es aus, folgende Zeile in einer Shell/Eingabeaufforderung einzugeben:

$ simulavr -g -d <AVR-Prozessortyp>

SimulAVR startet dann mit den defaultparametern und stellt einen GDBServer-Prozess auf dem lokalen oder entfernten Host auf Port 1212 zur Verfügung.
Das ''Backend'' der Simulation ist nun Einsatzbereit.

Eine weitere Möglichkeit ist, SimulAVR mit Display zu starten. Dann werden während der Ausführung die Werte der Register und dem RAM angezeigt (siehe Bild).

$ simulavr -g -P simulavr-disp -d <AVR-Prozessortyp>

Eine Übersicht der unterstützten AVR-Prozessoren und der SimulAVR spezifischen Parameter bekommt man durch folgende Zeile:

$ simulavr --help

=== Starten des GDB ===

Um das (vorläufige) Frontend GDB zu starten, reicht folgende Zeile:

$ avr-gdb

Der GDB meldet sich mit folgendem Bildschirm:

<pre>
Current directory is c:/WinAVR/testprj4/
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=avr".
(gdb)
</pre>

'''(gdb)''' ist der Prompt.

Soll während dem Debuggen der Quellcode angezeigt werden, der zur Zeit ausgeführt wird, kann GDB wie folgt gestartet werden.

$ avr-gdb -tui

Beim (gdb) prompt dann das Layout auf Assembler umschalten.,

(gdb) layout asm

=== Simulieren/Debuggen ===

Im ersten Schritt muss dem GDB die gewünschte Datei (vorher mittels entsprechendem ''Makefile'' erzeugt) bekannt gemacht werden:

(gdb) file main.elf
Reading symbols from main.elf...done.

Als nächstes muss dem GDB mitgeteilt werden, welches Ziel (target) er als Backend verwenden soll:

(gdb) target remote localhost:1212

oder kürzer:

(gdb) targ rem :1212
Remote debugging using :1212
0x00000000 in __vectors ()

Jetzt muss das Programm in den Simulator geladen werden:

(gdb) load
Loading section .data, size 0x32 lma 0x1bc
Loading section .text, size 0x1bc lma 0x0
Start address 0x0, load size 494
Transfer rate: 3952 bits in <1 sec, 30 bytes/write.

Damit der Simulator nicht das gesamte Programm abarbeitet, sollte man ''breakpoints'' setzen.
Den Ersten am besten bei ''main'':

(gdb) b main
Breakpoint 1 at 0xd2: file main.c, line 16.

Jetzt kann man das Programm im Simulator mit ''continue'' starten:

(gdb) c
Continuing.

Bei Erreichen des zuvor gesetzten ''breakpoints'' stoppt GDB und meldet:

Breakpoint 1, main () at main.c:16
(gdb)

Eine Liste der verfügbaren debug-befehle des GDB findet sich durch die Eingabe von '''help'''.

[TODO] Einige häufige GDB-Commands als Beispiel einfügen.

== VMLab ==

[http://www.amctools.com/vmlab.htm VMLab] ist eine komplette Freeware-IDE mit Debugger und Simulator für MS-Windows. VMLab arbeitet mit [[WinAVR]] zusammen und kann AVR-Peripheriehardware simulieren. Leider hat der Autor von VMLab die Entwicklung im Jahr 2006 eingestellt, da dem Projekt nicht der gewünschte kommerzielle Erfolg vergönnt war. Die aktuelle Version ist 3.15 von Oktober 2009.

Siehe auch:
* Forumsbeitrag [http://www.mikrocontroller.net/topic/24494#714662 VMLAB Bug bei Stackpointer/Interrupt?]
* [http://www.mikrocontroller.net/topic/85212#716727 Workaround]

== AVR Studio ==

[[Bild: AVR-Studio_Simulation.png|thumb|right|250px|Simulator-Ansicht in AVR Studio]]
[[AVR-Studio|AVR Studio]] von Atmel enthält neben dem Übersetzungsteil, dem Debuggingteil auch einen Simulatorteil. Eine Übersicht über alle drei Programmteile gibt der Powerpoint-Vortrag [http://ece353.ecs.umass.edu/lab2/labC-lectureslides.pptx AVR Studio: The comprehensive tutorial] (MS PowerPoint ''2007'') von Jeremy Gummeson und Brendan Kemp.

Wenn nur ein Breakpoint gesetzt ist, kann mit F5 das Programm einen Abarbeitungszyklus machen. Die Bearbeitung bleibt dann wieder beim Breakpoint stehen. Mit der Stoppuhr kann dann die Zeit für den abgearbeiteten Programmteil gemessen werden. Mit der rechten Mouse-Taste kann die Stoppuhr zurückgesetzt werden.

Ausführliche Anleitung zum Ablauf einer Simulation: [http://www2.tech.purdue.edu/ecet/courses/ecet309/Reference_Materials/Simulation_AVR_Studio_4.pdf Tutorial der Purdue University] (engl., PDF)

Externe Signale können mit den Tools HAPSIM oder über eine Stimulidatei in den Simulator eingespeist werden.

Zu beachten ist, dass sich mit der Einführung des AVR Simulator 2, welcher Vorteile wie Unterstützung von [[I2C|TWI]] bietet, das Datenformat für extern zugeführte Stimuli-Files geändert hat. Eine kleine Einführung inkl. Beispiel bietet die im AVR-Studio enthaltene Hilfe:
:AVR Studio Help → AVR Tools User Guide → Simulator → Simulator2 Stimuli

=== HAPSIM ===

[http://www.helmix.at/hapsim/index.htm HAPSIM] (Helmis AVR Periphery Simulator) ist ein Tool zur graphischen Simulation von Tasten, [[LED]], [[LCD]] und Terminalfunktionen in AVR Studio. (deutsch/engl., Windows, Freeware). Hinweise zur Installation von Hapsim nach einem AVR Studio Update stehen im Forum: http://www.mikrocontroller.net/topic/118668

=== Stimuli ===

Über eine sog. Stimuli-Datei lassen sich von ausserhalb Signale dem AVR Studio zuführen. Informationen zum Aufbau einer Stimulidatei finden sich in obigem "AVR Studio: The comprehensive tutorial" und bei Atmel ([http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=46 What is the format of the AVR Studio simulator stimuli files?]). Der [http://www.hot.ee/nppcsoftware/ Stimuli Generator for AVR Studio] ist eine Freeware für die Erzeugung von Stimulidateien und deren grafischen Darstellung. Für dieses Programm ist .NET 1.1 oder 2.0 erforderlich.

=== LogAnalyser ===

[http://www.dresco.co.uk/LogAnalyser/ LogAnalyser] v1.00 (c) 2008 Jon Escombe is a graphical "logic analyser" style display of Atmel AVR Studio simulator log files. The project is built using the (excellent) zedGraph charting class library, and the source code is made available under GPL license. Requires Windows XP and .NET framework 2.0 to run.

=== TCPSimDBG ===

[http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=74350 TCPSimDBG] ist ein Plugin für [[AVR-Studio]] um Remote Simulating/Debugging über TCP/IP durchzuführen. Ein TCP/IP-Terminal oder Serverprogramm kann sich mit dem Simulator/Debugger von AVR-Studio verbinden und Informationen aus dem Debugprozess abrufen und ändern. Damit lassen sich virtuelle Geräte (Devices) eingerichten. (Atmel SDK Lizenz, Windows XP, 2003, Vista .NET 3.5 erforderlich)

=== AVR Logic Analyzer ===

[http://www.coynetechsystems.com/avrlogicanalyzer/index.php AVR Logic Analyzer] von Coyne Technology Systems ist ein AVR Studio Plugin zur grafischen Anzeige der simulierten I/O-Ports.
(kommerziell)

== Avrora ==
[http://avrora.sourceforge.net/ Avrora], a research project of the UCLA Compilers Group, is a set of simulation and analysis tools for programs written for the AVR microcontroller produced by Atmel and the Mica2 sensor nodes. Avrora contains a flexible framework for simulating and analyzing assembly programs, providing a clean Java API and infrastructure for experimentation, profiling, and analysis.

== Proteus VSM for Atmel AVR ==

[http://www.labcenter-electronics.com/products/avr.cfm Proteus VSM for Atmel AVR] ist ein kommerzieller AVR Simulator.

In der Codesammlung gibt es dafür ein [http://www.mikrocontroller.net/topic/118974#1072449 Virtuelles AVR Funk Pollin Simulationsmodell] von Daniel Cagara.

== CrossWorks for AVR ==

[http://rowley.co.uk/avr/index.htm CrossWorks for AVR] besitzt einen ''core simulator'' für AVRs. (Windows, Mac OS X, Linux, Solaris)

== simavr ==

[http://gitorious.org/simavr simavr] is a new AVR simulator from Michel "buserror" Pollet for linux, or any platform that uses avr-gcc. It uses avr-gcc own register definition to simplify creating new targets for supported AVR devices.

The status of the project is the core works at about 98% (ie, it works, but there is a known bug). The supported IOs are eeprom, IO ports (including pin interupts), 8 bits timers (well, one of mode of the myriad) and a simple UART that makes “printf” work.

gdb support is planned next.

Lizenz: GPL v3 
[http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=86665 Diskussion bei avrfreaks.net]

== avrtest ==

avrtest ist ein freier AVR Core-Simulator, der zur Ausführung der avr-gcc Testsuite verwendet wird. Über spezielle "magische SFRs" können bestimmte Aktionen ausgelöst werden wie z.B. definierter Programmabbruch oder die Ausgabe eines Zeichens auf Console, so daß ein Programm wie
<c>#include <stdio.h>

int main()
{
printf ("Hallo Welt!\n");

return 0;
}
</c>
analoge Resultate bringt wie ein Programm, das nativ auf dem Rechner ausgeführt wird.

avrtest ist Open Source, einfach gehalten und auf Geschwindigkeit getrimmt. Die Eingabe von Stimuli ist nicht möglich, und interne Peripherie wird nicht unterstützt.

=== Weblinks ===

* [http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/ avrtest: Projekt bei sourceforge]
* [http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/README?view=markup README zur Einleitung (en)]
* [http://lists.gnu.org/archive/html/avr-gcc-list/2011-06/msg00015.html Beschreibung in der avr-gcc-list Mailingliste (en)]

== BASCOM AVR ==

In [http://www.mcselec.com/ BASCOM AVR] ist ein Simulatorteil enthalten und damit ist auch die Simulation von Geräten (LCD, UART) möglich. BASCOM AVR wird von MCS Electronics verkauft (89€) und ist ein unter Windows laufender [[Basic|BASIC]] [[Compiler]] für Atmel AVR Mikrocontroller. Eine auf 4 KB Codegröße eingeschränkte Demoversion ist kostenlos erhältlich.

== AVR Simulator IDE ==

[http://oshonsoft.com/avr.html AVR Simulator IDE] from oshonsoft.com is a powerful application that supplies AVR developers with user-friendly graphical development environment for Windows with integrated simulator (emulator), Basic compiler, assembler, disassembler and debugger. (Kommerziell, Testversion verfügbar)

== MacSim - AVR simulator for OS X ==
[http://www.fracturedsoftware.com/macsimavr/ MacSim Alpha 4]

Einschränkungen u.A.: "There are currently no timers, interrupts, or EEPROM. The processor is 'generic' and has fixed size data and instruction memories."

Mikrocontroller Vergleich

2010-05-21T08:37:45Z

213.61.222.21: /* Interrupt-feste Programmierung von I/O-Ports */

Ein paar Kriterien für den CPU-Core und die µC-Familie.

==Compiler verfügbar, bzw wieviel will man dafür ausgeben?==

Und wie verbreitet ist der Compiler? Finde ich dafür Hilfe, beispielsweise in Form von Support-Foren?

Für '''[[ARM]]''', '''[[AVR]]''' und '''[[MSP430]]''' gibt es mit GCC einen guten und kostenlosen Compiler. Bei '''ARM''' sind jedoch die Schritte zum fertigen Programm recht komplex und Library/Laufzeitsystem benötigen einige Handarbeit.

Für '''ARM''' gibt es von IAR eine auf 32KB begrenzte kostenlose Version eines umgänglicheren kommerziellen Compilers.

Des Weiteren gibt es für '''[[MSP430]]''' eine auf 4KB begrenzte kostenlose Version der Entwicklungsumgebung von IAR und eine auf 8KB begrenzte kostenlose Version der Entwicklungsumgebung Code Composer Essentials (basiert auf Eclipse) von Texas Instruments.

Für '''[[PIC]]''' und '''[[8051]]''' kann man entweder den Open-Source-Compiler [http://www.sf.net/projects/sdcc SDCC] verwenden (brauchbar, aber nicht mit GCC vergleichbar) oder diverse Löhnwares, bis 4-stellige Beträge (Keil: 2600€ , freie Version codegrösseneingeschränkt), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Für '''[[PIC]] 10/12/16''' gibt es den HI-TECH C-PRO von HI-TECH(Microchip) in einer freien Version. Der CC5X unterstützt zwar keine High-End PICs, dafür die meisten Mid-Range. Die einzige Einschränkung der freien Version des CC5X ist die Limitierung auf 1024 Instruktionen pro Modul, nicht so gute Codeoptimierung und die Begrenzung von Variablen auf 16-Bit.

Für die '''[[PIC]] 18''' gibt es den C18 von Microchip. Er ist frei erhältlich und hat ähnliche Einschränkungen wie der C30.

Für die '''[[PIC24]]''' und '''[[dsPIC]]''' gibt es den C30 von Microchip. Er basiert auf gcc und ist frei erhältlich, wobei nach 6 Wochen nicht mehr alle Optimierungsstufen wählbar sind, dann maximal -O1. Wie für alle PIC ist mit dem MPLAB eine kostenlose IDE mit Debugger und Simulator verfügbar.

Für '''[[R8C]]/M16C''' gibt es eine Demoversion des Herstellers und eine noch ziemlich frische (lies: Stand 2005 nicht ausgereifte) Version vom GCC.

Für '''[[ST7]]''' gibt es (teils limitierte) C-Compiler, teils mit IDE (z.ß. Cosmic und Ride). Toolchain von ST kostenlos erhältlich.

Von Toshiba gibt es für '''[[TLCS-870]]''' mit den Starterkits eine IDE mit C-Compiler und Assembler. Ausserdem gibt es Toshibas eigene "C-Like Language". Diese Tools sind nicht frei downloadbar.

Zilog stellt für '''[[Z8_encore!]]''' eine unbeschränkte IDE mit C-Compiler, Debugger und Simulator kostenlos per Download zur Verfügung.

'''Pascal'''

Für PIC,DSPIC und AVR gibt es einen sehr guten PASCAL-Compiler "MikroPascal"
der, in der Downloadversion Code-Size begrenzt ist,
und den man zu moderaten Preisen zur "Vollversion" aufrüsten kann.
http://www.mikroelektronika.co.yu/
( ab 149,- € )

Elektor-Verlag 'Pascal für 8051 und Derivate' Buch+Compiler(Vollversion)

AVRco Pascal Compiler (http://www.e-lab.de/),
Kostenlose Version für Mega8/88

'''BASIC:'''

Sowohl für den AVR als auch für die 8051er gibts von MCS-Electronics eine Demoversion eines BASIC-Compilers,
der leicht im Funktionsumfang und Codegröße eingeschränkt ist.
[http://www.mcselec.com/]

Darüber hinaus kursieren im Netz Versionen eines BASIC-Interpreters für 8052er mit dem Namen "8052 AH-BASIC", wobei die Originalversion von INTEL stammt. Dieser Interpreter unterstützt sogar Fließkomma-Arithmetik und ist als Freeware verfügbar.

==Architektur==

Betrifft vor allem Assembler-Programmierung und die Frage, wie einfach oder umständlich sich C-Code in Maschinensprache übersetzen lässt.

Dass für alle Architekturen teils mehrere C-Compiler existieren, hat wenig mit Eignung und viel mit Markt zu tun. Zudem ist meist nur entscheidend, ob ein Controller die Anforderungen erfüllt, nicht jedoch wie gut er das tut.

Manches davon ist durchaus subjektiv. Bei abweichender Meinung bitte als Diskussion starten, nicht einfach löschen.

'''8051''': Typische Akkumulator-orientierte 8-Bit Architektur. Eine gewisse Komplexität entstand durch die sukzessive Erweiterung auf mehr RAM als ursprünglich vorgesehen war, mit etlichen unterschiedlich adressierten RAM-Bereichen als Folge. Für C-Compiler nur eingeschränkt geeignet.

'''ARM''': 32bit RISC-Architektur. In den gängigen Implementierungen mit dem ARM7TDMI-Core (Architektur V4 = ARMv4T) stehen 2 Befehlssätze zur Verfügung: 32bit-codiert für Tempo, sofern der Speicherdurchsatz das zulässt, und 16bit-codiert (Thumb) für kompakte Programme. Cortex M3 (ARMv7) kennt ausschliesslich Thumb2 codierte Befehle, wurde gegenüber Thumb erheblich erweitert. Einheitlicher 32bit-Adressraum. Exzellente Zielmaschine für C-Compiler.

'''AVR''': Register-orientierte, an RISC Prinzipien angelehnte 8-Bit Architektur. Getrennte Adressräume für RAM und ROM. Registersatz nicht einheitlich nutzbar. I/O-Bereich nicht einheitlich adressierbar. Nur ein Teil des I/O-Bereiches ist bitweise manipulierbar. Einheitliche RAM-Adressierung. Für C-Compiler geeignet.Bemerkung: Laut Wikipedia wurde der Controller während der Entwicklungsphase für den Einsatz von C-Compilern optimiert.

'''MSP430''': Register-orientierte 16-Bit RISC-Architektur mit vollständiger Orthogonalität. Einheitlicher Adressraum für RAM und ROM. Exzellente Zielmaschine für C-Compiler. Angelehnt an die legendäre PDP-11, vieles wurde übernommen.

'''PIC''': Akkumulator-orientierte 8-Bit Architektur. Getrennte Adressräume für RAM und ROM. RAM-Banking, ROM-banking. Umständlicher Zugriff auf Daten im ROM (nur 12/14-Bit Versionen). Viele für C-Compiler wesentliche Elemente sind nur umständlich realisierbar (z. B. Code/Datenadressierung mit Banking, Vergleich mit Vorzeichen).

'''PIC24''': Register-orientierte 16-Bit Architektur mit getrennten Adressräumen für RAM und ROM, wobei ein Teil des ROM in den RAM-Adressbereich eingeblendet werden kann. Fast alle Befehle sind auf Register und RAM anwendbar, incl. Bitmanipulationen.

'''dsPIC''': wie '''PIC24''', mit zusätzlichen DSP Befehlen.

'''R8C''': 16-Bit 2-Adress CISC-Architektur. Einheitlicher 64KB Adressraum für RAM und ROM. Gute Zielmaschine für C-Compiler.

'''M16C''': Unter Bezeichnung M16C existieren zwei verschiedene inkompatible Architekturen. Die Modelle bis /6x sind grundsätzlich identisch mit R8C, die /8x Modelle mit M32C (hier nicht näher betrachtet). Der 64KB RAM-I/O-Adressraum ist ein Teil des 1MB großen Gesamtadressraumes, Daten im ROM liegen jedoch ausserhalb dieser 64KB und sind daher anders als beim R8C nicht mit 16-Bit Zeigern adressierbar. Gute Zielmaschine für spezialisierte C-Compiler, GCC jedoch tut sich etwas schwer mit den Adressräumen.

'''ST7''':Akkumulatorarchitektur, Gemeinsamter Code/Datenadressraum (von-Neumann). 63 Befehle. Einheitlicher 64KB Adressraum für RAM und ROM.

'''TLCS-870''': 8-Bit CISC-Architektur, aus Z80 weiterentwickelt. Gemeinsamer Adressraum für RAM und ROM bis 60KB ROM, darüber getrennt. Adressraum 64/128KB. Serie 870/X mit 1MB Adressraum existiert, aber nur als OTP/Maskenversion.

'''Z8e''': Register-orientierte 8-Bit Architektur, 2-Adress-CISC. Getrennte Adressräume für RAM und ROM. Historisch bedingt 3 RAM-Adressräume (8-Bit, 12-Bit, 16-Bit). Für C-Compiler geeignet

Kleiner nicht repräsentativer Compiler-Vergleich. Verwendet wurde eine Variante des crc8-Code von Colin O'Flynn. Jeweils kleinstes Speichermodell, auf Platz optimiert:
{|
|Compiler
| Befehle(1)
| Bytes(1)
| Befehle(2)
| Bytes(2)
|-
|GCC AVR
|24
|48
|24
|48
|-
|Keil 8051
|24
|38
|74
|109
|-
|SDCC 8051
|24
|40
|35
|54
|-
|Zilog Z8e
|21
|54
|27
|73
|-
|PIC C18
|26
|52
|95
|206
|-
|SDCC PIC18
|41
|112
|41
|112
|-
|SDCC PIC16
|26
|52
| -
| -
| (for pic16f84)
|-
|HEW R8C/M16C
|20
|48
|20
|48
|-
|GCC 68HC11
|36
|65
|36
|65
|-
|GCC MSP430
|17
|40
|17
|40
|-
|GCC ARM7
|12
|48
|12
|48
|-
|GCC ARM7-Thumb
|20
|40
|20
|40
|}
(1): Lokale Daten ggf. statisch gespeichert, nicht reentrant.

(2): Lokale Daten auf dem Stack, also reentrant.

==Sind CPU-spezifische Erweiterungen in C erforderlich?==

'''8051''':
* 5-6 Speicherklassen für Datenspeicher (direkt, indirekt, 8-Bit "external", 16-Bit "external", Flash, evtl. noch Einzelbits).
*Außerdem noch Adresserweiterungen durch Mapping, Paging und Banking

'''AVR''':
* 3 Speicherklassen für Datenspeicher (RAM, ROM, EEPROM).
* In neueren Versionen von avr-libc kommt zwar eine 4. Klasse für die Fuse-Bits hinzu, die aber nur für die Konfiguration des Controllers verwendet wird und für das C-Programm selbst nicht relevant ist.

'''ARM''', '''MSP430''', '''R8C''': nein.

'''PIC''':
* 3 Speicherklassen für Datenspeicher (shared RAM, banked RAM, ROM).

'''Z8e''':
* Für atomic execution (s.u.) notwendig, aber nicht existent.
* 4 Speicherklassen für Datenspeicher (256B, 4KB, 64KB, Flash).

==Sind Daten in RAM und ROM mit dem gleichen Code benutzbar?==

'''8051''', '''AVR''', '''PIC''', '''Z8e''' wie generell alle [[Harvard-Architektur|Harvard-Architekturen]]: NEIN. Daten im ROM
erfordern anderen Zugriff als Daten im RAM. Entweder versteckt das der Compiler in Runtime-Routinen für Pointerzugriffe, oder man kann Routinen nicht so schreiben, dass sie beides als Parameter verdauen können. Bei kleinen Programmen von ein paar KB kein Problem, bei größeren jedoch schon. Bei AVR/GCC ziemlich fehlerträchtig.

'''PIC24''' und '''dsPIC''' können einen Teil des ROM in den RAM-Adressbereich einblenden.

'''M16C''': Hängt vom Compiler ab. Mit 16-Bit Zeigern (GCC) nicht, 20-Bit Zeiger sind ineffizient.

'''ARM''', '''MSP430''', '''R8C''', '''ST7''', '''TLCS-870''': [[von Neumann-Architektur]], problemlos.

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''ST7''', '''TLCS-870''', '''Z8e''': kein Problem.

'''PIC''': PIC18 ja, PIC16,PIC12,PIC10 nein. RAM-Puffer die größer sind als das RAM in einer Bank sind nur mit Klimmzügen möglich.

==Skalierbarkeit==

Vor allem für jene wichtig, die sich scheuen, für
verschiedene Aufgaben verschiedene Lösungen zu verwenden.

Spezielle Versionen für LCD-Ansteuerung wurden in dieser Übersicht nicht berücksichtigt.

'''8051''': 8-Pin/1KB aufwärts, überwiegend 40/44-Pin und 64/68-Pin. Architekturbedingte Grenze bei 64KB Code, 64KB RAM - Versionen mit mehr Flash nutzbar via Banking (Compiler-Support vorhanden) existieren, Versionen mit bis zu 100 MHz Taktfrequenz verfügbar.

'''ARM''': 48-Pin/32KB, bis 512K mit internem Flash. Versionen mit internem Cache und externem Speicher sind praktisch beliebig weit ausbaufähig.

'''AVR''': 8-Pin/1KB bis 100-Pin/256KB. Architekturbedingte Grenze bei 8MB Code, 64KB RAM. GCC/WinAVR derzeit nur bis 128KB Code möglich (in Arbeit).

'''MSP430''': 14-Pin DIP/1KB bis 113-Pin BGA/256KB. DIP, SOIC, TSSOP, QFN, TQFP und BGA erhältlich, in DIP und BGA jedoch nur wenige Typen verfügbar. Architekturbedingte Grenze von 64KB für Code+Daten wird in den großen Versionen durch 20-bittige Adressen umschifft. Taktfrequenz: maximal 8, 16 und 18 MHz je nach Familie. 25 MHz-Versionen in Kürze. Stromaufnahme: Rund 2 uA im LPM3 (real time clock mode) bis ca. 5 mA, typisch 200 µA pro MHz.

'''PIC''': 6-Pin/512B aufwärts. Im Prinzip großer Bereich, aber innerhalb der Familie deutlich verschiedene inkompatible Architekturen mit unterschiedlichen architekturbedingen Grenzen und unterschiedlichem Compiler-Support.

'''PIC24''' und '''dsPIC''': 18 bis 100-Pin mit 16 bis 256kB Code und bis zu 16kB RAM. Generell sind alle als TQFP und QFN erhältlich, die 18 und 28 Pin Modelle gibt es auch als SDIP und SSOP und SOIC. Es gibt Modelle mit 16 und 40MHz.

'''ST7:''' 8 bis 80 Pins. SDIP, SOIC, LQFP, TQFP, QFN. 128 bis 2048 Bytes SRAM, 1 bis 60 kBytes Flash.

'''TLCS-870''': 20pin DIP bis 267FBGA. Daneben SDIP, SOIC, SSOP und (L/T)QFP. Relativ wenige Flash-Typen. RAM: 128 Bytes bis 4kB.

'''Z8e''': 8 bis 80 Pins. DIP, SOIC, SSOP, QFP, TQFP, QFN. Bis 64KB Flash. 256 Bytes bis 4 kBytes RAM.

Empfehlung hier: Auch wenn teilweise mehr möglich ist, sind 8/16-Bit-Controller nur bis maximal 40-60K empfehlenswert. Darüber sollte eine 32-Bit-Architektur — z. B. mit [[ARM]]-Core — in Betracht gezogen werden. Insbesondere auch, weil große Programme zu Programm- und Datenstrukturen neigen, die sich auf 8-Bit-Prozessoren schlecht abbilden lassen.

==Interrupt-feste (atomic) Programmierung von I/O-Ports==

Siehe http://www.mikrocontroller.net/articles/Interrupt.

Das ist besonders bei '''AVR''' (ausser den Typen seit 2004: ATtiny2313 usw.) ein Problem. Architekturbedingt ist nur ein Teil der Ports bitweise schaltbar, kein Port kann mehrere Bits gleichzeitig interrupt-fest schalten.

'''PIC''', '''8051''', '''MSP430''', '''R8C/M16C''', '''Z8e''' können AND/OR/XOR zum Port hin, daher ist bei geeigneter Programmierung das Problem auch ohne Abschalten der Interrupts vermeidbar.

Zu '''ARM''' ist dazu keine allgemeine Aussage möglich. Je nach Implementierung wird das Problem teilweise durch entsprechend gestaltete I/O-Ports gelöst, in anderen Fällen ist erhebliche Wachsamkeit geboten. Atmel SAM7 bereitet hier weniger Probleme als Philips LPC2000. Bei den LPC2000 gibt es zwei getrennte Register, eines zum Setzen, das andere zum Löschen einzelner Pins. In einem weiteren Register können Bits ausmaskiert werden. Es gibt also kein read-modify-write. Gut gelöst für Push/Pull-Ausgänge, aber eine äquivalente Steuerung der Richtung wurde vergessen, was Open-Drain Pins erschwert. Implementierungen auf Basis des Cortex M3 oder der ARM Port-Macrocell verwenden statt dessen Adressbits zur Maskierung.

Besonders pfiffig ist das beim '''Z8e''' gelöst. Ein Befehl fasst die nächsten 3 Befehle zu einer nicht unterbrechbaren Einheit zusammen (atomic execution). Allerdings wird das vom Zilog Compiler nicht unterstützt.

==Zugriff auf I/O-Ports==

Der '''8051''' verfügt weder über eigene Register für die Steuerung der Richtung der I/O-Ports, noch über die Möglichkeit, lesend auf den Sollzustand der Ausgänge zuzugreifen. In Assembler ist das kein Problem, da abhängig vom Befehl entweder vom Zustand der Pins (Leseoperationen) oder vom Sollzustand der Ausgänge (kombinierte Lese/Schreiboperationen) ausgegangen wird. Ein korrekt arbeitender C Compiler kann damit jedoch nicht umgehen, weshalb für die Steuerung von Port-Pins spezielle Zugriffsfunktionen und eine sehr genaue Kenntnis der Arbeitsweise der Ports erforderlich sind.

Anmerkung zum Keil 8051-Compiler: Port-Zugriff erfolgt über Pseudo-Variablen wie bei µC üblich. Infolgedessen ist in C Code nicht ersichtlich, ob beispielsweise die Port-Variable P1 für den Zustand der Pins oder den Sollzustand der Ausgänge steht. Nur der erzeugte Assembler-Code kann hier Klarheit schaffen. So haben die beiden prinzipiell identischen Zeilen
<pre>
P1 = P1 | 0x01;
P1 = (P1 | 0x01) & ~0;
</pre>
völlig unterschiedliche Auswirkung auf den Port. Der Code der ersten Zeile setzt Bit 0 und lässt alle anderen Bits unverändert. Der von der zweiten Zeile erzeugte Code setzt zusätzlich auch alle vorher als Eingang definierten Pins im Zustand 0 auf Ausgang mit Zustand 0. Das ist weder hilfreich, noch mit der Sprachdefinition von C vereinbar.

Auch manche Modelle der '''PIC'''-Familie können nur auf den Zustand der Pins zugreifen, nicht auf den Sollzustand der Ausgänge.

In beiden Fällen ist folglich bei Ports, die sowohl für Aus- als auch für Eingänge benutzt werden, besondere Sorgfalt nötig.

'''ARM''', '''AVR''', '''MSP430''', '''Z8e''' und neuere Modelle der '''PIC'''-Familie besitzen diese Probleme nicht.

==Priorisierte Interrupts==

Unter priorisierten Interrupts versteht man die Fähigkeit, den einzelnen Interrupt-Quellen eine Priorität zuweisen zu können um ohne Reprogrammierung der Interrupt-Quellen einen laufenden Interrupt ausschliesslich durch Interrupts höherer Priorität unterbrechbar machen zu können. Die bei separaten Vektoren selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM7/9-Core unterstützt 2 Prioritäten mit entsprechenden Vektoren. Oft ist jedoch ein separater priorisierter und vektorisierter Interrupt-Controller mit integriert (Atmel, NXP, Cortex ja, Analog Devices nein). Interrupt-Nesting ist dank eines Designfehlers etwas umständlich.

ARMv7 aka Cortex-M3: Ein priorisierender Interrupt Controller ist Teil des Cores und Nesting ist problemlos möglich.

'''AVR:''' Nein, aber separate Vektoren für die einzelnen Interrupt-Quellen.

''Anmerkung: Eine weniger wichtiger Interrupt Handler kann oft sofort nach Ansprung ein SEI ausführen, damit ein möglicherweise wichtigerer Interrupt Handler aufgerufen werden kann, weil bei den meisten Interrupts der Request bereits mit dem Aufruf des Handlers automatisch zurück gesetzt wird. Das trifft aber beispielsweise nicht beim TWI zu.''

'''MSP430:''' Nein, aber separate Vektoren für die einzelnen Interrupt-Quellen. Keine Priorisierung im Sinne der Präambel.

'''PIC12 & PIC16:''' Nein, nur ein Interruptvektor. Einfache PIC12 (12F508/509, 16F505) kennen gar keine Interrupts.

'''PIC18:''' Jeder Interruptquelle kann separat eine niedrige oder hohe Priorität zugewiesen werden, die dann auf zwei Interruptvektoren verzweigen. Welche Quelle den Interrupt ausgelöst hat, muss aber immer noch händisch festgestellt werden.

'''PIC17:''' Vier Interruptvektoren mit unterschiedlicher Priorität. Scheint es allerdings nur als OTP zu geben, deswegen wohl eher uninteressant.

'''PIC24''' und '''dsPIC''' haben 7 Prioritäten und für jeden Interrupt einen eigenen Interruptvektor.

'''R8C/M16C''': 7 Prioritäten, vektorisiert.

'''ST7''': Nein. 16 Vektoren mit fixer (absteigender) Priorität.

'''Z8e''': 3 Prioritäten, vektorisiert.

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': Modellabhängig 2-5V problemlos, ältere ab 3V. PICs für 2-4V sind schlecht verfügbar. Ungeregelter Batteriebetrieb möglich.

'''ARM''': 3,3V-Versorgung, je nach Modell mehr oder weniger 5V-kompatibel. Einige (vor allem ältere) Modelle benötigen eine separate 1,8V-Versorgung für den Core. Kein ungeregelter Batteriebetrieb möglich.

'''PIC24''' und '''dsPIC33''': 2-3,6V. Pins die keine analogen Funktionen übernehmen können sind 5V tolerant.

'''MSP430''': nur 1.8-3.6V. Nicht 5V-kompatibel, 5V-Peripherie für I2C/RS485/CAN/... ist also nur mit Pegelkonvertierung einsetzbar. Ungeregelter Batteriebetrieb möglich.

'''ST7''': 2,4-5,5V

'''TLCS-870''': 2,7-5,5V. Serie 870/C 1,8-5,5V.

'''Z8e''': 1,8-3,6V, I/Os 5V-tolerant.

==Programmierung in der Schaltung==

Geräte mit Debugging-Interface (s.U.) lassen sich i.d.R. auch damit programmieren. Siehe dazu nächsten Abschnitt.

Die meisten Controller können sich selbst programmieren, Bootloader per RS232,CAN,usw sind dann problemlos realisierbar. Nur müssen solche Bootloader erst einmal auf den Chip programmiert werden.

'''8051''': Verschieden, je nach Hersteller und Modell. Im Unterschied zu den anderen hier betrachtete Controllern existieren viele nicht in der Schaltung, sondern nur mit speziellen Interfaces programmierbare 8051 Modelle. Modelle mit seriellem Bootloader via UART, SPI, CAN oder USB existieren.

'''ARM''': Am besten über JTAG, je nach Hersteller und Familie auch mit Bootloader, z. B. bei Philips LPC2000 über RS232 und Atmel SAM7 über USB (bei letzterem sehr unbequem und langsam!).

'''AVR''': Über ein an SPI orientiertes proprietäres Interface. Ist via Parallelport günstig herzustellen; der Adapter ist im besten Fall genau 5 Widerstände teuer, professioneller mit einem [[Ausgangsstufen_Logik-ICs#Tri-state|Tri-State]]-Bustreiber etwa 5-15 EUR. Darüberhinaus auch mit HV-Programmer (z. B. auf dem [[STK500]]), der u.U. auch nötig ist um falsch gesetzte Fuses wieder zu "reparieren".

'''MSP430''': Via JTAG-Interface, TI "Spy BiWire" und über integrierten Bootloader. (Schaltung zur Ansteuerung via RS232 im Datenblatt)

'''PIC''': Entweder über die serielle ICSP-Schnittstelle (dafür gibt es Baupläne für billige ParPort-Programmer incl. guter Software) oder mit dem InCircuit-Debugger (~150€, ICD2 von Microchip). Bootloader müssen generell vorher mit einer der vorher genannten Möglichkeiten auf den Chip geflasht werden.

'''R8C''': Via UART (RS-232 oder USB-RS-232 Konverter) mit Flash-Tool (Windows, Linux). Variante über Bootloader ebenfalls möglich (wird vom Software Emulator-Debugger benutzt).

'''ST7''': Via ein mit der Schaltung (mittels mindestens 4poligen Kabels) kommunizieredes Debug-Interface. Offenes ST-Protokoll "ICC".

'''TLCS-870''': Flash-Typen besitzen maskenprogrammierten Bootloader.

'''Z8e''': Via Zilogs Debug-Interface "Smart Cable".

==Debugging in der Schaltung==

Ist beispielsweise ein günstiges [[JTAG]]-Interface für In-Circuit
Debugging verfügbar?

'''8051''': Derivate mit JTAG verfügbar. ICEen gebraucht erschwinglich.

'''ARM''': alle mit JTAG.
* Günstiges Parallel-Port-Interface verfügbar und einfach zu bauen (Wiggler), aber langsam und problematisch im Betrieb unter WinNT+ (besser: ocdremote unter Win9x auf Zweitrechner, via LAN). Kostenlose Debugger ([[GDB]]) unterstützen seit OCDremote 2.14 mit Einschränkungen auch Programme im Flash.
* Schnelles JTAG Interface basierend auf FT2232C für [[GDB]]/OpenOCD günstig und einfach zu bauen (http://www.fh-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html) oder fertig erhältlich (http://www.amontec.com/jtagkey.shtml).
* Kommerzielle Debugger per USB sind besser und schneller, aber recht teuer.

'''AVR''': für ATmega16/162/32/128 ist JTAG günstig verfügbar
(Olimex, Erostech) bzw. einfach zu bauen (Evertool). ATmegas ab 2005/2006 mit JTAG sind zu dieser Billigvariante inkompatibel. Für diese und den [[debugWIRE]] der ATtinys und ATmegaX8 existiert das JTAG ICE mkII von Atmel, aber recht teuer, sowie der preiswerte AVR Dragon.

'''MSP430''': alle mit JTAG, Adapter sehr günstig/einfach zu bauen. Neuere Geräte mit Spy-by-Wire (braucht weniger Pins als JTAG).

'''PIC''': Entweder Microchips MPLAB ICD2 (€150-200) oder ein kompatibler Nachbau, wie z. B. http://www.stolz.de.be/. Alternativ das PICKit 2 für ~40€, dass neben dem Programmieren und Debuggen über USB auch noch als RS232-Brücke und einfacher Logic-Analyzer benutzt werden kann.

'''R8C''': On-Chip Debugging ist mit dem E8 Hardware On-Chip Debugging Emulator möglich (kein JTAG). Ausserdem ist Debugging auch über einen normalen RS232 Anschluss möglich. Der E8 verwendet ein syncrones serielles Protokoll, die RS232 ein asyncrones. Daher ermöglicht der E8 das Debugging bei jeder beliebigen Taktfrequenz, bei RS232 gibt es da Einschränkungen.

'''ST7''': Via ein mit der Schaltung (mittels mindestens 4poligen Kabels) kommunizieredes Debug-Interface. Offenes ST-Protokoll "ICC".

'''Z8e''': Debugging möglich mit "Smart Cable" (kein JTAG), Anschluss über USB oder seriell Schnittstelle

==Starterkits==

'''8051''': Keil MCBx51 http://www.keil.com/mcbx51 (z. B. für ~240€ von [http://de.mouser.com/Search/Refine.aspx?Keyword=830-MCBX51 mouser.com])

'''ARM''': http://www.olimex.com (z.T. hier im Shop erhältlich), http://www.embeddedartists.com,
http://www.mct.de

'''AVR''': [[STK200]], [[STK500]], [[AVR_Butterfly]]

'''MSP430''': http://www.olimex.com (z.T. hier im Shop erhältlich), ez430 (http://www.ti.com/ez430)

'''PIC''': http://www.microchipdirect.com/ , Velleman-Kit K8048 (www.velleman.be)

'''R8C''': Mehrere (Google Suche). Am weitesten verbreitet ist vielleicht das R8C/13 Starterkit inkl. Entwickler-CD von Glyn/Elektor (Beilage Elektor 12/2005 (ausverkauft) bzw. diverse Drittanbieter).

'''Z8e''': Günstig verfügbar [~50€], teils hier im Shop, komplett inklusive unbeschränktem Compiler und In-System-Debugging. Nachteile: für jede Prozessorklasse ein eigenes Kit; eingelöteter SMD-Chip obwohl viele Typen auch im DIL-Gehäuse existieren.

==Gehäuse==

Mit DIP oder PLCC bastelt es sich leichter als mit *QFP. Die Domäne von
AVR/PIC/i51. Für MSP430 gibt es günstige fertig bestückte DIP-Adapter hier im Shop (MSP430x2xx gibt es auch in 14-Pin DIP-Gehäuse). Z8e-Chips existieren ebenfalls in DIP, sind aber schlechter verfügbar.

==Beschaltungsaufwand==

'''8051, AVR, PIC, MSP430, R8C, ST7, Z8e''': gering, i.d.R. sind Versionen mit integriertem Oszillator verfügbar, so dass man praktisch nur die Versorgungsspannung (nebst Abblockkondensator) braucht.

'''ARM''': aufwendigere externe Takt- und Spannungserzeugung, manchmal 2 Betriebsspannungen benötigt; Tendenz aber fallend.

==Links==

* [http://www.mikrocontroller.net/forum/read-1-185133.html#new Forum]
* [[8051]]
* [[ARM]]
* [[AVR]]
* [[MSP430]]
* [[PIC]]
* [[R8C]]
* [[ST7]]
* [[Z8]]
* [[Z8_encore!]]

[[Category:Mikrocontroller]]