www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Horizont um Atmel erweitern. Fragen zu Unterschieden


Autor: Tajas R. (tony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Liebes Forum,

ich bin z.Z. am Überlegen, ob ich meinen Wissensschatz nicht um 
Erfahrungen mit den Atmel AVRs erweitern soll... Bis jetzt habe ich mit 
PICs gearbeitet und habe auch keine ernsthaften Probleme mit größeren 
Projekten. Zuletzt habe ich einen MP3-Wecker fertiggestellt, der den 
Zimmerlicht-Dimmer ansteuern kann.

Grund für die Erweiterung ist, dass es mir der Grasshopper angetan hat. 
Auch sonst scheinen AVRs teilweise besser zu sein: Größerer Befehlssatz, 
mehr MIPS/MHz und niedrigere Kosten und letztenendes ist dieses Forum 
hier ziemlich stark AVR-gebunden.

Meine Frage beläuft sich nun darauf, was man so beachten muss, also die 
größten Unterschiede.
Ein Beispiel, dass ich schon entdeckt habe:
Bei AVRs muss man für Inputs 0 schreiben, bei PICs eine 1.

Eine Sache, die mir zum Beispiel nicht gefällt ist, dass man zum setzen 
eines Bits den Umweg über Bitverschiebungen gehen muss:
DDR|=(1<<3)
oder so Ähnlich. Bei PICs geht das einfach per:
DDRbits.Bit3=1;

Kann man bei AVRs wenigstens für die I/Os Bitfelder nutzen und sind die 
verschiedenen Compiler so schlau dafür die entsprechenden Befehle SBI 
und CBI zu ersetzen?

Ich denke das wars soweit... Danke schonmal für alle konstruktiven 
Antworten.

P.S.: Es ist nicht meine Absicht hier wieder ein AVR <-> PIC gebashe 
anzuzetteln ;-)

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Grasshopper ist kein typisches Beispiel für einen AVR. Es handelt 
sich dabei um einen AVR32, mit ARM-ähnlicher 32-Bit Architektur. Das hat 
mit den hier im Forum oft diskutierten AVR (8-bit, ATMega / ATTiny usw.) 
nicht viel zu tun. Der Grasshopper ist ein komplexes System mit externem 
Speicher, Bootloader, Linux-Betriebssystem... Entwicklung von 
Anwendungen dafür ähnelt eher der Programmierung für einen kleinen 
Embedded-PC.

Ansonsten: Bei klassischen AVR setzt der Compiler den 
Bitschiebe-Befehl tatsächlich in sbi / cbi um. Bitfelder gehen 
standardmäßig nicht, soweit ich weiß. Vielleicht mit zusätzlichen 
Makros. Wenn man in C programmiert. Man kann natürlich auch reinen 
Assembler benutzen oder Assemblerschnipsel in C einfügen.
Beim AVR32 hingegen wird die I/O-Einheit interne Peripherie sein... da 
ist sowieso alles anders, und die Konfiguration der Ports wahrscheinlich 
über mehr als ein Register geregelt.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tajas R. schrieb:
> Auch sonst scheinen AVRs teilweise besser zu sein: Größerer Befehlssatz,
Eher nicht, nur wesentlich praktischere Auslegung des Befehlssatzes, als 
bei den alten PIC. Es muss z.B. nicht alles mit der Kneifzange durch ein 
einzelnes Arbeitsregister gezogen werden.

> Bei AVRs muss man für Inputs 0 schreiben, bei PICs eine 1.
Nun, dafür gibt es Datenblätter. Das ist jetzt eigentlich kein 
Unterschied, der sonderlich erwähnenswert ist.

> Eine Sache, die mir zum Beispiel nicht gefällt ist, dass man zum setzen
> eines Bits den Umweg über Bitverschiebungen gehen muss:
> DDR|=(1<<3)
> oder so Ähnlich. Bei PICs geht das einfach per:
> DDRbits.Bit3=1;
Das hat nichts mit den AVR zu tun, sondern mit dem C-Compiler. 
Einerseits lässt sich das Verhalten wie bei den PIC mit einem Trick auch 
erreichen, andrerseits ist es nach ISO-C recht unportabel.

> Kann man bei AVRs wenigstens für die I/Os Bitfelder nutzen und sind die
> verschiedenen Compiler so schlau dafür die entsprechenden Befehle SBI
> und CBI zu ersetzen?
S.o.; bring es dem Compiler bei. Es lässt sich mit Bitvektoren 
arrangieren, wenn man weiß, wie der GCC diese intern anlegt.

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rein als frage, von welchen pics sprichst du?

das XYZbits.XYZ1 spricht mal für >=PIC18

eventuell siehst du dich bei den 24er und 32ern um.

der AVR32 ist kein wirklicher mikrocontroller mehr.

Auch die kleinen ARM könnten für dich interessant sein.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:

> der AVR32 ist kein wirklicher mikrocontroller mehr.

Sondern? Mikrocontroller: Integration von Prozessor, Peripherie und 
ganzem oder teilweisem Speicher in einem IC. Ob das ein 8-Bit oder ein 
32-Bit Prozessor ist, das ist nicht relevant.

Autor: Tajas R. (tony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die kleineren ARM möchte ich mir früher oder später auch zu gemüte 
führen. Das kommt also auch noch ;-) Wie lautet denn der Trick mit den 
Bitvektoren? Gibt es denn noch nennenswertes, das man wissen muss?

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke nicht das er nach einer diskussion gefragt hat.

wir können uns gerne per pm darüber unterhalten.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der Poster mit PICs vertraut ist und was Groesseres moechte, waere 
allenfalls ein PIC32 passend.

Autor: Tajas R. (tony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber mich stört etwas die fehlenden Bibliotheken etc. Für einen 
PIC32 müsste ich erst einen passenden Kernel kompilieren und viel Zeit 
und Geld in Beispielsweise Display-Routinen stecken.
Beim Grasshopper z.B. ist die meiste Arbeit bereits getan...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tajas R. schrieb:
> Beim Grasshopper z.B. ist die meiste Arbeit bereits getan...

Ne, der Grashopper ist nicht das, was 99% unter einem AVR verstehen.
Das ist ein spezieller 32-Bitter und tritt gegen die ARM-Familie an. Ob 
er dabei ne Zukunft hat, wer weiß.


Der bekannte AVR ist ein 8Bitter und geht von Attiny13 (1kB/8Pin) bis 
ATmega2560 (256kB/100Pin).
Und relativ neu die Xmega-Serie, sind zwar Befehls-kompatibel, aber mit 
eingeschränkter VCC (nicht 5V tauglich).


Der Grashopper ist auch preislich ne anderen Region, die 8Bit-AVRs gibts 
ab <1€ in Einzelstückzahlen.


Peter

Autor: Zacc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Displayroutinen ... soll das ein Witz sein ? Eine Displayansteuerung 
sollte man eh selbst schreiben, ist eine Frage von einer halben Stunde 
oder so.

Nicht, dass ich den AVR32 ausreden will, ist eine super Maschine, die 
ich selbst verwende.

Autor: Tajas R. (tony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch durchaus schon eigene Display-Routinen geschrieben... Aber 
das Ganze dann noch in eine Linux-Framebuffer Treiber zu packen bzw. es 
kompatibel zu machen ist einiges an Arbeit...

Und ich möchte natürlich mit den kleinen AVRs anfangen und erst später 
mit den großen arbeiten.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tajas R. schrieb:
> Zuletzt habe ich einen MP3-Wecker fertiggestellt, der den
> Zimmerlicht-Dimmer ansteuern kann.

Atmel hatte auch mal nen 8Bitter (8051-Derivat) mit MP3 im Programm, 
scheint aber nicht mehr gefragt zu sein (Not recommended for new 
designs):

http://www.atmel.com/dyn/products/product_card.asp...


Peter

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab viel mit PIC16Fxxx und PIC 10Fxxx gearbeitet, mit CCS 
PICC-Compiler.

Dann habe ich mit kleinen ATmegas und Codevision anfangen müssen und 
denke nur: DANKE!
Für mich sind einige Sachen bei der AVR/Codevision Kombi deutlich 
besser, vor allem das Interrupt-Handling. Außerdem haben die ATmegas ein 
bischen nettere Hardware integriert - nach meinem Geschmack.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tajas R. schrieb:
> Kann man bei AVRs wenigstens für die I/Os Bitfelder nutzen und sind die
> verschiedenen Compiler so schlau dafür die entsprechenden Befehle SBI
> und CBI zu ersetzen?

Ja, kein Problem.
Hier ein Beispiel für ein Text-LCD:

http://www.mikrocontroller.net/attachment/30300/lcd_drv.zip


Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.