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 ;-)
Gast
#1586866
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.
Gast
#1586874
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.
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.
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.
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?
ich denke nicht das er nach einer diskussion gefragt hat. wir können uns gerne per pm darüber unterhalten.
Wenn der Poster mit PICs vertraut ist und was Groesseres moechte, waere allenfalls ein PIC32 passend.
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...
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
Gast
#1586984
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.
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.
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?part_id=2598 Peter
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.
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
Bitte melde dich an, um einen Beitrag zu schreiben.