Heute erzähle ich Ihnen meine Geschichte, wie ich zu den AVR-Controllern gefunden habe.

Ich als Funkamateur und Radiobastler hatte eigentlich nichts mit Mikroprozessor und Co. am Hut. Will man jedoch mit der technischen Entwicklung Schritthalten, kommt man einfach nicht um die Verwendung eines Mikrocontrollers herum, um die Bedienung und Steuerung des selbstgebauten Gerätes zu realisieren. Auch, wenn es nur ein Mini-Projekt ist.

Klar, es gibt eine Menge verschiedenster Controller-Typen und Konzepte.
Wofür sollte ich mich also entscheiden?

Meine erste Begegnung mit Mikroprozessoren hatte ich in den 80ern, mit dem allseits bekannten Z80. Ok, der Z80 (damals z.B.U880) ist ein reiner Mikroprozessor ohne interne Peripherie. Also, man musste die Peripheriebausteine wie z.b. RAM, EPROM, SIO, PIO und CTC extern anschließen.

Man brauchte aber wenigstens einen (EP)ROM als Programmspeicher und irgend einen IO-Baustein, damit man überhaupt etwas sinnvolles damit anstellen konnte. Letztendlich hatte man immer ein Board, auf dem der Mikroprozessor und seine Peripheriebausteinen Platz finden mussten. Also, keine Rede von minimaler Hardware.

Allerdings hatte der Mikroprozessor einen recht umfangreicher Registersatz (Register A, F, B, C, D, E, H, L, Index-Register IX und IY) incl. einem Tauschregistersatz für schnelle Interrupt-Bearbeitung.

Der umfangreiche CISC-Befehlssatz von ca. 150 Befehlen war auch nicht zu verachten.

Besonders bemerkenswert fand ich auch die SIO, die unter anderem eine Hartwareunterstützung des HDLC-Protokolls und CRC-Erzeugung und Prüfung bietet, und damit dem Prozessor einiges an Arbeit abnimmt.

Zugegeben, das ist doch alles Schnee von gestern. Oder?

Später tauchten immer mehr Geräte auf, die mit einem Motorola-Controller MC68HC11 oder MC68HC05 ausgerüstet waren. Also habe ich die Programmierung des MC68HC11 erlernt, und einige kleinere Projekte realisiert.

Der MC68HC11 verfügte intern über 256Byte RAM, 512Byte EEPROM und einen BOOT-ROM. Zur Programmabarbeitung standen zwei 8-Bit-Arbeitsregister A und B, und zwei Index-Register X und Y zur Verfügung. Weiterhin verfügte der Controller über 5 IO-Ports, Port A bis E.

• Der Port A steht hauptsächlich dem internen Timer-System zur Verfügung.
• Der Port B stellt 8 Ausgänge bereit.
• Der Port C stellt 8 Aus- oder Eingänge je nach Konfiguration bereit.
• Ãœber Port D ist das SPI (Serial Peripheral Interface) und SCI (Serial Comm. Interface) verfügbar.
• Port E stellt 8 A/D-Wandler-Eingänge bereit.

Der interne EEPROM (512 Byte) kann als Programmspeicher verwendet werden. Für kleinere Projekte ausreichend. Will man aber ein ganzes Gerät steuern, muss man auf externen Programmspeicher (EPROM) zurückgreifen. Dafür muss man Port B und C für den externen Daten- und Adressbus opfern. Für mich als Funkamateur und Radiobastler kam ein weiteres Problem hinzu. Nicht nur, dass man zwei Ports für den externen Daten- und Adressbus opfern musste, es strahlte auch der externe Bus ein breites störendes Rauschen bis in den UKW-Bereich hinein ab. Eine etwas unbefriedigende Situation, will man z.B. einen „Funkapparat“ damit steuern.

Auch nicht das Richtige!

Auf der weiteren Suche nach einem modernen Controller bin ich dann auf die 8Bit-RISC-Controller-Familien gestoßen. Es war nicht einfach zu entscheiden, welche Controller-Familie es nun sein sollte.

Ich habe mich nach einigen für und wider für die AVR-RISC-Controller-Familie entschieden.

Hier nun die 3 wichtigsten Argumente, warum ich mich für die AVR-8Bit-Controller entschieden habe.

• Die Befehlsausführungszeit von einem Oszillator-Takt-Impuls für einen Befehl, das bedeutet bei 10MHz-Takt, die Ausführung von 10 Millionen Befehle pro Sekunde !! (10 MIPS) Andere Controller benötigen mindestens 4 Takte für die Ausführung eines Befehls.

• Der Befehlssatz von über 100 Befehlen, der für RISC-Controller (Reduzierter Befehlssatz) doch sehr umfangreich ausfällt. Ein Umstand der mir sehr entgegen kam, als alter CISC-Programmierer.

• Die 32 fast gleichberechtigten Arbeitsregister, die direkt mit dem Rechenwerk (ALU) verbunden sind. Dadurch wurde das Nadelöhr des traditionellen Akkumulator-Register deutlich entschärft. Die Register r26 bis r31 kann man außerdem als Index-Register-Paare X, Y und Z verwenden. (optimal für Hochsprachen wie C usw..)

Am Ende hatte ich mir eine Menge Gründe zurechtgelegt, die meine längst getroffene Entscheidung für die 8Bit-AVR-RISC-Controller-Familie unterstützten sollen.

Also habe ich mir das AVR-Evaluations-Board STK500 gekauft.
Entweder richtig oder gar nicht, hab’ ich mir gedacht.
Ich habe es nicht bereut, das STK500 benutze ich heute noch.

Ich glaube, es muss jeder für sich entscheiden ob nun PIC, AVR oder was auch immer. Jeder Controller-Typ hat seine Vor- und Nachteile, und kann z.b. eine bestimmte Aufgabe besser lösen als andere Controller und umgekehrt.

Meine Entscheidung war ganz klar …8Bit-AVR!
Und der ATtiny2313 ist für meine gelegentlichen Miniprojekte die erste Wahl.

PS:
War diese kleine Geschichte hilfreich, oder eher nicht?
Benutzen Sie bitte die Kommentar-Funktion.

Incoming search terms:

• avr synthesizer
• avr pll
• pll mit atmega
• atmega pll
• atmel pll
• Entwicklungstool für MC68HC11
• hdlc avr
• pic avr besser für c geeignet
• phase locked loop atmega
• orcad ix iy