Als Person, die nichts mit Mikrocontrollern am Hut hat, fragt man sich ja immer, was für eine Wissenschaft das eigentlich ist. Man hört von gefährlichen Fusebits, kaputtgeflashten Chips, hat vielleicht auch schonmal jemanden mit ISP/JTAG-Gedöns rumfummeln sehen und stellt insgesamt fest, dass das alles unheimlich kompliziert aussieht.

Das schöne an der Sache ist: Wenn man sich erstmal mit beschäftigt, merkt man schnell, dass es viel simpler ist, als man denkt. Genaugenommen sind die ersten Schritte dank Internet, insbesondere mikrocontroller.net sehr einfach.

Programmer und Chips

Zunächst mal vorweg: Alles folgende bezieht sich auf die Atmel AVR-Prozessoren.

An AVR-Programmier- und -Testboards gibt's mehr als genug, z.B. das Arduino-Projekt. Da kann man sich irgendwas aussuchen, von dem bekannt ist, mit welchen Methoden welche Arten von Chips programmiert werden können. Aus der Menge der programmierbaren Chips besorgt man sich ebenfalls ein paar Stück und schon kann man loslegen.

Es ist übrigens auch möglich, AVR-Chips direkt am LPT-Port zu programmieren, für den Anfang ist ein fertiges Board aber deutlich empfehlenswerter. Da hat man nämlich ein paar LEDs und Taster am µc dranhängen, so dass man direkt rumspielen kann, ohne erst eine Schaltung zu löten.

Atmelboard von Pollin

In meinem Fall wurde es das Atmel-Evaluationsboard. Das ganze gibt's als Bausatz oder auch Fertigmodul, und mikrocontroller.net und der Entropia haben auch Artikel darüber.

Das Atmelboard von Pollin unterstützt mehrere verschiedene AVR-Typen, ich hab mir ein paar ATtiny2313-Chips geholt, mit 1.95 Euro pro Chip kann man bei denen nicht viel falschmachen. So ein ATtiny ist zwar sehr eingeschränkt (2kB ROM, 128 Byte RAM, 128 Byte EEPROM), aber für erste Testprogramme reicht er locker, und später wird man ohnehin feststellen, dass auf so einen µc viel mehr draufpasst, als man denkt.

Software

Wenn man nun sein Board hat, braucht man die nötige Software, i.d.R. reicht es dazu aus, avrdude und avr-libc (sollten gcc-avr und binutils-avr mitziehen) zu installieren. Ziel ist jedenfalls, dass man einen funktionierenden Compiler für den AVR-Plattform (gcc-avr) und ein Proramm zum Flashen des Chips (avrdude) hat.

Vorbereitung

Für alles weitere empfiehlt sich auch sehr, einfach mal durch AVR-Tutorial und AVR-GCC-Tutorial durchzuklicken, da steht alles (und noch viel mehr), was man wissen muss.

Man kann schonmal einen Chip in den Programmer stecken und ihn an Strom und PC anschließen. Je nach Interface (USB / Seriell) wird er meist als /dev/ttyUSB0 oder /dev/ttyS0 angesprochen. Beim Pollinboard ist unbedingt zu beachten, dass das serialle Kabel an den ISP-Anschluss und nicht RS232 kommt. Letzterer macht nichts kaputt, tut aber auch nichts für uns.

Nun fehlt nur noch eine Methode, um Code zu kompilieren und auf den AVR zu spielen, und etwas Code zum Testen.

Ich selbst bevorzuge C-Code, welcher mittels eines Makefiles kompiliert und dann (ebenfalls vom Makefile) auf den µc programmiert werden kann. Siehe dazu Beispiel Makefile. Ich verwende die korrigierte Fassung aus dem Artikel (direktlink).

Man muss in dem Makefile nur noch drei Dinge einstellen: Den verwendeten Chip (MCU), den Programmer (AVRDUDE_PROGRAMMER) und den Port (AVRDUDE_PORT). Für meine Konstellation wäre das:

MCU = attiny2313
AVRDUDE_PROGRAMMER = ponyser
AVRDUDE_PORT = /dev/ttyS0

Dinge tun!

Damit wäre die Vorbereitung fertig. Für einen ATtiny auf dem Pollinboard gäbe es noch dieses simple Testprogramm (main.c):

#include <avr/io.h>

int main (void) {

    DDRD = (1 << PD5);
    PORTD = (1 << PD5);

    while (1);

    return 0;
}

Dieses Programm mit make kompilieren und anschließend mit make program auf den AVR übertragen lassen. Man sieht nun jede Menge Ausgaben von avrdude, ganz unten sollte jetzt stehen, dass alles geklappt hat.

Das Programm tut nichts anderes, als den I/O-Pin PD5 auf Output zu setzen, einzuschalten und dann zu loopen. Auf dem Board ist an PD5 eine LED angeschlossen, diese sollte nun leuchten.

Das war's dann auch schon. Falls der Controller funktioniert ist alles schön, falls nicht einfach mal auf mikrocontroller.net und in den Kommentaren des Makefiles rumwühlen, wahrscheinlich stimmt irgendeine Einstellung nicht. Ich selbst kam in das Glück, nicht debuggen zu müssen.

Und so weiter

Für alles Weitere (und sehr gute Erklärungen dazu, was die einzelnen Codezeilen des Beispiels genau tun) sei noch einmal auf das AVR-GCC-Tutorial ( sowie sämtliche andere Artikel auf der Seite :p ) verwiesen. Das Tutorial behandelt im Gegensatz zu meinem Blogpost auch so ziemlich alle Methoden, mit denen man was tun kann.

Man sieht jedenfalls, dass "Mikrofoo" eigentlich ziemlich simpel ist, man sollte sich nur nicht von der Länge der Howtos oder den Fachbegriffen erschlagen lassen.

Ein Wort zu Fuses noch: Solange man einfach nur rumspielt, kann man die meist komplett ignorieren. Somit hat man auch keine Möglichkeiten, seinen Controller kaputtzuflashen, schlimmstenfalls hängt man ihn durch einen Programmierfehler auf, was mit 'nem einfachen Reset / Flashen einer korrigierten Programmversion behoben wird.