Chipwahl für ATMEL-Umsteiger

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
Hallo Group!

Ich hab vor einiger zeit angefangen µC's zu programmieren und damit herum zu
experimentieren. Leider ist mir vor kurzem durch irgendwelche unerklärlichen
Umstände mein Board mit dem 80C517A (Feger-Board) eingegangen. Nun würde ich
gerne auf die günstigeren ATMEL AVR's umsteigen. Auf der Suche nach einem
Chip der mir gefalle würde bin ich auf den ATmega8535 gestoßen der mir sehr
gefalle würde (bezüglich Ausstattung mit PWM, ADC, Timer, Preis, usw. für
zukünftige Sachen). Nun würde ich gerne wissen was ihr von diesem Controller
haltet oder ob ihr mir einen anderen empfehlen würdet?? Weiters wäre
interessant welches Programmierinterface besser wäre: das parallele oder das
serielle??
Ich freue mich schon auf eure zahlreichen kommentare.

MFG
Fuchs Michael



Re: Chipwahl =?ISO-8859-15?Q?f=FCr?= ATMEL-Umsteiger

[...]
Quoted text here. Click to load it

Ich mag AVR, sehr angenehm zu programmieren. Es gibt hier aber auch
andere Meinungen -> http://groups.google.com

Quoted text here. Click to load it

Also erstmal das übliche:
- Datenblätter bei http://www.atmel.com
- Gute Seite für Anfänger http://www.avrfreaks.com
- GCC-Compiler + Programmiersoftware für Windows
 http://winavr.sourceforge.net

Parallele Programmierung geht nur, wenn der Chip nicht in der
Schaltung ist. Ist also eher für Massenfertigung gedacht.
Die Frage ist also eher seriell (SPI) oder JTAG. Für den Anfang muß es
IMO kein JTAG sein.

Falls Du ein fertiges Board kaufen willst, solltest Du Dir den mega128
angucken. z.B
http://www.bdmicro.com
http://www.ethernut.de
Habe keines dieser Boards selber benutzt oder auch nur gesehen.

Ansonsten finde ich den mega8 noch ganz knuffig. Ist bei Reichelt aber
teurer als der mega8535 ;-(

 Jan-Hinnerk


Re: Chipwahl für ATMEL-Umsteiger

Quoted text here. Click to load it

Mehr Ressourcen haben zum Experimentieren noch nie geschadet. ;-) Nimm
das Größte, das Du Dir dafür leisten kannst, nach Möglichkeit also
ruhig einen ATmega128.  Hast noch paar Portpins mehr, genügend ROM, um
Dir auch um Floatingpoint, malloc() und printf() erstmal keine Sorgen
machen zu müssen, genügend RAM für den Alltag (und die Möglichkeit, im
Gegensatz zum ATmega8535 trotz vorhandenen ADCs auch noch externen RAM
dranzuklemmen) usw. usf.

Wenn Du Dir das nicht leisten kannst, dann skaliere nach unten, bis es
Dir gefällt.  Aber wenigstens ein ATmega16 sollte wohl nicht das Thema
sein, oder?  Einziger Nachteil gegenüber dem ATmega8535 ist, daß man
für 16 KB keine RJMP/RCALL mehr nehmen kann, der avr-gcc schaltet
derzeit dann komplett auf JUMP/CALL um, was etwas Platz verschwendet.
Ein identisches Programm fällt damit also größer aus als auf einem
ATmega8535.

Wenn Du das Board für den TQFP des ATmega128 nicht selbst machen
willst und das Dein einziges Argument ist zugunsten eines kleineren
AVR, der noch als DIL erhältlich ist: Experimentierplatinen werden
vielfältigst angeboten für AVRs, auch unbestückt.  Keine Angst vorm
SMD-Selbstlöten, das ist weniger schlimm, als es auf den ersten Blick
aussieht.  Du mußt es ja nicht gleich übertreiben und ein BGA-Gehäuse
selbst löten wollen wie Georg Acher. ;-)

Quoted text here. Click to load it

Parallel braucht kein Mensch mehr bei den heutigen Chips.  Ganz zu
Anfang gab's noch Chips, bei denen man bestimmte Fuses nur parallel
manipulieren konnte, aber das ist bei den aktuellen AVRs
Vergangenheit.
--
J"org Wunsch                           Unix support engineer
joerg_wunsch@interface-systems.de        http://www.interface-systems.de/~j /

Re: Chipwahl für ATMEL-Umsteiger

Quoted text here. Click to load it

Zusätzlicher Vorteil: ab ATmega16 gibt's ein JTAG-Interface, mit dem
man auch on-chip debuggen kann.
--
J"org Wunsch                           Unix support engineer
joerg_wunsch@interface-systems.de        http://www.interface-systems.de/~j /

Re: Chipwahl für ATMEL-Umsteiger
snipped-for-privacy@gmx.at says...
...
Quoted text here. Click to load it
...

Michael,

Ich würde den 8535 nicht nehmen. Atmel hat schon angekündigt, das dieser
in absehbarer Zeit eingestellt wird (end of life).
Mir gefällt der Mega8 sehr gut, er ist günstig, hat aber trotzdem die
volle ausstattung (adc, pwm, timer, etc). Auch ist er im DIL gehäuse
erhältlich, was zum Hausgebrauch einfach zu löten ist. Ich programmiere
ihn mit Ponyprog und einem Simpel-Interface (1 Transistor + 3
Widerstände).

Eine sehr gute Auskunftsquelle: ist www.avrfreaks.net

Markus
--
  Markus Baertschi             Phone: ++41 (21) 807 1677
  Bas du Rossé 14b             Fax  : ++41 (21) 807 1678
We've slightly trimmed the long signature. Click to see the full one.
Re: Chipwahl für ATMEL-Umsteiger

Quoted text here. Click to load it
einem
sehr
für
Quoted text here. Click to load it
Controller

Hallo
richtig, 8535 ist abgekündigt, aber nicht der
MEGA8535

Ich würde auch lieber etwas größere nehmen, ich versuche gerade
die Software für ein Motortestgerät in ein Mega8535 zu kriegen,
...wird verdammt eng.
Ich benutze aber auch nur Bascom AVR , mit AVR-GCC würde
es bestimmt kleiner, oder ?

Gruß
Falko



Re: Chipwahl für ATMEL-Umsteiger
Quoted text here. Click to load it
Da hast du recht. Die beiden recht vergleichbar bis auf die etwas mehr
pins des 8535 und dem entsprechend gösseren Gehäuse.
Quoted text here. Click to load it
Ich glaube nicht. Der GCC-compiler is nicht schlecht, nützt aber nicht
immer alle features des AVR optimal aus. Da kommt schon mal etwas
Ballast zusammen.
Wenn du kompakten Code brauchst bist Du mit einem der kommerziellen
Compiler besser dran (Imagecraft, Codevision). Das ist jedenfalls den
Eindruck, den ich nach 2-Jährigen mitlesen auf AVRFreaks habe...

Markus
--
  Markus Baertschi             Phone: ++41 (21) 807 1677
  Bas du Rossé 14b             Fax  : ++41 (21) 807 1678
We've slightly trimmed the long signature. Click to see the full one.
Re: Chipwahl für ATMEL-Umsteiger

Quoted text here. Click to load it


Das deckt sich überhaupt nicht mit dem, was ich als Eindruck gewonnen
habe.  Zu beachten ist dabei übrigens, daß gerade auf AVRFreaks eine
Menge and DAUs herumlungern, da sind Leute dabei, die nichtmal die
simpelsten Grundlagen der Programmierung oder von C beherrschen und
dann erwarten, daß ihnen alles löffelfertig vorgesetzt wird.  Solche
Leute sind wahrscheinlich in der Tat mit einem kommerziellen Compiler
besser bedient, wenigstens belasten sie dann deren Support
stattdessen. :-))

Die Kommerziellen glänzen mit schicken GUIs, in die alles verpackt
ist, keine Frage, während ein gcc von Haus aus sowas nicht mitbringt
(gehört ja auch nicht zum Compiler).  Aber Entwicklungsumgebungen, an
die man einen Kommandozeilencompiler anflanschen kann, gibt's einige,
Eric Weddington liefert mit WinAVR das Programmer's Notepad mit, das
er offenbar selbst bevorzugt.  Ich habe mich in über 10 Jahren an den
Emacs gut genug gewöhnt und muß mich nicht mehr umstellen, egal ob ich
einen AVR programmiere, eine email oder diesen Newsartikel schreibe,
irgendwas in meinem FreeBSD programmiere oder einen Brief in LaTeX
schreibe.  So hat jeder seine persönlichen Vorlieben.

Der gcc leidet im Umfeld des AVR ein wenig darunter, daß er praktisch
ausschließlich auf eine von-Neumann-Architektur orientiert ist, so daß
in einer Harvard-CPU die verschiedenen Speicherbereiche nicht ohne
weiteres adressiert werden können.  Die kommerziellen Compiler haben
dies von vornherein berücksichtigt und können daher leichter mit
Konstanten im ROM oder Daten im EEPROM umgehen.  Wenn ich mir
allerdings die Verrenkungen in Atmel's AVR butterfly Code ansehe, die
dann teilweise doch noch zu machen sind, um den Compiler davon zu
überzeugen, daß vielleicht ein bestimmter Tabellenzugriff jetzt als
ROM und nicht als RAM gemeint ist, dann bin ich mir mittlerweile da
gar nicht mehr so sicher, ob man das wirklich uneingeschränkt als
Vorteil ansehen sollte.  Beim avr-gcc muß man halt die ROM-Zugriffe
explizit selbst vornehmen, dafür bekommt man dann immer exakt das, was
man aufgeschrieben hat.  (Der generierte Code dürfte sich kaum
unterscheiden, auch der IAR muß ja am Ende [E]LPM Befehle dafür
benutzen.)

Von den Kommerziellen dürfte der IAR eindeutig die Nase vorn haben,
kein Wunder, wurde und wird dieser Hersteller von Atmel seit eh und je
bevorzugt (und durfte bereits beim CPU-Design mitwirken, um es besser
hochsprachentauglich zu machen -- aber davon haben zum Glück alle
Compiler etwas).  Der IAR hat einige Optimierungen, die in der Tat ein
gutes Stück besser sind als der avr-gcc, insbesondere kann er JMP/CALL
durch RJMP/RCALL ersetzen, was halt gerade bei 16 KB Chips einiges an
Ersparnis bringen kann.  (Allerdings hat Denis Chertykov vorgestern
auf der Mailingliste geschrieben, daß der GNU Linker das auch könnte,
er hat nur keine Zeit, das gerade zu implementieren.  Wird aber sicher
nur noch eine Frage der Zeit sein, bis das jemand anpackt.
Möglicherweise wäre gcc damit sogar besser als IAR, da ich bei IAR den
Eindruck habe, daß dort diese Optimierung nur auf Compilerebene
vorgenommen werden kann.  Auf Linkerebene hingegen profitieren auch
alle Bibliotheksfunktionen usw. davon.)

Die anderen Compiler sind dem Vernehmen nach in der Codegenerierung
gleichwertig oder eher ein bißchen schlechter als avr-gcc.
--
J"org Wunsch                           Unix support engineer
joerg_wunsch@interface-systems.de        http://www.interface-systems.de/~j /

Re: Chipwahl für ATMEL-Umsteiger

Quoted text here. Click to load it

Ist die Frage, ob Du erstmal eine Experimentierplatine haben willst
und danach dann die, mit der die Motorsteuerung tatsächlich laufen
soll.  Zum Experimentieren ist ein großer Controller immer praktisch,
für eine Serienproduktion kann man das dann optimieren, wenn alles
erst einmal tut, was man sich vorgenommen hat.  Wobei die Frage ist,
ab welcher Seriengröße es sich denn überhaupt rechnet, die jeweils
kleineren Chips zu benutzen.  So riesig sind ja bei Mengenabnahme
die Preisunterschiede ohnehin nicht, die Kosten für die Software und
das Board dürften bei kleinen Stückzahlen allemal überwiegen.

Quoted text here. Click to load it

Keine Ahnung, wie gut Bascom's Compilate und Organisation der
Bibliothek ist.
--
J"org Wunsch                           Unix support engineer
joerg_wunsch@interface-systems.de        http://www.interface-systems.de/~j /

Re: Chipwahl für ATMEL-Umsteiger

Quoted text here. Click to load it

Oder schau Dir mal die MSP430-Familie von Texas Instruments
www.ti.com/msp430 (auch bei reichelt) an. In Bezug auf die
"Rechenpower" wohl etwas schwachbrüstiger als die AVR's (imho aber voll
ausreichend) dafür aber Weltmeister im Stromsparen, z.B. eine ständig
mitlaufende Uhr (real time clock) kann man mit 2-3uA Stromverbrauch
realisieren, PWM, ADC usw. auch alles drauf. Als Parallele zum 8535
kann man wohl den MSP430F133 betrachten.
Kann per Boostraploader über eine normale RS232 programmiert werden,
JTAG ist auch vorhanden, C-Compiler MSPGCC ...

M.



Re: Chipwahl für ATMEL-Umsteiger

Quoted text here. Click to load it

Es gibt Dutzende von Applicationnotes (siehe Website) samt Beispielen,
etliche Veröffentlichungen und Freewareprojekte. Ist zwar nicht ganz so
umfangreich wie beim AVR, aber doch dicke ausreichend. Übrigens der
MSP430 wurde urspruenglich in .de entwickelt und irgendwann von ti
gekauft (soviel zum Lokalpatriotismus :-).

M.

Re: Chipwahl für ATMEL-Umsteiger
snipped-for-privacy@despammed.com (Aguja) wrote in

Quoted text here. Click to load it

Ich habe mich damit noch nicht selbst im Detail beschäftigt, in der
mspgcc mailingliste war da aber mal eine Diskussion, da hatte jemand
ein paar Benchmarks auf beiden laufen lassen und auch Taktzeiten usw
durchgerechnet, wobei die Atmegas besser abschnitten. Kann aber auch am
damals noch nicht so ganz ausgereiften mspgcc gelegen haben...

Atmel selbst zieht auch einen Vergleich:
http://www.atmel.com/ad/fastavr/megaavr_analysis.pdf
Der MSP ist also wegen dem maximal möglichen Takt langsamer und braucht
angeblich 20% mehr Flashplatz für Programme...; andere "Nachteile"
fallen imho nicht ins Gewicht; man kann diese ja auch umgehen ;-). z.B.
kein ADC in den 20pol Varianten; na klar per software und den on chip
comparator bekommt man sogar 12bit hin; die JTAG fuse brauch ich
einfach nicht zu zerstören; andererseits ist man aber auf der sehr
sicheren Seite, das das JTAG disabled ist, damit kann damit kein Unsinn
mehr angestellt werden; kein interner EEPROM (stimmt imho so nicht) usw
usf :-)

Einige der Features, die negativ fuer den MSP430 aufgeführt werden,
sind aber mit der neuen 15x Serie behoben (brown out protection).
Andererseits sind auch die Atmels jetzt stromsparender geworden.

M.

Re: Chipwahl für ATMEL-Umsteiger
On Tue, 2 Sep 2003 14:22:14 +0000 (UTC), snipped-for-privacy@pentax.boerde.de

Moin!

Quoted text here. Click to load it


Toller Vergleich, oder hab ichs mit den Augen? Multiplikation und
Division hab ich jedenfalls nicht in der Tabelle gesehen. Und da
braucht der AVR immerhin 34 Takte für eine 8bit*8bit Multiplikation,
bis hin zu 255 Takten für eine 16bit/16bit Division. Da helfen auch
16MHz nicht drüber weg.

http://www.atmel.com/dyn/resources/prod_documents/DOC0936.PDF

Gruß,
Michael.

Re: Chipwahl für ATMEL-Umsteiger
Quoted text here. Click to load it
Die ATmega-Serie, welche die z.T. schon abgekündigten Controller der
AVR-Reihe ersetzen (z.T. pinkompatibel zu den Vorgängertypen), haben
alle Hardware-Multiplikation on chip.

Thomas.

Re: Chipwahl für ATMEL-Umsteiger

Hi!

Quoted text here. Click to load it

Oh, gut zu wissen.
Ich sag aber trotzdem nicht "sorry, mein Fehler", weil ich eben die
genannte AN unter atmel.com -> mega128 -> more application notes
gefunden hab :-)

Gruß,
Michael.

Re: Chipwahl =?ISO-8859-15?Q?f=FCr?= ATMEL-Umsteiger

Quoted text here. Click to load it

Die Divisionsroutinen in dieser AppNote sind großer Müll ;-)))
16bit-unsigned geht in maximal 203 Zyklen (ohne return) durch
8bit-unsigned in 67. Beides nach Codegröße optimiert.

Falls jemand nachzählen will:

;***** Subroutine Register Variables

.def    drem8u  =r15            ;remainder
.def    dres8u  =r16            ;result
.def    dd8u    =r16            ;dividend
.def    dv8u    =r17            ;divisor
.def    dcnt8u  =r18            ;loop counter

;***** Code

div8u:  sub     drem8u,drem8u   ;clear remainder and carry
        ldi     dcnt8u,8        ;init loop counter
d8u_1:  rol     dd8u            ;shift left dividend
        rol     drem8u          ;shift dividend into remainder
        sub     drem8u,dv8u     ;remainder = remainder - divisor
        brcc    d8u_3           ;if result negative
        add     drem8u,dv8u     ;    restore remainder
d8u_3:  dec     dcnt8u          ;decrement counter
        breq    d8u_1           ;if done
        rol     dd8u,8          ;shift left dividend
        com     dres8u
        ret


 Jan-Hinnerk



Re: Chipwahl für ATMEL-Umsteiger

Quoted text here. Click to load it

Das ist ein fauler Vergleich.  Einen Comparator hat selbst der dümmste
alte AT90S1200 ebenfalls schon.  Ist aber doch undendlich mühevoller,
und Portpins verbrauchst Du außerdem dafür.

Sicher ist der ADC weder überragend schnell noch überragend genau.
Andererseits sind 10 Bit Auflösung meist schon mehr, als die Umgebung
eines Controllers bei laufendem Takt überhaupt an S+N/N vertragen kann
(nicht umsonst gibt's auch einen sleep mode, der sich `ADC noise
reduction' nennt).  Gerade ein Punkt macht diese umschaltbaren ADCs
richtig hübsch: man kann eine Quasi-Analogeingabe simpelst mit einem
Poti realisieren, für die man sonst irgendwelche umständlichen (und
teureren) Schaltermimiken bräuchte.  Denke mal an eine
Teemaschinensteuerung, bei der man die Brühzeit einstellbar haben
möchte.  Da bietet sich sowas an.  (Wollte ich mal bauen aus einer
alten, kaputten Teemaschine, aber die hat dann leider jemand entsorgt,
bevor der Plan in die Phase der Ernsthaftigkeit gelangt ist.)

Quoted text here. Click to load it

Das ist wohl eher für ,,heiße'' Einsätze interessant, bei denen man
seine Daten mit lock bits schützen will (aber mit gesetztem lock bit
kann ich sie verständlicherweise auch beim AVR nicht mehr
modifizieren).

Quoted text here. Click to load it

Doch doch, das stimmt (leider) schon.  Du hast nur reprogrammierbaren
Flash ROM (hat der ATmega ja auch), aber einzelzellenbeschreibbaren
EEPROM hat der MSP430 wohl nicht.  Außer der Einzelzellen-
Beschreibbarkeit wird bei Atmel die duration des EEPROMs auch um den
Faktor 10 höher angegeben als die des Flash ROMs.  Das kann für Fälle,
in denen man häufig Daten zwischenspeichern will, schon wichtig
werden.  (OK, auch die 100000 Zyklen bekommt man kaputtgenuddelt, wenn
man sich einen dummen Algorithmus aussucht.)
--
J"org Wunsch                           Unix support engineer
joerg_wunsch@interface-systems.de        http://www.interface-systems.de/~j /

Re: Chipwahl für ATMEL-Umsteiger

Hallo,

Quoted text here. Click to load it

Ja, die MSP430 sind in erster Linie auf Stromsparen ausgelegt.

Das sie schwachbrüstiger sind, kann aber eigentlich nicht sein,
wenn man bedenkt, daß es 16-Bit-Controller sind, der AVR aber
nur 8-Bit. Zumindest bei gleichem Takt sollte der MSP430 beim
Integerrechnen deutlich schneller sein?!
 
Der MSP430 hat vorallem einen Riesennachteil: max. 64kB Adressraum.
Für RAM und ROM. Das wird schnell eng.
Ansonsten aber ein guter µC.

Grüße,

Sebastian  
 




--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Site Timeline