Mikrocontroller.net - Benutzerbeiträge [de]

AVR-GCC-Tutorial/Der UART

2010-09-29T20:05:46Z

134.76.63.190: /* UART initialisieren */

Über den [[UART]] kann ein [[AVR]] leicht mit einer [[RS-232]]-Schnittstelle eines PC oder sonstiger Geräte mit "[[seriell]]er Schnittstelle" verbunden werden.

== Allgemeines zum UART ==

Mögliche Anwendungen des UART:

;Debug-Schnittstelle: z. B. zur Anzeige von Zwischenergebnissen ("printf-debugging" - hier besser "Logging" oder "UART-debugging") auf einem PC. Auf dem Rechner reicht dazu ein [[RS-232#Terminalprogramme|Terminalprogramm]] (MS-Windows: Hyperterm oder besser [https://sites.google.com/site/terminalbpp/], [http://www.der-hammer.info/terminal/ HTerm]; Unix/Linux z. B. minicom). Ein direkter Anschluss ist aufgrund unterschiedlicher Pegel nicht möglich, jedoch sind entsprechende Schnittstellen-ICs wie z. B. ein MAX232 günstig und leicht zu integrieren. Rechner ohne serielle Schnittstelle können über fertige USB-seriell-Adapter angeschlossen werden.
;Mensch-Maschine Schnittstelle: z. B. Konfiguration und Statusabfrage über eine "Kommandozeile" oder Menüs (siehe z. B. Forumsbeitrag [http://www.mikrocontroller.net/topic/52985 Auswertung RS232-Befehle] und Artikel [[Tinykon]])
;Übertragen von gespeicherten Werten: z. B. bei einem Datenlogger
;Anschluss von Geräten: mit serieller Schnittstelle (z. B. (Funk-)Modems, Mobiltelefone, Drucker, Sensoren, "intelligente" LC-Displays, GPS-Empfänger).
;"Feldbusse": auf RS485/RS422-Basis mittels entsprechenden Bustreiberbausteinen (z. B. MAX485)
;DMX, Midi: etc.
;LIN-Bus: '''L'''ocal '''I'''nterconnect '''N'''etwork: Preiswerte Sensoren/Aktoren in der Automobiltechnik und darüber hinaus

Einige AVR-Controller haben ein bis zwei vollduplexfähigen UART ('''U'''niversal '''A'''synchronous '''R'''eceiver and '''T'''ransmitter) schon eingebaut ("Hardware-UART").
Übrigens: Vollduplex heißt nichts anderes, als dass der Baustein gleichzeitig senden und empfangen kann.

Neuere AVRs (ATmega, ATtiny) verfügen über einen oder zwei U'''S'''ART(s), dieser unterscheidet sich vom UART hauptsächlich durch interne FIFO-Puffer für Ein- und Ausgabe und erweiterte Konfigurationsmöglichkeiten. Die Puffergröße ist allerdings nur 1 Byte.

Der UART wird über vier separate Register angesprochen. USARTs der ATMEGAs verfügen über mehrere zusätzliche Konfigurationsregister. Das Datenblatt gibt darüber Auskunft. Die Folgende Tabelle gibt nur die Register für die UARTs der ATmega8/16/32 u.ä. wieder.

{| class="wikitable"
|-
| '''UCSRA   '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''A'''. 
Hier teilt uns der UART mit, was er gerade so macht.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''RXC'''|| '''TXC'''|| '''UDRE'''|| '''FE'''|| '''DOR'''|| '''PE'''|| '''U2X'''|| '''MPCM'''
|-
! R/W
| R|| R/W|| R|| R|| R|| R|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| 1|| 0|| 0|| 0|| 0|| 0
|}

'''RXC''' (UART Receive Complete)
:Dieses Bit wird vom AVR gesetzt, wenn ein empfangenes Zeichen vom Empfangs-Schieberegister in das Empfangs-Datenregister transferiert wurde.
:Das Zeichen muss nun schnellstmöglich aus dem Datenregister ausgelesen werden. Falls dies nicht erfolgt bevor ein weiteres Zeichen komplett empfangen wurde wird eine Überlauf-Fehlersituation eintreffen. Mit dem Auslesen des Datenregisters wird das Bit automatisch gelöscht.

'''TXC''' (UART Transmit Complete)
:Dieses Bit wird vom AVR gesetzt, wenn das im Sende-Schieberegister befindliche Zeichen vollständig ausgegeben wurde und kein weiteres Zeichen im Sendedatenregister ansteht. Dies bedeutet also, wenn die Kommunikation vollumfänglich abgeschlossen ist.
:Dieses Bit ist wichtig bei Halbduplex-Verbindungen, wenn das Programm nach dem Senden von Daten auf Empfang schalten muss. Im Vollduplexbetrieb brauchen wir dieses Bit nicht zu beachten.
:Das Bit wird nur dann automatisch gelöscht, wenn der entsprechende Interrupthandler aufgerufen wird, ansonsten müssen wir das Bit selber löschen.

'''UDRE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty)
:Dieses Bit zeigt an, ob der Sendepuffer bereit ist, um ein zu sendendes Zeichen aufzunehmen. Das Bit wird vom AVR gesetzt (1), wenn der Sendepuffer leer ist. Es wird gelöscht (0), wenn ein Zeichen im Sendedatenregister vorhanden ist und noch nicht in das Sendeschieberegister übernommen wurde. Atmel empfiehlt aus Kompatibilitätsgründen mit kommenden µC, UDRE auf 0 zu setzen, wenn das UCSRA Register beschrieben wird.
:Das Bit wird automatisch gelöscht, wenn ein Zeichen in das Sendedatenregister geschrieben wird.

'''FE''' ('''F'''raming '''E'''rror)
:Dieses Bit wird vom AVR gesetzt, wenn der UART einen Zeichenrahmenfehler detektiert, d.h. wenn das Stopbit eines empfangenen Zeichens 0 ist.
:Das Bit wird automatisch gelöscht, wenn das Stopbit des empfangenen Zeichens 1 ist.

'''DOR''' ('''D'''ata '''O'''ver '''R'''un)
:Dieses Bit wird vom AVR gesetzt, wenn unser Programm das im Empfangsdatenregister bereit liegende Zeichen nicht abholt bevor das nachfolgende Zeichen komplett empfangen wurde.
:Das nachfolgende Zeichen wird verworfen.
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.

'''PE''' ('''P'''arity '''E'''rror''')
:Dieses Bit wird vom AVR gesetzt, wenn das im Empfangsdatenregister bereit liegende Zeichen eine Paritätsfehler aufweist.
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.

'''U2X''' (Double the transmission speed)
:Dieses Bit wird lediglich im asynchronen Modus genutzt. Im synchronen Modus ist es 0 zu setzen. Wird das Bit gesetzt, so wird der Baudraten Divisor von 16 auf 8 reduziert, was einer Verdopplung der Transferrate gleich kommt.

'''MPCM''' ('''M'''ulti '''P'''rozessor '''C'''ommunication '''M'''ode)
:Dieses Bit aktiviert die Multi-Prozessor-Kommunikation. Jeder eintreffende Frame der keine Adressinformation enthält wird dadurch irgnoriert.

|-
| '''UCSRB    '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''B'''. 
In diesem Register stellen wir ein, wie wir den UART verwenden möchten. 
Das Register ist wie folgt aufgebaut:

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''RXCIE'''|| '''TXCIE'''|| '''UDRIE'''|| '''RXEN'''|| '''TXEN'''|| '''UCSZ2'''|| '''RXB8'''|| '''TXB8'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R|| R/W
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''RXCIE''' ('''RX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART RX Complete Interrupt ausgelöst, wenn ein Zeichen vom UART empfangen wurde. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''TXCIE''' ('''TX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART TX Complete Interrupt ausgelöst, wenn ein Zeichen vom UART gesendet wurde. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''UDRIE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART Datenregister Leer Interrupt ausgelöst, wenn der UART wieder bereit ist um ein neues zu sendendes Zeichen zu übernehmen. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''RXEN''' ('''R'''eceiver '''E'''nable)
:Nur wenn dieses Bit gesetzt ist, arbeitet der Empfänger des UART überhaupt. Wenn das Bit nicht gesetzt ist, kann der entsprechende Pin des AVR als normaler I/O-Pin verwendet werden.

'''TXEN''' ('''T'''ransmitter '''E'''nable)
:Nur wenn dieses Bit gesetzt ist, arbeitet der Sender des UART überhaupt. Wenn das Bit nicht gesetzt ist, kann der entsprechende Pin des AVR als normaler I/O-Pin verwendet werden.

'''UCSZ2''' (Characters Size)
:Dieses Bit setzt in Verbindung mit dem UCSZ1:0 Bits im UCSRC Register die Anzahl von Datenbits eines Frames beim Empfang oder Senden.

'''RXB8''' (Receive Data Bit 8)
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann enthält dieses Bit das 9. Datenbit eines empfangenen Zeichens.

'''TXB8''' (Transmit Data Bit 8)
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann muss in dieses Bit das 9. Bit des zu sendenden Zeichens eingeschrieben werden bevor das eigentliche Datenbyte in das Datenregister geschrieben wird.
|-
| '''UCSRC    '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''C'''. 

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''URSEL'''|| '''UMSEL'''|| '''UPM1'''|| '''UPM0'''|| '''USBS'''|| '''UCSZ1'''|| '''UCSZ0'''|| '''UCPOL'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W
|-
! Initialwert
| 1|| 0|| 0|| 0|| 0|| 1|| 1|| 0
|}

'''URSEL''' (Register Select)
:Dieses Bit selektiert die Auswahl des UCSRC bzw. des UBRRH Registers. Beim lesen von UCSRC wird es als 1 gelesen. Beim schreiben auf UCSRC muss es auf 1 gesetzt werden.

'''UMSEL''' (USART Mode Select)
:Durch dieses Bit kann eine asynchroner- oder synchroner Übertragung eingestellt werden. Durch setzten des Bits wird eine synchrone Übertragung eingestellt.

'''UPM1:0''' (Parity Mode)
{| class="wikitable" style="text-align:center"
|-
| '''UPM1'''|| '''UPM0'''|| '''Parity Mode'''
|-
| 0|| 0|| Disabled
|-
| 0|| 1|| Reserved
|-
| 1|| 0|| Enabled, Even Priority
|-
| 1|| 1|| Enabled, OddPriority
|}

'''USBS''' ('''U'''SART '''S'''top '''B'''it '''S'''elect)
:Diese Bits setzen die Anzahl der zu sendenden Stopp-Bits eines Frames. Beim Setzen werden 2 Stopp-Bits übertragen, anderenfalls nur 1 Stopp-Bit.
{| class="wikitable" style="text-align:center"
|-
| '''USBS'''|| '''Anzahl der Stop Bits'''
|-
| 0|| 1
|-
| 1|| 2

|}

'''UCSZ1:0''' (Character Size)
:Diese Bits setzten in Verbindung mit UCSZ2 aus dem UCSRB Register die Anzahl der Datenbits eines Frames.
:Diese Bits setzten den entsprechenden Paritätsmodus.
{| class="wikitable" style="text-align:center"
|-
| '''UCSZ2'''|| '''UCSZ1'''|| '''UCSZ0'''|| '''Character Size'''
|-
| 0|| 0|| 0|| 5-Bit
|-
| 0|| 0|| 1|| 6-Bit
|-
| 0|| 1|| 0|| 7-Bit
|-
| 0|| 1|| 1|| 8-Bit
|-
| 1|| 0|| 0|| Reserved
|-
| 1|| 0|| 1|| Reserved
|-
| 1|| 1|| 0|| Reserved
|-
| 1|| 1|| 1|| 9-Bit
|}

'''UCPOL''' (Clock Polarity)

|-
| '''UDR'''
| '''U'''ART '''D'''ata '''R'''egister. 
Hier werden Daten zwischen UART und CPU übertragen. Da der UART im
Vollduplexbetrieb gleichzeitig empfangen und senden kann, handelt es sich
hier physikalisch um 2 Register, die aber über die gleiche I/O-Adresse
angesprochen werden. Je nachdem, ob ein Lese- oder ein Schreibzugriff auf
den UART erfolgt wird automatisch das richtige UDR angesprochen.
|-
| '''UBRR'''
| '''U'''ART '''B'''aud '''R'''ate '''R'''egister. 
In diesem Register müssen wir dem UART mitteilen, wie schnell wir gerne
kommunizieren möchten. Der Wert, der in dieses Register geschrieben
werden muss, errechnet sich nach folgender Formel:

:<math>
\mathrm{UBRR} = \frac{\mathrm{Taktfrequenz}}{\mathrm{Baudrate} \cdot 16} - 1
</math>

Es sind Baudraten bis zu 115200 Baud und höher möglich.
|}

== Die Hardware ==

Der UART basiert auf normalem TTL-Pegel mit 0V (logisch 0) und 5V (logisch 1). Die
Schnittstellenspezifikation für RS-232 definiert jedoch -3V ... -12V (logisch 1) und
+3 ... +12V (logisch 0). Daher muss der Signalaustausch zwischen AVR und
Partnergerät invertiert werden. Für die Anpassung der Pegel und das
Invertieren der Signale gibt es fertige Schnittstellenbausteine. Der bekannteste
davon ist wohl der MAX232.


Streikt die Kommunikation per UART, so ist oft eine fehlerhafte Einstellung der Baudrate die Ursache. Die Konfiguration auf eine bestimmte Baudrate ist abhängig von der Taktfrequenz des Controllers. Gerade bei neu aufgebauten Schaltungen (bzw. neu gekauften Controllern) sollte man sich daher noch einmal vergewissern, dass der Controller auch tatsächlich mit der vermuteten Taktrate arbeitet und nicht z. B. den bei einigen Modellen werksseitig eingestellten internen [[Oszillator]] statt eines externen Quarzes nutzt. Die Werte der verschiedenen fuse-bits im Fehlerfall also beispielsweise mit ''[[AVRDUDE]]'' kontrollieren und falls nötig anpassen. Grundsätzlich empfiehlt sich auch immer ein Blick in die [[AVR_Checkliste]].

== UART initialisieren ==

Wir wollen nun Daten mit dem UART auf die serielle Schnittstelle ausgeben. Dazu müssen wir den UART zuerst mal initialisieren. Dazu setzen wir je nach gewünschter Funktionsweise die benötigten Bits im '''U'''ART '''C'''ontrol '''R'''egister.

Da wir vorerst nur senden möchten und noch keine Interrupts auswerten wollen, gestaltet sich die Initialisierung wirklich sehr einfach, da wir lediglich das '''Transmitter Enable''' Bit setzen müssen:

<c>
UCSRB |= (1<<TXEN);
</c>

Neuere AVRs mit USART haben mehrere Konfigurationsregister und erfordern eine etwas andere Konfiguration. Für einen ATmega16 z. B.:

<c>
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC |= (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0); // Asynchron 8N1
</c>

Nun ist noch das Baudratenregister '''UBRR''' einzustellen. Bei neueren AVRs besteht es aus zwei Registern '''UBRRL''' und '''UBRRH'''. Der Wert dafür ergibt sich aus der angegebenen Formel durch Einsetzen der Taktfrequenz und der gewünschten Übertragungsrate. Das Berechnen der Formel wird dem [[C-Präprozessor|Präprozessor]] überlassen. Dabei ist zu beachten, dass der Präprozessor keine Floating Point Ergebnisse liefert, sondern Integer Ergebnisse. Das bedeutet, dass wenn durch Division auf einen Integer Wert 1.99 zugewiesen wird, 0.99 abgeschnitten werden und das Ergebnis 1.0 ist - obwohl 2.0 viel näher wäre. Aus diesem Grund kann man sich einem kleinen Trick bedienen, indem vor der eigentlichen Division bei der Zuweisung die Hälfte des Wertes dazu addiert wird. Allgemein formuliert bedeutet das: <c>int i = ( a + b/2 ) / b;</c> Dies wird in der unten angegebenen Berechnung von UBRR_VAL ausgenutzt um den Fehler zu minimieren.

Eine ausführliche Erklärung zum ''cleveren Runden'' findet sich in der Forumsdiskussion [http://www.mikrocontroller.net/topic/170617#1631916].

<c>
/*
UART-Init:
Berechnung des Wertes für das Baudratenregister
aus Taktrate und gewünschter Baudrate
*/

#ifndef F_CPU
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann
F_CPU im Makefile definiert werden, eine nochmalige Definition
hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
#ifndef/#endif

Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio
verwendet wird und dort eine andere, nicht zur Hardware passende
Taktrate eingestellt ist: Dann wird die folgende Definition
nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?)
von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
noch nicht definiert: */
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
#define F_CPU 4000000UL // Systemtakt in Hz - Definition als unsigned long beachten
// Ohne ergeben sich unten Fehler in der Berechnung
#endif

#define BAUD 9600UL // Baudrate

// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif
</c>

Die Makros sind sehr praktisch, da sie sowohl automatisch den Wert für UBRR als auch den Fehler in der generierten Baudrate berechnen und im Falle einer Überschreitung (+/-1%) einen Fehler und somit Abbruch im Compilerablauf generieren. Damit können viele Probleme mit "UART sendet komische Zeichen" vermieden werden. Ausserdem kann man mühelos die Einstellung an eine neue Taktfrequenz bzw. Baudrate anpassen, ohne selber rechnen oder in Tabellen nachschlagen zu müssen.

Inzwischen gibt es in der avr-libc Makros für obige Berechnung der UBRR Registerwerte aus Taktrate F_CPU und Baudrate BAUD in der Includedatei <util/setbaud.h> ([http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html]).

Die eigentliche Initialisierung der UART Register kann im Hauptprogramm main() vorgenommen werden. Öfters wird jedoch eine Funktion z. B. uart_init() dafür geschrieben, die in der eigenen Codesammlung in mehreren Projekten verwendet werden kann.

Für einige AVR (z. B. ATmega169, ATmega48/88/168, AT90CAN jedoch nicht für z. B. ATmega16/32, ATmega128, ATtiny2313) wird durch die Registerdefinitionen der avr-libc (io*.h) auch für Controller mit zwei UBRR-Registern (UBRRL/UBRRH) ein UBRR bzw. UBRR0 als "16-bit-Register" definiert und man kann den Wert direkt per UBRR = UBRR_VAL zuweisen. Intern werden dann zwei Zuweisungen für UBRRH und UBRRL generiert.

<c>
/* UART-Init Bsp. ATmega48 */

void uart_init(void)
{
UBRR0 = UBRR_VALUE;
UCSR0B |= (1<<TXEN0);
// Frame Format: Asynchron 8N1
UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
}
</c>

Die einzelne Anweisung ist nicht bei allen Controllern möglich, da die beiden Register nicht bei allen aufeinanderfolgende Addressen aufweisen. Die getrennte Zuweisung an UBRRH und UBRRL wie im nächsten Beispiel gezeigt, ist universeller und portabler und daher vorzuziehen. Wichtig ist, dass UBRRH '''vor''' UBRRL geschrieben wird:

<c>
/* UART-Init Bsp. ATmega16 */

void uart_init(void)
{
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC |= (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1

UBRRH = UBRR_VALUE >> 8;
UBRRL = UBRR_VALUE & 0xFF;
}
</c>

Siehe auch:
* [http://www.wormfood.net/avrbaudcalc.php WormFood's AVR Baud Rate Calculator] online.
* [http://www.gjlay.de/helferlein/avr-uart-rechner.html AVR Baudraten-Rechner] in JavaScript

== Senden mit dem UART ==

=== Senden einzelner Zeichen ===

Um nun ein Zeichen auf die Schnittstelle auszugeben, müssen wir dasselbe
lediglich in das '''U'''ART '''D'''ata '''R'''egister schreiben. Vorher ist zu prüfen, ob das UART-Modul bereit ist, das zu sendende Zeichen entgegenzunehmen. Die Bezeichnungen des/der Statusregisters mit dem Bit UDRE ist abhängig vom Controllertypen (vgl. Datenblatt).

<c>
// bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z. B. fuer ATmega16:
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */
</c>

=== Schreiben einer Zeichenkette (String) ===

Die Aufgabe "String senden" wird durch zwei Funktionen abgearbeitet. Die universelle/controllerunabhängige Funktion uart_puts übergibt jeweils ein Zeichen der Zeichenkette an eine Funktion uart_putc, die abhängig von der vorhandenen Hardware implementiert werden muss. In der Funktion zum Senden eines Zeichens ist darauf zu achten, dass vor dem Senden geprüft wird, ob der UART bereit ist den "Sendeauftrag" entgegenzunehmen.

<c>
/* ATmega16 */
int uart_putc(unsigned char c)
{
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = c; /* sende Zeichen */
return 0;
}

/* puts ist unabhaengig vom Controllertyp */
void uart_puts (char *s)
{
while (*s)
{ /* so lange *s != '\0' also ungleich dem "String-Endezeichen" */
uart_putc(*s);
s++;
}
}
</c>

Die in uart_putc verwendeten Schleifen, in denen gewartet wird bis die UART-Hardware zum senden bereit ist, sind insofern etwas kritisch, da während des Sendens eines Strings nicht mehr auf andere Ereignisse reagiert werden kann. Universeller ist die Nutzung von FIFO(first-in first-out)-Puffern, in denen die zu sendenden bzw. empfangenen Zeichen/Bytes zwischengespeichert und in Interruptroutinen an die U(S)ART-Hardware weitergegeben bzw. von ihr ausgelesen werden. Dazu existieren fertige Komponenten (Bibliotheken, Libraries), die man recht einfach in eigene Entwicklungen integrieren kann. Es empfiehlt sich, diese Komponenten zu nutzen und das Rad nicht neu zu erfinden.

=== Schreiben von Variableninhalten ===

Sollen Inhalte von Variablen (Ganzzahlen, Gleitkomma) in "menschenlesbarer" Form gesendet werden, ist vor dem Transfer eine Umwandlung in Zeichen ("ASCII") erforderlich. Bei nur einer Ziffer ist diese Umwandlung relativ einfach: man addiert den ASCII-Wert von Null zur Ziffer und kann diesen Wert direkt senden.

<c>
#include <stdlib.h>
//...

// hier uart_putc (s.o.)

int main (void)
{
// Ausgabe von 0123456789
char c;

for (uint8_t i=0; i<=9; ++i) {
c = i + '0';
uart_putc( c );
// verkuerzt: uart_putc( i + '0' );
}

while (1) {
;
}

return 0; // never reached

}
</c>

Soll mehr als eine Ziffer ausgegeben werden, bedient man sich zweckmäßigerweise vorhandener Funktionen zur Umwandlung von Zahlen in Zeichenketten/Strings. Die Funktion der avr-libc zur Umwandlung von vorzeichenbehafteten 16bit-Ganzzahlen (int16_t) in Zeichenketten heißt ''itoa'' (Integer to ASCII). Man muss der Funktion einen Speicherbereich zur Verarbeitung (buffer) mit Platz für alle Ziffern, das String-Endezeichen ('\0') und evtl. das Vorzeichen bereitstellen.

<c>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

int main(void)
{
char s[7];
int16_t i = -12345;

uart_init();

itoa( i, s, 10 ); // 10 fuer radix -> Dezimalsystem
uart_puts( s );

// da itoa einen Zeiger auf den Beginn von s zurueckgibt verkuerzt auch:
uart_puts( itoa( i, s, 10 ) );

while (1) {
;
}

return 0; // never reached
}
</c>

Für vorzeichenlose 16bit-Ganzzahlen (uint16_t) exisitert ''utoa''. Die Funktionen für 32bit-Ganzzahlen (int32_t und uint32_t) heißen ''ltoa'' bzw. ''ultoa''. Da 32bit-Ganzzahlen mehr Stellen aufweisen können, ist ein entsprechend größerer Pufferspeicher vorzusehen.

Auch Gleitkommazahlen (float/double) können mit bereits vorhandenen Funktionen in Zeichenfolgen umgewandelt werden, dazu existieren die Funktionen ''dtostre'' und ''dtostrf''. dtostre nutzt Exponentialschreibweise ("engineering"-Format). (Hinweis: z.Zt. existiert im avr-gcc kein "echtes" double, intern wird immer mit "einfacher Genauigkeit", entsprechend float, gerechnet.)

dtostrf und dtostre benötigen die libm.a der avr-libc. Bei Nutzung von Makefiles ist der Parameter -lm in in LDFLAGS anzugeben (Standard in den WinAVR/mfile-Makefilevorlagen). Nutzt man AVRStudio als IDE für den GNU-Compiler (gcc-Plugin) ist die libm.a unter Libaries auszuwählen: Project -> Configurations Options -> Libaries -> libm.a mit dem Pfeil nach rechts einbinden. Siehe auch die [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|FAQ]]

<c>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

/* lt. avr-libc Dokumentation:
char* dtostrf(
double __val,
char __width,
char __prec,
char * __s
)
*/

int main(void)
{
// Pufferspeicher ausreichend groß
// evtl. Vorzeichen + width + Endezeichen:
char s[8];
float f = -12.345;

uart_init();

dtostrf( f, 6, 3, s );
uart_puts( s );
// verkürzt: uart_puts( dtostrf( f, 7, 3, s ) );

while (1) {
;
}

return 0; // never reached
}
</c>

== Empfangen ==
=== einzelne Zeichen empfangen ===

Zum Empfang von Zeichen muss der Empfangsteil des UART bei der Initialisierung aktiviert werden, indem das RXEN-Bit im jeweiligen Konfigurationsregister (UCSRB bzw UCSR0B/UCSR1B) gesetzt wird. Im einfachsten Fall wird solange gewartet, bis ein Zeichen empfangen wurde, dieses steht dann im UART-Datenregister (UDR bzw. UDR0 und UDR1 bei AVRs mit 2 UARTS) zur Verfügung (sogen. "Polling-Betrieb"). Ein Beispiel für den ATmega16:

<c>
#include <inttypes.h>
#include <avr/io.h>

/* Siehe auch obere Baudrateneinstellung */
/* USART-Init beim ATmega16 */

void uart_init(void)
{
UCSRB |= (1<<RXEN); // UART RX einschalten
UCSRC |= (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1

UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
}

/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}
</c>

Diese Funktion blockiert den Programmablauf. Alternativ kann das RXC-Bit in einer Programmschleife abgefragt werden und dann nur bei gesetztem RXC-Bit UDR ausgelesen werden. Eleganter und in den meisten Anwendungsfällen "stabiler" ist die Vorgehensweise, die empfangenen Zeichen in einer Interrupt-Routine einzulesen und zur späteren Verarbeitung in einem Eingangsbuffer (FIFO-Buffer) zwischenzuspeichern. Dazu existieren fertige und gut getestete [[Libraries|Bibliotheken]]  und Quellcodekomponenten (z. B. UART-Library von P. Fleury, procyon-avrlib und einige in der "Academy" von avrfreaks.net).

siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html Dokumenation der avr-libc/stdlib.h]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Die_Nutzung_von_printf Die Nutzung von printf]
* [http://homepage.hispeed.ch/peterfleury/ Peter Fleurys] UART-Bibiliothek fuer avr-gcc/avr-libc


TODO: 9bit

=== Empfang von Zeichenketten (Strings) ===

Beim Empfang von Zeichenketten, muß man sich zunächst darüber im klaren sein, daß es ein Kriterium geben muß, an dem der µC erkennen kann, wann ein Text zu Ende ist. Sehr oft wird dazu das Zeichen 'Return' benutzt, um das Ende eines Textes zu markieren. Dies ist vom Benutzer einfach eingebbar und er ist auch daran gewöhnt, daß er eine Eingabezeile mit einem Druck auf die Return Taste abgeschlossen wird.

Prinzipiell gibt es jedoch keine Einschränkung bezüglich dieses speziellen Zeichens. Es muß nur sichergestellt werden, daß dieses spezielle 'Ende eines Strings' - Zeichen nicht mit einem im Text vorkommenden Zeichen verwechselt werden kann. Wenn also im zu übertragenden Text beispielsweise kein ';' vorkommt, dann spricht nichts dagegen, den Benutzer die Eingabe eines Textes mit einem ';' abschließen zu lassen.

Im Folgenden wird die durchaus übliche Annahme getroffen, daß eine Stringübertragung identisch ist mit der Übertragung einer Textzeile und daher mit einem Return ('\n') abgeschlossen wird.

Das Problem der Übertragung eines Strings reduziert sich damit auf die Aufgabenstellung: Empfange und sammle Zeichen in einem char Array, bis entweder das Array voll ist oder das Text Ende Zeichen' empfangen wurde. Danach wird der empfangene Text noch mit einem '\0' Zeichen abgeschlossen um einen Standard C-String daraus zu machen, mit dem dann weiter gearbeitet werden kann.

<C>
/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}

void uart_gets( char* Buffer, uint8_t MaxLen )
{
uint8_t NextChar;
uint8_t StringLen = 0;

NextChar = uart_getc(); // Warte auf und empfange das nächste Zeichen

// Sammle solange Zeichen, bis:
// * entweder das String Ende Zeichen kam
// * oder das aufnehmende Array voll ist
while( NextChar != '\n' && StringLen < MaxLen - 1 ) {
*Buffer++ = NextChar;
StringLen++;
NextChar = uart_getc();
}

// Noch ein '\0' anhängen um einen Standard
// C-String daraus zu machen
*Buffer = '\0';
}
</C>

Beim Aufruf ist darauf zu achten, dass das empfangende Array auch mit einer
vernünftigen Größe definiert wird.

<C>

char Line[40]; // String mit maximal 39 zeichen

uart_gets( Line, sizeof( Line ) );
</C>

Bei der Benutzung von sizeof() ist allerdings zu beachten, dass sizeof() nicht die Anzahl der Elemente des Arrays liefert, sondern die Länge in Byte. Da ein char nur ein Byte lang ist, passt der Aufruf 'uart_gets(Line, sizeof( Line ) );' in diesem Fall. Falls man - aus welchen Gründen auch immer - andere Datentypen benutzen möchte, sollte man zur korrekten Angabe der Array-Länge folgende Vorgehensweise bevorzugen:

<C>
int Line[40]; // Array vom Typ int

uart_gets( Line, sizeof( Line ) / sizeof( Line[0] ) );
</C>

==Interruptbetrieb==

Beim ATMEGA8 muss das RXCIE Bit im Register UCSRB gesetzt werden, damit ein Interrupt ausgelöst werden kann.
<c>
/* siehe auch obere Baudrateneinstellung */
/* USART-Init beim ATmega16 */
void uart_init(void)
{
UCSRB |= (1<<RXEN)|(1<<TXEN)|(1<<RXCIE); // UART RX, TX und RX Interrupt einschalten
UCSRC |= (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1

UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
}
</c>
Der Interrupt wird immer ausgelöst, wenn ein Zeichen erfolgreich empfangen wurde. Zudem werden ein paar globale Variablen und defines benötigt:
<c>
#define UART_MAXSTRLEN 10

volatile uint8_t uart_str_complete = 0; // 1 .. String komplett empfangen
volatile uint8_t uart_str_count = 0;
volatile char uart_string[UART_MAXSTRLEN + 1] = "";
</c>

Zusätzlich braucht man die Interrupt-Routine:

<c>
ISR(USART_RXC_vect)
{
unsigned char nextChar;

// Daten aus dem Puffer lesen
nextChar = UDR;
if( uart_str_complete == 0 ) { // wenn uart_string gerade in Verwendung, neues Zeichen verwerfen

// Daten werden erst in string geschrieben, wenn nicht String-Ende/max Zeichenlänge erreicht ist/string gerade verarbeitet wird
if( nextChar != '\n' &&
nextChar != '\r' &&
uart_str_count < UART_MAXSTRLEN - 1 ) {
uart_string[uart_str_count] = nextChar;
uart_str_count++;
}
else {
uart_string[uart_str_count] = '\0';
uart_str_count = 0;
uart_str_complete = 1;
}
}
}
</c>

natürlich muss "Global Interrupt Enable" aktiviert sein ( sei() ).
!! Nur getestet beim ATMEGA8 !!

Wurde eine komplette Zeichenkette empfangen, also das Ende (\n oder \r) erkannt oder die maximale Länge uart_maxstrlen erreicht, wird die globale Variable uart_str_complete auf '1' gesetzt. Damit wird dem Hauptprogramm, welches auf diese Variable pollt, mitgeteil, dass die Zeichenkette uart_string zur Verarbeitung bereit steht. Nach der Verarbeitung der Zeichenkette in der entsprechenden main-Routine, muss die Variable uart_str_complete wieder auf '0' gesetzt werden. Dadurch werden alle neu empfangenen Zeichen wieder in den globalen Puffer geschrieben.

[BAUSTELLE! Aus Lerngründen eventuell als eigenen UART-Interrupt-Block hinter den grundlegenden Interrupt-Teil im Tutorial und hier eine kurze Einführung und einen Verweis darauf anbieten.]

* Unterschied Polling-Betrieb (bisher, oben) und Interrupt-Betrieb
* Empfangen (Receive)
** Verändertes UART-Init, ISR (RXC), ggf. Fallstricke ([http://www.mikrocontroller.net/topic/84256#707214 UDR in der ISR lesen!]), Philosophie einer ISR (kurz und schmerzlos), Datenaustausch ISR zu Restprogramm (volatile)
** Einfachstbeispiel ([http://www.mikrocontroller.net/topic/84228#707052 Echo] (noch buggy beim Datenzugriff, siehe Lit. 2+3!)), ggf. LED zur ISR-Empfangsanzeige oder Overflow-Anzeige
* FIFO-Puffer, Ringpuffer
* Senden (Transmit)
** Variante "UART Data Register Empty" (UDRE)
** Variante "UART Transmit Complete" (TXC)
* Fertige UART-Bibliotheken (->Fleury, ->Procyon)
* Literatur:
** 1/ [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48188 avrfreaks.net Tutorial] inkl. Diskussion (engl.)
** 2/ avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_16bitio Why do some 16-bit timer registers sometimes get trashed?]
** 3/ [[Interrupt]] und atomarer Datenzugriff

==Software-UART==

Falls die Zahl der vorhandenen Hardware-UARTs nicht ausreicht, können weitere Schnittstellen über sogennante Software-UARTs ergänzt werden. Es gibt dazu (mindestens) zwei Ansätze:
* Der bei AVRs üblichste Ansatz basiert auf dem Prinzip, dass ein externer Interrupt-Pin für den Empfang ("RX") genutzt wird. Das Startbit löst den Interrupt aus, in der Interrupt-Routine (ISR) wird der externe Interrupt deaktiviert und ein Timer aktiviert. In der Interrupt-Routine des Timers wird der Zustand des Empfangs-Pins entsprechend der Baudrate abgetastet. Nach Empfang des Stop-Bits wird der externe Interrupt wieder aktiviert. Senden kann über einen beliebigen Pin ("TX") erfolgen, der entsprechend der Baudrate und dem zu sendenden Zeichen auf 0 oder 1 gesetzt wird. Die Implementierung ist nicht ganz einfach, es existieren dazu aber fertige Bibliotheken (z. B. bei [http://www.avrfreaks.net/ avrfreaks] oder in der [http://hubbard.engr.scu.edu/embedded/avr/avrlib/ Procyon avrlib]).
* Ein weiterer Ansatz erfordert keinen Pin mit "Interrupt-Funktion" aber benötigt mehr Rechenzeit. Jeder Input-Pin kann als Empfangspin (RX) dienen. Über einen Timer wird der Zustand des RX-Pins mit einem vielfachen der Baudrate abgetastet (dreifach scheint üblich) und High- bzw. Lowbits anhand einer Mindestanzahl identifiziert. (Beispiel: "Generic Software Uart" Application-Note von IAR)

Neuere AVRs (z. B. ATtiny26 oder ATmega48,88,168,169) verfügen über ein Universal Serial Interface (USI), das teilweise UART-Funktion übernehmen kann. Atmel stellt eine Application-Note bereit, in der die Nutzung des USI als UART erläutert wird (im Prinzip "Hardware-unterstützter Software-UART").

==Handshaking==
Wenn der Sender ständig sendet, wird irgendwann der Fall eintreten, daß der Empfänger nicht bereit ist, neue Zeichen zu empfangen. In diesem Fall muß durch ein '''Handshake-Verfahren''' die Situation bereinigt werden. Handshake bedeutet nichts anderes, als daß der Empfänger dem Sender mitteilt, daß er zur Zeit keine Daten annehmen kann und der Sender die Übertragung der nächsten Zeichen solange einstellen soll, bis der Empfänger signalisiert, daß er wieder Zeichen aufnehmen kann.
===Hardwarehandshake (RTS/CTS)===
Beim Hardwarehandshake werden zusätzlich zu den beiden Daten-Übertragungsleitungen noch 2 weitere Leitungen benötigt: '''RTS''' ('''R'''equest '''T'''o '''S'''end) und '''CTS''' ('''C'''lear '''T'''o '''S'''end). Jeder der beiden Kommunikationspartner ist verpflichtet, bevor ein Zeichen gesendet wird, den Zustand der '''RTS''' Leitung zu überprüfen. Nur wenn die Gegenstelle darauf Empfangsbereitschaft signalisiert, darf das Zeichen gesendet werden. Um der Gegenstelle zu signalisieren, daß sie zur Zeit keine Zeichen schicken soll, wird die Leitung '''CTS''' benutzt.

===Softwarehandshake (XON/XOFF)===
Beim Softwarehandshake sind keine speziellen Leitungen notwendig. Statt dessen werden besondere ASCII-Zeichen benutzt, die der Gegenstelle signalisieren, daß Senden einzustellen bzw. wieder aufzunehmen. 
* '''XOFF''' Aufforderung das Senden einzustellen
* '''XON''' Gegenstelle darf wieder senden

Nachteilig bei einem Softwarehandshake ist es, dass dadurch keine direkte binäre Datenübertragung mehr möglich ist. Von den möglichen 256 Bytewerten werden ja 2 (nämlich '''XON''' und '''XOFF''') für besondere Zwecke benutzt und fallen daher aus.

==Fehlersuche==
Erstaunlich oft wird im Forum der Hilferuf laut: "Meine UART funktioniert nicht, was mache ich falsch". In der überwiegenden Mehrzahl der Fälle stellt sich dann heraus, daß es sich um ein Hardwareproblem handelt, wobei da wiederrum der Löwenanteil auf das Konto einer nicht korrekt eingestellten Taktrate geht: Der µC benutzt nicht einen angeschlossenen Quarz, so wie er auch im Programm eingetragen ist, sondern läuft immer noch mit dem internen RC-Takt. Daraus resultiert aber auch, daß der Baudraten Konfigurationswert falsch berechnet wird.

Hilfreich zum Aufspüren solcher Fehler ist auch die [[AVR_Checkliste#UART/USART|AVR-Checkliste]].

==Links==
Tipps zur Verarbeitung von Strings sind in den [[FAQ]].

[[Kategorie:avr-gcc Tutorial]]
[[Kategorie:UART und RS232]]

Entscheidung Mikrocontroller

2009-03-22T12:16:21Z

134.76.63.190: /* [http://www.microchip.com/ Microchip] */

[[Category:Mikrocontroller]]
Die meisten Anfänger stellen sich die Frage, welchen [[Mikrocontroller]] sie verwenden sollen. Es gibt dutzende Hersteller, und jeder davon hat unzählige Varianten im Angebot. Stellt man die Frage in einem Diskussionsforum, dann bekommt man viele verschiedene (sich teilweise widersprechende) Antworten. Bei der Entscheidung sollten u.a. die unten stehenden Kriterien beachtet werden. Dieser Artikel ist primär für Hobbyisten gedacht, da im professionellen Einsatz oftmals völlig andere Kriterien beachtet werden müssen. Weitere vergleichende Informationen über verschiedene Controllerfamilien gibt der Artikel: [[AVR_PIC_51-Vergleich]]

== Verfügbarkeit ==
* Während man manche Mikrocontroller an jeder Straßenecke bekommt, sind andere nur in großen Stückzahlen und mit Gewerbenachweis erhältlich. Dazu einfach mal in die Kataloge der einschlägigen Privatkundenhändler schauen. Dabei auch darauf achten, dass der gewünschte Controller auch in der richtigen Bauform erhältlich ist (DIP, TQFP, MLF,usw.), s.u.
* Ab und zu kündigen Hersteller ein neues Modell an (und veröffentlichen das Datenblatt dazu), können aber erst ein Jahr später nennenswerte Stückzahlen liefern. Also den Controller nicht einfach anhand der Übersichten beim Hersteller aussuchen, sondern überprüfen, was die Händler auch wirklich liefern können.
* Lebenszyklus: Kein Modell wird ewig hergestellt, deswegen sollte man überprüfen, ob der Hersteller vielleicht schon angekündigt hat, dass er ein bestimmtes Modell nicht mehr herstellen will. Die Hersteller schreiben dann z.B. "Mature Product (Not Recommended for New Designs)". Für Neuentwicklungen oder den Einstieg sollte man folgende Modelle nicht verwenden:
** AVR AT90-Reihe,
** AVR ATMega 103(L), 161(L), 163(L), 323(L).
* Für alle abgekündigten AVR-Controller gibt es jedoch pin- und funktionskompatible Nachfolger. Daher kommt es nur in den seltensten Fällen zu Problemen. Probleme können nur entstehen wenn ein Programm nur in kompilierter Version zur Verfügung steht.
* Dagegen sind Mikrocontroller der [[8051|MCS51-Familie]] von Intel eher für langfristige Investitionen geeignet. Der 8051 wurde 1979 (!) als erstes Mitglied dieser Familie vorgestellt. Heute gibt es bereits hunderte von 8051-Derivaten von dutzenden von Halbleiterherstellern, zum Teil auch mit weiterentwickelten Prozessorkernen. Wird ein Derivat tatsächlich mal abgekündigt, findet man bei dieser Riesenauswahl meist leicht adäquaten Ersatz.

== Preis ==
Einerseits kann es lästig sein, wenn man durch die Verwendung eines kleineren Modells 2 Euro gespart hat und dann mit dessen Unzulänglichkeiten kämpft, andererseits ist ein versehentlich zerstörter Chip für 30 Euro ziemlich ärgerlich. Auch ist es oft ganz praktisch, wenn man einige Controller auf Vorrat hat.

Zum Preis eines einzelnen Mikrocontrollers kommen noch die Kosten für die Entwicklungswerkzeuge, wie [[Compiler]], Programmübertragung und Debugging hinzu (s.u. Programmiersprache und Programmübertragung).

== Dokumentation ==
Die wichtigste Informationsquelle zu einem Mikrocontroller ist das Datenblatt. Diese gibt es heutzutage aber fast ausschließlich in Englisch. Wer damit nicht zurecht kommt muss vorher schauen, ob es irgendwelche Tutorials oder Bücher in seiner Lieblingssprache gibt.

Je mehr Funktionen ein Mikrocontroller beherrscht, desto umfangreicher wird auch das Datenblatt. Das führt dazu, dass bei manchen Mikrocontrollern das Datenblatt über 1000 Seiten hat. Da ist die Gefahr groß, dass ein Anfänger den Überblick verliert.

== Unterstützung/Community ==
Gerade als Anfänger ist man oft auf die Hilfe anderer angewiesen. Da empfiehlt es sich, der Masse hinterherzulaufen und keine exotischen Typen zu verwenden. Im Bastlerbereich populäre Mikrocontroller-Familien sind die AVRs von Atmel und die PICs von Microchip. Für diese Architekturen gibt es z.B. im Forum dieser Internet-Seite gute und meist auch schnelle Hilfestellung bei Problemen.

== Bauformen ==
Neben den klassischen (bedrahteten) Bauformen setzt sich heutzutage [[SMD]] immer mehr durch. Manche Mikrocontroller sind nur noch in SMD-Bauformen erhältlich. Für SMD benutzt man üblicherweise geätzte Platinen oder Adapter/Sockel (die aber wieder extra kosten). Will man mit Lochrasterplatinen oder [[Breadboard]]s arbeiten, dann braucht man die klassischen Bauformen, z.B. PDIP. Zu beachten ist dabei, dass es PDIP oft nur bis DIP40 (also mit 40 Pins) gibt, d.h. einen Mikrocontroller mit 50 I/O-Pins kann es dann nur als SMD geben.

Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)
* AVR ATMega 64, 128, 169

In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:
* AVR ATMega 8, 16, 32
* viele 8051-Derivate, z.B. Atmel 89S8252

== Spannung ==
Während früher die meisten Mikrocontroller und die gesamte Peripherie mit 5V liefen, so gibt es heute auch alle möglichen anderen Varianten. Zu beachten ist:
* Controller und Peripherie müssen zusammenpassen. Man kann nicht einfach (ohne weitere Vorkehrungen) ein 3,3V-RAM an einen 5V-Controller anschließen und umgekehrt.
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].

* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!
* Bei Batterien und Akkus sinkt die Spannung ab, wenn sie leerer werden. Braucht der Controller z.B. mindestens 2,7V, dann wird man mit zwei 1,5V-Batterien nicht lange Freude haben (außer man benutzt spezielle Schaltregler).

== Stromverbrauch ==
Im Vergleich zu PC-Prozessoren (Pentium, Athlon usw.) brauchen Mikrocontroller relativ wenig Strom. Will man sie allerdings mit Batterien betreiben, dann wird der Stromverbrauch plötzlich doch wichtig. Die meisten Mikrocontroller besitzen hierfür Stromsparmodi, mit denen man den Controller teilweise abschalten kann. Für einen extrem geringen Stromverbrauch sind z.B. die [[MSP430]]-Controller optimiert.

Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab.

{| border=1 cellspacing=0
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)
|-
! 32KHz
|62µA||80µA||45µA||-
|-
! 100KHz
|0,3mA||0,5mA||-||-
|-
!1MHz, 2MHz*
|1,5mA ||2,3mA||4mA||-
|-
!8MHz, 4MHz*
|5mA ||7/15mA**||-||4.5mA
|-
!16MHz, 20MHz*
| - ||20mA||-||20mA
|}

[*] Abweichende Taktangabe für PIC16*F84A, da hier keine entsprechenden Werte für die Frequenzen des ATmega8 im Datenblatt (PIC16F84A Data Sheet, Microchip 2001, 35007b.pdf) vorliegen.

[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).

== Takt/Geschwindigkeit ==
Einerseits wünscht man sich oft einen möglichst schnellen Controller, insbesondere als Anfänger, wenn man effiziente Lösungen noch nicht so kennt, andererseits schlägt sich ein hoher Takt auch im Stromverbrauch und im Preis nieder. Man sollte sich dabei nicht von den hohen Taktraten der PC-Prozessoren irritieren lassen. Für viele Anwendungen reicht 1-MHz-Takt völlig aus.

Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann:
* Während manche Controller 12 Takte für einen Befehl brauchen (z.B. die Original-[[8051]]), kommen andere mit einem Takt pro Befehl aus (z.B. [[AVR]]).
* Manche Controller unterstützen gewisse Operationen hardwareseitig, die auf anderen Controllern in Software nachgebildet werden muss. Beispiele sind z.B. Multiplikation und Division. Wer in einer Hochsprache programmiert merkt davon nicht viel, da es dort die Befehle sowieso zur Verfügung stehen, aber sie brauchen auf einem Controller ohne Hardwareunterstützung eben deutlich länger.
* Die Datenbus- bzw. Registerbreite spielt eine wichtige Rolle, weil man z.B. für eine 16-Bit-Addition auf einer 8-Bit-CPU zwei Befehle und auf einer 16-Bit-CPU nur einen Befehl braucht.

== Speicher ==
Während früher oft nur die [[Register]] im Mikrocontroller waren, und der gesamte restliche Speicher extern angebunden werden musste, so sind heute die Speicher oft komplett im Mikrocontroller integriert. Das bedeutet aber teilweise auch, dass man sie nicht erweitern kann. Wichtig ist dabei u.a. die Größe des Programmspeichers (meist ein [[Flash-ROM]]) und das [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.

Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|Von-Neumann-Architektur]] und [[Harvard-Architektur]]. Bei letzterer liegen Programmspeicher (ROM) und Datenspeicher (RAM) in getrennten Speicherbereichen; dies hat den Nachteil, dass für den Zugriff auf den Programmspeicher spezielle Befehle notwendig sind (was die Verwendung von im ROM abgelegten Daten in C-Compilern ziemlich umständlich macht), und dass man keine Programmteile direkt aus dem Datenspeicher ausführen kann.

== Onboard-Peripherie ==
Mikrocontroller haben meist eine ganze Menge Funktionen integriert, z.B. [[AD-Wandler]], [[I²C]]-Bus, [[SPI]], [[PWM]], [[RS-232]] usw. usf. Der Vorteil liegt darin, dass der Controller damit mehrere Dinge gleichzeitig machen kann. Dadurch steigt zum einen die Gesamtleistung des Controllers, zum anderen sind viele Dinge zeitkritisch, und die Programmierung ist deutlich einfacher, wenn man zehn zeitkritische Dinge gleichzeitig erledigen muss.

== Störfestigkeit ==
Eigentlich ein wichtiges Thema, andererseits findet man dazu nur sehr wenig Informationen. Bekannt ist beispielsweise, dass bei der [[AVR]]-Familie die ATmegas deutlich störfester sind als die alten AT90S.

== Programmiersprachen ==
Den direktesten Zugriff auf die "Innereien" eines Prozessors hat man mit [[Assembler]]. Dies ist jedoch gleichzeitig - zumindest auf den ersten Blick - die "abschreckendste" Sprache, denn sie erfordert einen hohen Lernaufwand. Aufgrund stark unterschiedlicher Befehlssätze verschiedener Controllerfamilien ist das Gelernte nie 1-zu-1 übertragbar und meist nur direkt auf einen einzigen Prozessor oder allenfalls auf eine Familie "verwandter" Produkte anwendbar. Dennoch kann man sich mit einiger Erfahrung recht schnell in einen anderen Befehlssatz einarbeiten. In bestimmten Bereichen oder Teilen eines Projekts wird die Verwendung von Assembler dennoch unabdingbar sein. (Diese Teile mögen projektabhängig zwischen 100% oder auch nur deutlich unter 1% umfassen.)

Die Auswahl der richtigen Programmiersprache hängt auch stark vom geplanten Einsatzzweck ab. Ein Elektrotechnik-Student, der sich für sein späteres Berufsleben vorbereiten möchte, sollte sich mit C und Assembler befassen. Wer dagegen gar nicht vorhat sich allzu tief einzuarbeiten und sowieso schon Basic oder Pascal kann, der sollte zu diesen Sprachen greifen.

Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.

== Debugging ==
Bei der Fehlerbeseitigung trennen sich Profi von Amateur und es kann richtig teuer werden. Genau hier haben die Hersteller von Mikrocontrollern und/oder Compilern eine Möglichkeit gefunden den Gelegenheitsprogrammierer abzuweisen und nur den zahlenden Profi vorzulassen.

Die preisgünstigste aber auch unkomfortabelste Art des Debuggings ist der Einbau von Testcode in das Programm. Dieser Testcode informiert den Programmierer über erreichte Programmpunkte und dabei aufgetretene Datenwerte. Die Ausgabe erfolgt per optisch/akustischer Anzeige oder serieller Schnittstelle. Der Nachteil dieser Methode liegt in ihrem Zeitaufwand. Für jedes Problem muss ein kurzes Stück Testcode erdacht und in das Programm eingefügt werden. Danach wird das Programm kompiliert/assembliert und in den Flashspeicher des Mikrocontrollers gebrannt. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.

Deutlich effektiver ist die Fehlersuche mittels einer in die PC-Entwicklungsumgebung integrierten Debugger Software. Üblicherweise besteht diese Software aus mehreren Fenstern zur Anzeige folgender Informationen:

* Programm- und Datenspeicher des Mikrocontrollers.
* Arbeits- und Konfigurationsregister des Mikrocontrollers.
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.
* Werte von Programm Variablen.

Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise oder wiederholend abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert. Angemerkt sei, Debugging einer Hochsprache wie C funktioniert nur richtig wenn die Codeoptimierung des Compilers deaktiviert ist. Diese Bedingung bringt es mit sich, dass für die Entwicklungsphase bis zu 30% mehr Programmspeicher benötigt werden.

Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.

Für das In-System Debugging wird der Ziel-Mikrocontroller mit seiner In-Circuit Debugging Hardware benutzt. Diese integrierte Hardware kommuniziert über teils genormte Schnittstellen mit der Debugger Software auf dem PC. Als Verbindungsglied dient ein Kabel mit mehr oder weniger komplexer Elektronik. Diese Elektronik, das fehlende Wissen um ihre Funktion und die teils eingebaute Donglefunktion verhindern preisgünstigen Nachbau und machen ihren Hersteller sicher vor unautorisierter Benutzung der Entwicklungsumgebung.

Bei der Vielzahl von Controller- und Compiler-Herstellen ist es kaum möglich einen Überblick über die Debugger Hardware/Software zu geben. Hier nur einige Beispiele:

=== [http://www.atmel.com/ Atmel] ===

{| border="1"
|-
!System
!Preis
|-
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)
| ~ 35€
|-
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)
| ~ 55€
|-
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]
| ~ 85$
|-
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone
| ~ 280€/140$
|-
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]
| ~ 550€
|}

[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].

Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.

Der [[JTAG|AVR JTAG]] ICE Clone kann nur nachfolgende ältere ATmega Controller debuggen: ATmega16, ATmega16L, ATmega162, ATmega162L, ATmega162V, ATmega165, ATmega165V, ATmega169, ATmega169L, ATmega169V, ATmega32, ATmega32L, ATmega323, ATmega323L, ATmega64, ATmega64L, ATmega128, ATmega128L, AT90CAN128. Trotzdem ist er ein sehr wertvolles, weil günstiges, Werkzeug wenn man die Typbeschränkung akzeptieren kann.

Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.

[http://www.mikrocontroller.net/topic/107070 AVR JTAG ICE MKII – CN] ist ein Produkt aus China mit der versprochenen Funktionalität eines originalen AVR JTAG ICE MKII von Atmel. Es besitzt eigenständige Elektronik und auch die aktualisierbare Firmware ist vom Original verschieden. Oftmals ist dieses Produkt beim nicht unbekannten Online-Auktionshaus zu finden.

=== [http://www.microchip.com/ Microchip] ===

{| border="1"
|-
!System
!Preis
|-
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]
| ~ 30€/55€
|-
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]
| ~ 65€
|-
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.keeelectronics.com/icd25debugger.html Clone ICD2.5] / [http://www.sivava.com/MPLAB_ICD2.html Clone ICD2]
| ~ 90€/40€/40€
|-
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]
| ~ 190€
|}

Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese IDE kann mit C-Compilern verschiedener Hersteller zusammenarbeiten. Das Setup installiert keine Microchip C-Compiler sondern bietet als Option die C-Compiler von CCS und HI-TECH. Der CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt. Die HI-TECH Compiler für PIC10/12/16, PIC18 und PIC32 haben, wenn sie als Freeware im ‚Lite mode’ arbeiten, eingeschränkte Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen einen Teil der Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.

Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.

Die beiden für PICs vorhandenen IDEs von Microchip und HI-TECH bilden zusammen mit den freien C-Compilern und den preisgünstigen ICD 2 Clones eine kostengünstige Möglichkeit PIC-Code zu erstellen und zu debuggen. Die eingeschränkte Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.

=== [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] ===

{| border="1"
|-
!System
!Preis
|-
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p58_MSP430-JTAG-Parallelportkabel--MSP430-JTAG-.html MSP430 JTAG (parallel)]
| ~ 15€
|-
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html MSP430-JTAG-TINY (USB)]
| ~ 65€
|-
| TI-FET [http://focus.ti.com/docs/toolsw/folders/print/msp-fet430uif.html MSP430 USB Debugging Interface]
| ~ 115€
|-
| TI [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool]
| ~ 30€
|}

[http://focus.ti.com/lit/ug/slau265/slau265.pdf Programmierung] und Debugging der MSP430 erfolgt über JTAG-Schnittstelle und in neusten Varianten (MSP430F20xx, F21x2, F22xx) über ‚Spy-Bi-Wire’ (2-wire JTAG). Die ursprüngliche JTAG-Schnittstelle benötigt 4 Signalleitungen plus Reset. Bei ‚Spy-Bi-Wire’ sind die Signalleitungen auf 2 reduziert.

Jeder anwenderprogrammierbare MSP430 enthält einen [[Bootloader]]. Bei den Typenreihen MSP430F1xx, F2xx und F4xx befindet er sich im ROM. Bei den MSP430F6xx im Flash-Speicher.

TI bezeichnet die Programmier- und Debugging-Hardware als Flash Emulation Tool (FET). Es existieren die Varianten ‚Parallel Port’ und USB. Die preisgünstigen parallelen Systeme beherrschen nur JTAG. Bei den USB-Systemen ist zusätzlich ‚Spy-Bi-Wire’ implementiert und man kann damit die Codeschutz Sicherung des Mikrocontrollers auslösen.

Die [http://www.olimex.com/dev/index.html Olimex] Produkte entsprechen in ihrer Funktion weitestgehend den TI Vorbildern und können mit jeder, die TI Werkzeuge unterstützenden, Software verwendet werden. Kleine Abweichungen bestehen bei der [http://www.olimex.com/dev/images/MSP430/SPY-BI-WIRE-CONNECTION.jpg Olimex Implementierung] der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.

Das ‚MSP430 USB Stick Development Tool’ ist eine eigenständige Debugging-Hardware mit aufgestecktem eZ430-F2013 Zielsystem. Der Stick beherrscht aber nur ‚Spy-Bi-Wire’ wodurch die Anzahl der unterstützten Controller begrenzt ist.

Als Entwicklungsumgebung stellt TI den auf der [http://www.eclipse.org/ Eclipse IDE] aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html ‚CCE Core Edition’] ist dieses Paket auf 16kB Code begrenzt.

Mit der freien IDE Eclipse, dem GNU C-Compiler für MSP430, einigen Zutaten und dem Olimex Parallelport-Adapter kann man die wohl preiswerteste, unbeschränkte Entwicklungsumgebung für Mikrocontroller zusammenstellen. Es ist keine perfekte Kombination und die Installation macht einige Mühe; im Ergebnis hat man aber eine Arbeitsplattform, einschließlich Debugger, ohne unverständliche Skripte oder kryptischen Make-Files. Über diese beiden Links

* [[Eclipse und MSPGCC unter Windows]] (03/2009)
* [http://matthias-hartmann.blogspot.com/ Use Eclipse and mspgcc - the easy way] (Windows 02/2009)

findet man zwei verschiedenartige Lösungen der Installation unter Windows. Obwohl beide Varianten auf teils verschiedene Werkzeuge zurückgreifen sind sie kombinierbar und ergeben damit Spielraum für persönliche Vorlieben.

=== [http://www.zilog.com/ Zilog] ===

{| border="1"
|-
!System
!Preis
|-
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]
| ~ 30$
|-
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]
| ~ 70$
|}

Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.

== Programmübertragung ==
Im Idealfall stellt sich die Frage, wie das Programm in den Mikrocontroller kommt, für den Programm-Entwickler nicht. Die Debugging-Hardware erledigt diese Aufgabe ganz unauffällig mit. Da die Umstände aber nicht immer ideal sind, muss der Entwickler manchmal auf andere Methoden zurückgreifen.

Früher wurden überwiegend teure und umständlich zu handhabende Programmiergeräte verwendet, mit deren Hilfe der Programmspeicher außerhalb des Zielsystems gefüllt wurde. Heute sind die meisten Mikrocontroller über verschiedene ISP-Schnittstellen oder über das [[UART]] ‚In-System’-programmierbar.

Die ISP-Schnittstelle ist entweder als universelle Debugging- und Programmier-Schnittstelle, z.B. [[JTAG]], oder als dedizierte Programmier-Schnittstelle realisiert. Für den zweiten Fall benötigt man einen speziellen Programmier-Adapter den man, meistens in verschiedenen Ausführungen, kaufen oder selber bauen kann. Dazugehörig ist ein passendes Programmier-Programm für den PC. Spezialisierte Programmier-Adapter und –Programme werden auch gern in der laufenden Produktion eingesetzt.

Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.

Mikrocontroller Vergleich

2009-03-21T14:33:48Z

134.76.63.190: /* Starterkits */

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€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Bei '''PIC''' sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; 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. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm

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.

Zilog stellt für '''[[Z8]]e''' 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". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein.

==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 16bit codierte Befehle. 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 sich 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.

'''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''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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''': [[von Neumann-Architektur]], problemlos.

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''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 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. 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.

'''eZ8''': Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB 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 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 einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM-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, repariert in ARMv7 (Cortex M3).

'''AVR:''' Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zu alten PIC ihre eigenen Interruptvektoren, so dass keine Zeit mit der Suche nach der Quelle verbracht wird.
Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. ''Achtung: es muss gewährleistet sein, dass auch im worst case ein Interrupt sich nicht selbst unterbricht!''

''Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).''

'''MSP430:''' Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar.

'''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.

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

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V

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

'''ARM''': 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich.

'''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.

'''Z8e''': 3,3V-Versorgung, 5V-kompatibel.

==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.

'''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.

'''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)

'''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).

'''Z8e''': Via Debug-Interface.

==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.

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

==Starterkits==

'''8051''': Keil MCB900 (http://www.keil.com/mcb900)

'''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==

'''AVR, PIC, 8051, Z8e, MSP430, R8C''': 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]]
* [[AVR]]
* [[PIC]]
* [[Z8]]
* [[ARM]]
* [[MSP430]]
* [[R8C]]

[[Category:Mikrocontroller]]

Mikrocontroller Vergleich

2009-03-21T14:31:11Z

134.76.63.190: /* Debugging in der Schaltung */

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€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Bei '''PIC''' sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; 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. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm

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.

Zilog stellt für '''[[Z8]]e''' 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". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein.

==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 16bit codierte Befehle. 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 sich 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.

'''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''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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''': [[von Neumann-Architektur]], problemlos.

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''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 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. 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.

'''eZ8''': Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB 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 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 einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM-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, repariert in ARMv7 (Cortex M3).

'''AVR:''' Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zu alten PIC ihre eigenen Interruptvektoren, so dass keine Zeit mit der Suche nach der Quelle verbracht wird.
Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. ''Achtung: es muss gewährleistet sein, dass auch im worst case ein Interrupt sich nicht selbst unterbricht!''

''Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).''

'''MSP430:''' Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar.

'''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.

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

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V

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

'''ARM''': 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich.

'''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.

'''Z8e''': 3,3V-Versorgung, 5V-kompatibel.

==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.

'''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.

'''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)

'''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).

'''Z8e''': Via Debug-Interface.

==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.

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

==Starterkits==

'''8051''': Keil MCB900 (http://www.keil.com/mcb900)

'''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''': 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==

'''AVR, PIC, 8051, Z8e, MSP430, R8C''': 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]]
* [[AVR]]
* [[PIC]]
* [[Z8]]
* [[ARM]]
* [[MSP430]]
* [[R8C]]

[[Category:Mikrocontroller]]

Mikrocontroller Vergleich

2009-03-21T14:24:27Z

134.76.63.190: /* Spannungsversorgung */

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€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Bei '''PIC''' sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; 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. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm

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.

Zilog stellt für '''[[Z8]]e''' 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". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein.

==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 16bit codierte Befehle. 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 sich 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.

'''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''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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''': [[von Neumann-Architektur]], problemlos.

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''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 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. 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.

'''eZ8''': Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB 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 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 einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM-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, repariert in ARMv7 (Cortex M3).

'''AVR:''' Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zu alten PIC ihre eigenen Interruptvektoren, so dass keine Zeit mit der Suche nach der Quelle verbracht wird.
Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. ''Achtung: es muss gewährleistet sein, dass auch im worst case ein Interrupt sich nicht selbst unterbricht!''

''Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).''

'''MSP430:''' Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar.

'''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.

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

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V

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

'''ARM''': 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich.

'''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.

'''Z8e''': 3,3V-Versorgung, 5V-kompatibel.

==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.

'''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.

'''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)

'''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).

'''Z8e''': Via Debug-Interface.

==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/

'''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.

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

==Starterkits==

'''8051''': Keil MCB900 (http://www.keil.com/mcb900)

'''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''': 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==

'''AVR, PIC, 8051, Z8e, MSP430, R8C''': 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]]
* [[AVR]]
* [[PIC]]
* [[Z8]]
* [[ARM]]
* [[MSP430]]
* [[R8C]]

[[Category:Mikrocontroller]]

Mikrocontroller Vergleich

2009-03-21T14:21:51Z

134.76.63.190: /* Priorisierte Interrupts */

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€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Bei '''PIC''' sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; 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. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm

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.

Zilog stellt für '''[[Z8]]e''' 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". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein.

==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 16bit codierte Befehle. 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 sich 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.

'''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''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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''': [[von Neumann-Architektur]], problemlos.

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''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 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. 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.

'''eZ8''': Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB 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 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 einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM-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, repariert in ARMv7 (Cortex M3).

'''AVR:''' Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zu alten PIC ihre eigenen Interruptvektoren, so dass keine Zeit mit der Suche nach der Quelle verbracht wird.
Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. ''Achtung: es muss gewährleistet sein, dass auch im worst case ein Interrupt sich nicht selbst unterbricht!''

''Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).''

'''MSP430:''' Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar.

'''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.

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

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V

'''ARM''': 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich.

'''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.

'''Z8e''': 3,3V-Versorgung, 5V-kompatibel.

==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.

'''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.

'''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)

'''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).

'''Z8e''': Via Debug-Interface.

==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/

'''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.

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

==Starterkits==

'''8051''': Keil MCB900 (http://www.keil.com/mcb900)

'''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''': 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==

'''AVR, PIC, 8051, Z8e, MSP430, R8C''': 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]]
* [[AVR]]
* [[PIC]]
* [[Z8]]
* [[ARM]]
* [[MSP430]]
* [[R8C]]

[[Category:Mikrocontroller]]

Mikrocontroller Vergleich

2009-03-21T14:17:16Z

134.76.63.190: /* Skalierbarkeit */

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€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Bei '''PIC''' sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; 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. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm

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.

Zilog stellt für '''[[Z8]]e''' 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". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein.

==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 16bit codierte Befehle. 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 sich 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.

'''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''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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''': [[von Neumann-Architektur]], problemlos.

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''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 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. 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.

'''eZ8''': Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB 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 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 einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM-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, repariert in ARMv7 (Cortex M3).

'''AVR:''' Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zum PIC ihre eigenen Interruptvektoren, so dass keine Zeit mit der Suche nach der Quelle verbracht wird.
Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. ''Achtung: es muss gewährleistet sein, dass auch im worst case ein Interrupt sich nicht selbst unterbricht!''

''Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).''

'''MSP430:''' Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar.

'''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.

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

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

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V

'''ARM''': 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich.

'''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.

'''Z8e''': 3,3V-Versorgung, 5V-kompatibel.

==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.

'''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.

'''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)

'''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).

'''Z8e''': Via Debug-Interface.

==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/

'''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.

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

==Starterkits==

'''8051''': Keil MCB900 (http://www.keil.com/mcb900)

'''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''': 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==

'''AVR, PIC, 8051, Z8e, MSP430, R8C''': 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]]
* [[AVR]]
* [[PIC]]
* [[Z8]]
* [[ARM]]
* [[MSP430]]
* [[R8C]]

[[Category:Mikrocontroller]]

Mikrocontroller Vergleich

2009-03-21T13:41:10Z

134.76.63.190: /* Sind Daten in RAM und ROM mit dem gleichen Code benutzbar? */

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€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Bei '''PIC''' sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; 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. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm

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.

Zilog stellt für '''[[Z8]]e''' 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". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein.

==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 16bit codierte Befehle. 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 sich 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.

'''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''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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''': [[von Neumann-Architektur]], problemlos.

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''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 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. 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.

'''eZ8''': Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB 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 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 einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM-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, repariert in ARMv7 (Cortex M3).

'''AVR:''' Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zum PIC ihre eigenen Interruptvektoren, so dass keine Zeit mit der Suche nach der Quelle verbracht wird.
Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. ''Achtung: es muss gewährleistet sein, dass auch im worst case ein Interrupt sich nicht selbst unterbricht!''

''Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).''

'''MSP430:''' Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar.

'''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.

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

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

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V

'''ARM''': 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich.

'''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.

'''Z8e''': 3,3V-Versorgung, 5V-kompatibel.

==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.

'''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.

'''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)

'''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).

'''Z8e''': Via Debug-Interface.

==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/

'''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.

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

==Starterkits==

'''8051''': Keil MCB900 (http://www.keil.com/mcb900)

'''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''': 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==

'''AVR, PIC, 8051, Z8e, MSP430, R8C''': 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]]
* [[AVR]]
* [[PIC]]
* [[Z8]]
* [[ARM]]
* [[MSP430]]
* [[R8C]]

[[Category:Mikrocontroller]]

Mikrocontroller Vergleich

2009-03-21T13:23:47Z

134.76.63.190: /* Architektur */

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€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Bei '''PIC''' sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; 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. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm

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.

Zilog stellt für '''[[Z8]]e''' 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". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein.

==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 16bit codierte Befehle. 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 sich 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.

'''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''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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.

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

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

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''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 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. 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.

'''eZ8''': Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB 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 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 einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM-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, repariert in ARMv7 (Cortex M3).

'''AVR:''' Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zum PIC ihre eigenen Interruptvektoren, so dass keine Zeit mit der Suche nach der Quelle verbracht wird.
Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. ''Achtung: es muss gewährleistet sein, dass auch im worst case ein Interrupt sich nicht selbst unterbricht!''

''Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).''

'''MSP430:''' Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar.

'''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.

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

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

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V

'''ARM''': 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich.

'''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.

'''Z8e''': 3,3V-Versorgung, 5V-kompatibel.

==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.

'''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.

'''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)

'''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).

'''Z8e''': Via Debug-Interface.

==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/

'''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.

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

==Starterkits==

'''8051''': Keil MCB900 (http://www.keil.com/mcb900)

'''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''': 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==

'''AVR, PIC, 8051, Z8e, MSP430, R8C''': 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]]
* [[AVR]]
* [[PIC]]
* [[Z8]]
* [[ARM]]
* [[MSP430]]
* [[R8C]]

[[Category:Mikrocontroller]]

Mikrocontroller Vergleich

2009-03-21T13:12:56Z

134.76.63.190: /* Compiler verfügbar, bzw wieviel will man dafür ausgeben? */

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€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden.

Bei '''PIC''' sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; 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. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm

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.

Zilog stellt für '''[[Z8]]e''' 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". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein.

==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 16bit codierte Befehle. 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). Mit der neueren 16-Bit (Programmspeicherbreite) Architektur wurden einige dieser Probleme beseitigt, andere nicht. Microchip hat auch eine Familie mit 16-Bit Datenbusbreite angekündigt.

'''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 sich 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.

'''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''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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.

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

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

==Lineare Adressierung vom RAM?==

'''8051''', '''ARM''', '''AVR''', '''MSP430''', '''R8C/M16C''', '''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 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. 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.

'''eZ8''': Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB 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 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 einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

'''8051''': Ja.

'''ARM''': Der ARM-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, repariert in ARMv7 (Cortex M3).

'''AVR:''' Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zum PIC ihre eigenen Interruptvektoren, so dass keine Zeit mit der Suche nach der Quelle verbracht wird.
Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. ''Achtung: es muss gewährleistet sein, dass auch im worst case ein Interrupt sich nicht selbst unterbricht!''

''Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).''

'''MSP430:''' Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar.

'''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.

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

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

== Spannungsversorgung ==

'''8051''', '''AVR''', '''PIC''': 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V

'''ARM''': 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich.

'''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.

'''Z8e''': 3,3V-Versorgung, 5V-kompatibel.

==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.

'''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.

'''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)

'''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).

'''Z8e''': Via Debug-Interface.

==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/

'''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.

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

==Starterkits==

'''8051''': Keil MCB900 (http://www.keil.com/mcb900)

'''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''': 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==

'''AVR, PIC, 8051, Z8e, MSP430, R8C''': 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]]
* [[AVR]]
* [[PIC]]
* [[Z8]]
* [[ARM]]
* [[MSP430]]
* [[R8C]]

[[Category:Mikrocontroller]]