Über den Beitrag

Viele Hobbyelektroniker steigen über den Arduino in die Welt der Microcontroller (MCU) ein, da dieser Weg auch für Anfänger leicht verständlich ist. Ich bin da keine Ausnahme. Im Laufe der Zeit merkt man aber auch, dass es da noch tiefere Ebenen gibt, in die es sich einzusteigen lohnt. Man stößt auf Register, Portmanipulation, Fuse-Bits, Signaturen, C-Programme usw. und irgendwann will man auch diese Dinge verstehen. Dafür ist die Arduino Umgebung allerdings nur bedingt geeignet.

Der nächste logische Schritt ist der Einstieg in Atmel Studio, aktuell Atmel Studio 7 (Nachtrag: in 2020 wurde Atmel Studio in Microchip Studio umbenannt). So leicht es einem der Arduino macht, so eigentümlich ist hingegen das Arbeiten mit Atmel Studio. Man gewöhnt sich daran, aber am Anfang kann es etwas abschreckend sein, da vieles in diesem Programm alles andere als selbsterklärend ist. Aber es lohnt sich und mit diesem Beitrag möchte ich euch den Einstieg erleichtern.

Ich war schon mal kurz auf Atmel Studio in meinem Beitrag über die Programmierung von ATtiny85 & Co eingegangen, konnte das Thema wegen seines Umfanges aber nur anreißen. Geeignete Programmer für Atmel Studio habe ich in meinem letzten Beitrag beschrieben. Wenn bei euch im weiteren Verlauf dieses Beitrages Fragen zu den Programmern auftreten, dann werden sie vielleicht dort beantwortet.

Im Einzelnen gibt es hier eine Schritt-für-Schritt Anleitung für: 

• die Installation von Atmel Studio 7
• den Upload eines Blinkprogrammes auf einen ATtiny85
• Debugging und Breakpoints

Dabei setze ich voraus, dass ihr einen debuggingfähigen Programmer wie den AVR Dragon oder den Atmel-ICE besitzt. Ist euer Programmer nicht debuggingfähig, dann könnt ihr aber zumindest die ersten beiden Punkte nachvollziehen. 

Installation von Atmel Studio 7

Atmel Studio 7 ist eine kostenlose Entwicklungsumgebung für die Programmierung von Atmel MCUs, welche hier von den Seiten des Herstellers Microchip Technology Inc heruntergeladen werden kann. Wenn ihr dem Link folgt, dann gibt es dort einen Web Installer und einen Offline Installer. Der Web Installer ist die empfohlene Variante. Sie setzt eine durchgehende Internetverbindung voraus. 

Die Installation ist nicht schwierig, da fast alles automatisch passiert. Allerdings dauert das Ganze etwas. Auf einem nicht ganz neuen Laptop nahm die Installation des gesamten Softwarepaketes eine gute halbe Stunde in Anspruch und satte 4 GB Plattenplatz wurden benötigt. 

Die einzige größere Entscheidung, die man während der Installation treffen muss, ist welche MCU Familie man mit Atmel Studio programmieren möchte: 

Sehr wahrscheinlich reicht euch die Installation von AVR 8, also das Paket für die 8-Bit MCUs. Damit habt ihr die ATtiny-, ATMega- und AVR XMega-Familien abgedeckt. Da ich auch die anderen Pakete mit installiert habe, dürfte der benötigte Plattenplatz bei euch etwas geringer sein und auch die Installationszeit, sofern ihr euch auf AVR 8 beschränkt.

Nach der Installation legen wir das Programm erstmal beiseite und wenden uns anderen vorbereitenden Maßnahmen zu. 

Die Schaltung

Als Beispiel für ein erstes „Projekt“ nehmen wir wie schon erwähnt ein Blinkprogramm, das per ISP Verbindung auf einen ATtiny85 geladen wird. Die LED soll durch den I/O Pin PB4 geschaltet werden. 

Der ISP Anschluss ist folgendermaßen belegt:

Der Pinout des ATtiny85 sieht so aus:

Ihr müsst jetzt sicherstellen, dass ihr den Programmer entsprechend der Anschlussschemata miteinander verbindet. Also schlicht MISO an MISO, MOSI an MOSI, VCC an VCC usw. Wie ihr das konkret macht und ob ihr für den ATtiny85 noch eine externe Stromquelle braucht, hängt vom verwendeten Programmer ab. Vielleicht benutzt ihr auch einen Breadboardadapter oder wählt die On-Board Programmierung auf dem AVR Dragon. Wenn euch nicht klar ist was zu tun ist, dann schaut bitte in meinen letzten Beitrag. 

Das Beispielprogramm

Programme (man sagt hier nicht Sketche) in Atmel Studio werden meistens in C geschrieben. Das sieht für diejenigen, die bisher nur die Arduinowelt kennen, befremdlich-kryptisch aus. Ein 

pinMode(4, OUTPUT);  und digitalWrite(4, HIGH);

ist gegenüber den C – Äquivalenten

DDRB = (1<<PB4); bzw. PORTB |= (1<<PB4); 

natürlich selbsterklärender. Das Schöne am C-Code ist hingegen, dass man sieht, was auf Port- bzw. Registerebene passiert. Außerdem ist der C-Code um ein Mehrfaches schneller. Eine sehr komprimierte Einführung in Portmanipulation und Bitoperationen gibt es hier. Vielleicht mache ich auch nochmal einen eigenen Beitrag zu dem Thema, hier würde es aber den Rahmen sprengen.

Hier das Beispiel Blinkprogramm:

/*
 * ATtiny85_Blink.c
 *
 * Created: 25.06.2019 18:30:08
 * Author : Ewald
 */ 

// Einbinden der benötigten Bibliotheken:
#include <avr/io.h> 
#include <util/delay.h>

int main(void) // Beginn des Hauptprogrammes
{
  DDRB = (1<<PB4); // Pin 4 im Richtungsregister auf Output
   
    while (1) // Entspricht der loop Schleife beim Arduino
    {
    PORTB |= (1<<PB4); // PB4 geht HIGH
    _delay_ms(1000); // warte 1000 ms
    PORTB &= ~(1<<PB4); // PB4 geht LOW
    _delay_ms(1000); // warte 1000 ms
    }
}

 

Programmerstellung

Nun aber wieder zurück zum frisch installierten Atmel Studio 7. Nach dem Öffnen wählt ihr „New Project …“. 

Nun wählt ihr „GCC C Executable Project“. Wenn ihr C++ Code verwenden wollt, dann wählt „GCC C++ Executable Project“. Was es mit der letzten Option „Create project from Arduino Sketch“ auf sich hat, werde ich in einem separaten Beitrag erklären. 

Wichtig ist, dass man hier schon den richtigen Projektnamen eingibt. Eine spätere Änderung des Namens ist nicht so trivial wie bei Arduino Sketchen.

Dann mit „OK“ bestätigen. 

Als nächstes müsst ihr den MCU wählen, hier ATtiny85. Der MCU wird in Atmel Studio als „Device“ bezeichnet. 

Dann seid ihr auch schon im Editor für das Hauptprogramm, das standardmäßig „main.c“ heißt. Ersetzt bzw. ergänzt den Code um das Beispielprogramm.

Habt ihr das Programm eingegeben, könnt ihr es auf Syntaxfehler testen. Dazu geht auf das eingekreiste Symbol für „Build Solution“. Im Outputfenster weiter unten erscheinen eine Reihe von Meldungen – und hoffentlich ist keine Fehlermeldung dabei.

Die meisten Funktionen wie „Build Solution“ sind nicht nur über die Symbole, sondern auch über die Drop Down Menüs und Tastenkombinationen zugänglich. Ich bleibe hier bei den Symbolen. 

Toolauswahl und MCU Einstellungen in Atmel Studio 7

Der Programmer wird in Atmel Studio als „Tool“ bezeichnet. Die Toolauswahl erfolgt über das Symbol mit dem Hammer (ein recht grobes Symbol, finde ich).

In meinem Beispiel wähle ich den Dragon. Er muss mit dem PC verbunden sein, damit er als Auswahl erscheint. 

Jetzt müssen noch ein paar Einstellungen im ATtiny85 vorgenommen werden. Das geht nur im ISP Modus, den man über ein Drop Down Menü auswählt. 

Nun klickt ihr auf das kleine Symbol mit dem IC und dem Blitz („Device Programming“). Sofern im aufgehenden Fenster Tool, Device und Interface korrekt sind, klickt auf „Apply“. Dann könnt ihr die Signatur des MCU (Device Signature) und die Spannung am MCU (Target Voltage) auslesen, indem ihr auf „Read“ klickt. Denkt daran: der AVR Dragon, der Atmel-ICE und manche andere Programmer können den MCU nicht mit Strom versorgen. Es muss eine externe Spannungsquelle verwendet werden. Trotzdem müssen zusätzlich GND und VCC des ISP Anschlusses verbunden werden. 

Nun könnt ihr euch den berühmt-berüchtigten Fuse-Bits zuwenden. 

Bei den Fuse-Bits muss man ein wenig aufpassen, was man tut, da man sich leicht aussperren kann. Das ist dann nur mit einem HVSP-fähigem Programmer wie dem AVR Dragon rückgängig zu machen. 

Ein neuer ATtiny85 hat den sogenannten Clock Divider aktiviert. Er teilt den Takt durch 8. Verantwortlich dafür ist das Fuse-Bit CKDIV8. Entfernt den Haken und klickt auf „Program“.

Wenn ihr euren ATtiny vorher schon einmal mit dem Arduino mit 8 MHz programmiert habt, sollte der Haken nicht gesetzt sein.  

Wenn alles funktioniert, ist der Haken weg und unten taucht die Meldung „Verify Registers … OK“ auf. 

Eine vorbereitende Tätigkeit fehlt noch, und zwar müssen wir Atmel Studio die Taktfrequenz mitteilen. Dazu schließt ihr das Device Programming Fenster, geht zu den Tools (Hammersymbol) und wählt „Toolchain“. Klickt auf „Symbols“, dann auf das „Add Item“ Symbol und tragt im Dialogfenster „F_CPU=8000000UL“ ein. Alternativ zu diesen Schritten tragt ihr im Programm die Zeile

#define F_CPU 8000000UL

ein (noch vor den includes!). Das war es dann aber auch.  

Upload und Debugging in Atmel Studio 7

Sofern ihr kein Debugging wollt (oder der Programmer es nicht kann) oder ihr schon mal neugierig seid, ob alles funktioniert, könnt ihr jetzt auf das grüne, nicht ausgefüllte Dreieck („Start Without Debugging“) klicken. Das Programm wird hochgeladen und sofern ihr die LED schon angeschlossen habt, sollte sie in der richtigen Frequenz blinken. 

Um das Programm im Debugging Modus laufen zu lassen, klickt ihr auf das Symbol mit dem Play-Pause Zeichen („Start Debugging and Break“). 

Seid ihr dieser Anleitung gefolgt, befindet ihr euch noch im ISP Modus und bekommt folgende Fehlermeldung:

Ihr müsst also vom ISP Modus in den debugWire Modus wechseln. Dazu geht ihr wieder in den Toolbereich und wählt debugWIRE als Interface. Der debugWire Modus hat keinen separaten Anschluss – auch er läuft über die ISP Leitungen. 

Ihr versucht es nochmal und bekommt noch eine Fehlermeldung, da das DWEN (debugWire Enable) Fuse Bit nicht aktiviert ist. Die gute Nachricht: wenn ihr mit „Yes“ quittiert, nimmt Atmel Studio diese Einstellung vor. 

Die schlechte Nachricht: ihr bekommt noch eine Fehlermeldung, da der MCU neu gestartet werden muss. Trennt den AVR Dragon vom MCU, trennt einmal kurz die Stromversorgung zum MCU, verbindet den Dragon wieder und klickt auf „OK“.

Ich spare mir Schritt 1 und 3 immer, trenne also nur kurz die Stromversorgung vom MCU und es funktioniert trotzdem. Nachmachen auf eigene Gefahr!  

Das Programm startet nun, bleibt aber dann in der ersten Programmzeile stehen. 

Wenn ihr jetzt auf das volle, grüne Dreieck („Continue“) klickt, läuft das Programm normal weiter. 

Diese Prozedur bietet natürlich noch keinen wirklichen Vorteil. Das ändert sich mit dem schrittweisen Ausführen des Programmes. Dazu stoppt zunächst einmal das Debugging durch Klicken auf das rotbraune Quadrat.

Schrittweises Ausführen und Register verfolgen

Es gibt zwei Methoden Programme schrittweise auszuführen. Bei der ersten Methode müssen die delay Befehle auskommentiert werden. Bei der zweiten Methode, den Breakpoints, die weiter unten behandelt werden, ist das nicht notwendig. 

Aber zunächst zur ersten Methode. Kommentiert die delay Befehle aus und wählt wieder „Start Debugging and Break“ (das Play-Stop Symbol). Dann klickt auf das „Step Over“ Symbol. Mit jedem Klick auf das Symbol springt das Programm eine Zeile weiter. Dabei seht ihr, dass der Stopp vor der Ausführung des Befehls in der aktuellen Zeile erfolgt. Die aktuelle Zeile ist durch einen gelben Pfeil markiert.

Nun könnt ihr auch Registerinhalte verfolgen. Klickt dazu auf das I/O Symbol. Es geht das I/O Fenster auf. Klickt dort auf „I/O Port (Port B)“. Es taucht ein Unterfenster auf das den Zustand der Register PINB, DDRB und PORTB anzeigt. Um die Veränderung der Register in Abhängigkeit von der Programmzeile verfolgen zu können, löst das I/O Fenster aus seiner Verankerung und zieht es neben das main.c Fenster. Dann klickt weiter ein paar mal auf „Step Over“ und schaut was passiert: 

Ziemlich cool, finde ich. 

Nun verlassen wir mal den debugWire Modus. Dazu reicht es nicht aus auf Stop Debugging (rotbraunes Quadrat) zu klicken. Leider gibt es kein Symbol für diesen Vorgang. Geht stattdessen im Menü auf:

Debug  –> Disable debugWIRE and Close

Geht man nur auf „Stop Debugging“ und versucht dann im ISP Modus Einstellungen per Device Programming im ATtiny vorzunehmen, bekommt man komische Fehlermeldungen, die man nicht wirklich dem Umstand zuordnen kann, dass man sich noch im debugWire Modus befindet. Das hat mich anfangs des Öfteren ebenso verwirrt wie genervt. 

Variablen verfolgen und Breakpoints setzen

Um zu schauen, wie man Variableninhalte verfolgen kann, brauchen wir erstmal eine Variable in unserem Programm. Wir definieren eine (zugegebenermaßen ziemlich sinnbefreite) Variable x mit dem Startwert 0. An mehreren Stellen im Programm fügen wir ein x++ ein: 

/*
 * ATtiny85_Blink.c
 *
 * Created: 25.06.2019 18:30:08
 * Author : Ewald
 */ 

#include <avr/io.h>
#include <util/delay.h>
uint8_t x=0;

int main(void)
{
  DDRB = (1<<PB4);
  x++;
   
    while (1) 
    {
    x++;
    PORTB |= (1<<PB4);
    x++;
    //_delay_ms(1000);
    PORTB &= ~(1<<PB4);
    x++;
    //_delay_ms(1000);
    }
}

 

Startet das Programm wieder im debugWire Modus über „Start Debugging and Break“. Nach dem Break könnt ihr auf das Brillensymbol klicken. Ist Debugging noch nicht gestartet, ist das Brillensymbol ausgegraut. 

Mit dem Klick auf die Brille geht ein Fenster auf. Dort gebt ihr im Feld Expression „x“ ein und klickt auf „Add Watch“. Alternativ geht ihr mit einem Rechtsklick im Programmcode auf die Variable und wählt dann im Kontextmenü „Add Watch“. 

Jetzt könnt ihr mit „Step Over“ Schritten durch das Programm gehen und verfolgen wie x immer größer wird. 

Es nervt natürlich, wenn man immer alle delay Zeilen auskommentieren muss. Auch möchte man bei großen Programmen sicherlich nicht jede Zeile einzeln ausführen. Eine bessere Methode ist es Breakpoints zu setzen, also Punkte an dem das Programm im debugWire Modus stoppt. 

Einen Breakpoint setzt man, indem man ganz einfach auf den linken, grauen Streifen auf Höhe der gewählten Zeile klickt. Es erscheint ein roter Punkt. Man löscht einen Breakpoint, indem man einfach noch einmal draufklickt. 

Entfernt also die Auskommentierung der delay Zeilen, setzt einen oder mehrere Breakpoints und startet das Programm mit „Start Debugging and Break“. Dann klickt auf das grüne „Continue“ Dreieck. 

Ihr werdet sehen, dass das Programm am Breakpoint stoppt. Die Zeile, in der der Breakpoint steht, wird nicht mehr ausgeführt. Ein weiteres „Continue“ lässt das Programm bis zum nächsten Breakpoint weiterlaufen bzw. in diesem Beispiel bis das Programm wieder auf denselben Breakpoint trifft. 

Damit habt ihr nun eine gewisse Basis und könnt euch komplexeren Dingen zuwenden. 

Im nächsten Beitrag werde ich zeigen, wie man mit Atmel Studio 7 Debugging in die Arduino Welt zaubert, sozusagen beide Welten miteinander verbindet.