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
• hdlc avr
• 8 bit synthesizer avr
• pll with atmega
• pll atmega1284
• pic avr besser für c geeignet
• phase locked loop atmega

ElTono sagt:

Für PLL-Synthesizer ist die Atmel Tiny Serie sicherlich geeignet, da sie teilweise einen internen Oszillator besitzen und damit keinen externen Quarz benötigen. Zudem besitzen sie eine sehr geringe Stromaufnahme. Für andere komplexere Anwendungen, wo Strom keine Rolle spielt, ist sicherlich ein Cortex M3, M0, M4 die bessere Wahl.

kemitten sagt:

aus den vielen µControllern-typen ist es tatsächlich sehr schwierig, für sich selber das “beste system” zu finden, zumal ja auch einiges an tools beschafft werden muss…AVR ist auch meine wahl, da mit AVR-Studio ein kostenloses entwicklungstool für die controller angeboten wird (was es für PIC und co auch gibt)…entscheidend war aber auch bei mir der umfangreiche befehlssatz mit der möglichkeit einer “feineren auflösung” bei der programmierung und die vielen foren-hinweise zu vielen themen…wäre prima, wenn nach ihrem PLL-Kurs dieses thema auf den AVR portiert wird…

Nordlicht sagt:

auch Ich hab jahrelang mit dem Z80/8085 experimentiert.
Mittlerweile hat sich einiges getan.
Gestern hab ich Nägel mit Köpfe gemacht und den “AT AVR ISP” von Atmel bestellt. Einen STK500 wäre auch nicht schlecht gewesen, aber meistens hacke ich in bestehenden Systeme rum und mit dem AVR Studio arbeitet das System auch gut zusammen.
Für meine Bedürfnisse reicht das.
Durch eine eBay Auktion hab ich noch über 150 !!! 68HC11A8
liegen, die werde ich wohl verfüttern müssen

admin sagt:

Danke für alle bisherigen Kommentare!

Hallo Nordlicht, da hast du dir ja doch was richtiges besorgt, und nicht dieses simple Evaluations-Board, welches du zuerst ins Auge gefasst hattest. Gute Entscheidung.
Wie geht das Relais-Projekt voran?

VLF Spezi (U-Boot Fahrer) sagt:

Moin Moin!
Nun scheint es ja zu fuktionieren.
Diese Probleme kenne ich auch.

Ich war so weit blickend, das ich mir damals (80er) ein
Hard u. Softweare Upgrate Paket für meinen Damals Schweine Teueren C64 geholt hatte.

Ein Modul für entweder nur Radio oder zum senden / Antenne Drehen.
sofweare für Poketradio, Wetter fax,Tele fax, Telex, usw.
dann noch ein Modul fürs Senden

das wurde in den 80er unter der Bez. Bonico RCA vertrieben
ich kann es nur Empfehlen die Firma macht jetzt 1a . Prog.
für Pc.

Nordlicht sagt:

Hallo Uwe und Interessierte

Ich wollte etwas universelles haben, natürlich wäre der STK besser gewesen wenn man erst das ganze vorher simulieren möchte. Ich hab mir bei Pollin dazu das AVR NetIO- Board bestellt und gleich den Atmega644 dazu.
So hab ich gleich ein “Bastelobjekt”. Das einzigste Problem ist das “AVR Studio”. Ich hab bis auf einen Rechner nur Linux als Betriebssystem am laufen.

Apropo Relais, das dudelt vor sich hin(da Ersatzrelais).

Ich muß noch NF- Filter sowie einen Begrenzerverstärker entwickeln der den Hub auf maximal 2,5 Khz beschränkt.

Alex sagt:

Hallo,

das meiste verstehe ich leider nur am Rande…Register? I / O Ports, 8Bit 10Bit? RISC? Alles sicher schonmal gehört und nachgeschlagen. Ich als Unwissender in Sachen Controller will hier auch nicht kritisieren, dafür fehlt mir einfach das Wissen. Vor einiger Zeit habe ich mal mit Conrads C-Control rumgespielt, und da sogar noch mit ner graphischen Oberfläche. Irgendwann habe ich dann schnell gemerkt, dass man damit leider irgendwann an gewissen Grenzen stößt. Schön fand ich hingegen den einfachen Einstieg. Alleine solche einfachen Begriffe wie PORT und INTEGER und der Unterschied zwischen seriell und parallel konnte so schnell fühlbar verstanden werden. Auf der Suche nach nem neuen Konzept bin ich dann allerdings stehen geblieben. In der Zwischenzeit habe ich dann noch diese Site gefunden:http://www.sprut.de/electronic/pic/ Zwar gehts hier speziell um PICS, aber gerade die Begrifflichkeiten werden hier ganz schön erklärt Achja, nen Z80 kenne ich auch noch, allerdings nur von TNCs. Vielleicht setze ich mich doch mal mit der ganzen Thematik mehr auseinander, und berichte von meinem Weg zum “idealen” Controller.

admin sagt:

Hallo Alex,
ich danke dir herzlichst für deinen, und für mich sehr aufschlussreichen Kommentar.

Wir hatten uns ja schon recht intensiv zum Thema PLL-Crashkurs per Mail unterhalten, und ich durfte auch an deinen Aha-Erlebnissen in Sachen PLL teilhaben.

Ich möchte nun in Zukunft etwas mehr zum Thema „PLL-Synthesizer steuern mit AVR-Controller“ (oder so ähnlich) bringen. Ich bin aber noch auf Meinungs- und Ideensuche.
Ich bin also selbst gespannt, in welche Richtung sich die Sache PLL-Synthesizer und Controller hier entwickeln wird.

PS:
Kommt eigentlich Dein Messplatz-Projekt voran? Du wolltest doch mal dazu Berichten.

Jan sagt:

Seit 2006 arbeite ich auch beruflich mit dem AVR Atmega8, Atmega16. Für die Einführung der Atmel-RISC Controller an meinem Arbeitsplatz hatte ich die gleichen Gründe, die Uwe oben auch schon benannte. Sehr entscheidend waren für mich auch kostenlose Softwaretools (AVR-Studio, PonyProg)und billige Evalations-Boards. Im Internet ist auch viel hilfreiche Literatur zu finden, die mir den Einstieg erleichterte und mir bei der Fehlersuche half, wenn es mal nicht gleich funktionierte.
Seit dem setze ich diese uP’s für allgemeine regelungstechnische Aufgaben und bei HF-Messdatenübertragungssystemen ein und bin sehr zufrieden.

Matthias sagt:
16. Mai 2013 um 00:27 Uhr

Huhu! Ich habe den Artikel gelesen und bin sehr interessiert. Habe auch bei Pollin so etliche µCs mir zugelegt, aber noch nix damit gemacht, weil ich mich einfach nicht traue, weil ich vieles nicht kapiere… Zwar kenne ich Begriffe wie “integer, interrupt, MOSI, MISO, RISC, etc. blabla pp…”, aber wenn ich angefangen habe ein Buch zu µCs zu lesen, habe ich schon immer sehr schnell gestreikt… Ich finde da keinen Anfang! Ich verstehe einfach nicht, wie man so ein nackiges Ding dazu bringt, diesen oder jenen Pin als In- oder Out – Port zu definieren, wo es doch zuerst programmiert werden muss, dass der oder die Ports In oder Out sind… Aber unbedingt will ich cdas lernen. Weil ich schon sehr viel Sachen mit CMOS, TTL, OPs gebastelt habe, aber nie gross mit µCs.

Uwe sagt:
17. Mai 2013 um 17:11 Uhr

Hi Matthias,
manchmal scheinen kleine Hürden unüberwindlich zu sein.
Ich antworte mal direkt per Mail.

Gruß Uwe