Chipwahl für ATMEL-Umsteiger

[Fuchs Michael]

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

 

[Jan-Hinnerk Reichert]

Fuchs Michael wrote:

[...]

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??

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

Weiters wäre interessant welches Programmierinterface besser wäre:
das parallele oder das serielle?? Ich freue mich schon auf eure
zahlreichen kommentare.

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

 

[Joerg Wunsch]

Fuchs Michael <fuxi1@gmx.at> wrote:

... 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?

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. ;-)

Weiters wäre interessant welches Programmierinterface besser wäre:
das parallele oder das serielle?

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/

 

[Joerg Wunsch]

Joerg Wunsch <j@ida.interface-business.de> wrote:

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?

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/

 

[Markus Baertschi]

In article <3f4ddee0$0$24080$91cee783@newsreader02.highway.telekom.at>,
fuxi1@gmx.at says...
....

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
....
Fuchs Michael

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
CH-1163, Etoy Email: markus@markus.org
Switzerland Homepage: www.markus.org

 

[Falko Jahn]

"Markus Baertschi" <markus@markus.org> schrieb im Newsbeitrag
news:MPG.19b8589fbc57b4829896ed@News.CIS.DFN.DE...

In article <3f4ddee0$0$24080$91cee783@newsreader02.highway.telekom.at>,
fuxi1@gmx.at says...
...
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
...
Fuchs Michael


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

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

 

[Florian Schenk]

"Tobias Aurand" <Tobias.Aurand@ei.fh-giessen.de> schrieb:

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.


Sicher? Ich hab von einem Bekannten gehört, er hätte versucht
einen neuen (also unbenutzen) ATMEGA162 via SPI zu proggen
und es hätte nicht geklappt. Also dann paralellmode und dann
erstmal die SPI schnittstelle aktivieren. Danach gings dann
auch seriell.
Kann das sein oder war das ein "Ausrutscher"?

Das war definitiv ein Ausrutscher... Ich habe hier sicher schon 20
neue ATMega162 seriell programmiert. Alle haben wunderbar
funktioniert.

Gruss,
Florian

 

[Markus Baertschi]

In article <bilhah$r7n$1@online.de>, falkojahn@online.de says...

richtig, 8535 ist abgekündigt, aber nicht der
MEGA8535
Da hast du recht. Die beiden recht vergleichbar bis auf die etwas mehr

pins des 8535 und dem entsprechend gösseren Gehäuse.

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 ?

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
CH-1163, Etoy Email: markus@markus.org
Switzerland Homepage: www.markus.org

 

[Joerg Wunsch]

Falko Jahn <falkojahn@online.de> wrote:

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.

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.

Ich benutze aber auch nur Bascom AVR , mit AVR-GCC würde
es bestimmt kleiner, oder ?

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/

 

[Joerg Wunsch]

Markus Baertschi <markus@markus.org> wrote:

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...

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/

 

[Matthias Weingart]

"Fuchs Michael" <fuxi1@gmx.at> wrote in
<3f4ddee0$0$24080$91cee783@newsreader02.highway.telekom.at>:

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

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.

 

[Matthias Weingart]

Marco Budde <mb-news-a@linuxhaven.de> wrote in
<3F4F8CFD.26C14D95@linuxhaven.de>:

Matthias Weingart wrote:

Kann per Boostraploader über eine normale RS232 programmiert werden,
JTAG ist auch vorhanden, C-Compiler MSPGCC ...

Und wie sieht es mit Doku aus? Das scheint bei TI ja immer
ein gewisses Problem zu sein .

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.

 

[Matthias Weingart]

aguja@despammed.com (Aguja) wrote in
<YN9U/g6wVgCH092yn@despammed.com>:

"Rechenpower" wohl etwas schwachbrüstiger als die AVR's (imho aber
voll

Wenn Du Rechenpower wörtlich meinst, wage ich das anzuzweifeln. Die
MSPs sind für Rechenarbeit geradezu optimiert (Hardware-Mul und so).

Programmpowerseitig mag das wieder anders aussehen...

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.

 

[Michael Eggert]

On Tue, 2 Sep 2003 14:22:14 +0000 (UTC), mwnews@pentax.boerde.de
(Matthias Weingart) wrote:

Moin!

Wenn Du Rechenpower wörtlich meinst, wage ich das anzuzweifeln. Die
MSPs sind für Rechenarbeit geradezu optimiert (Hardware-Mul und so).

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 [...]

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.

 

[Thomas Rehm]

Michael Eggert wrote:

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
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.

 

[Michael Eggert]

On Tue, 02 Sep 2003 19:59:51 +0200, Thomas Rehm <Th.Rehm@T-Online.de>
wrote:

Hi!

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.

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.

 

[Joerg Wunsch]

Matthias Weingart <mwnews@pentax.boerde.de> wrote:

...; 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;

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.)

die JTAG fuse brauch ich
einfach nicht zu zerstören; ...

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).

kein interner EEPROM (stimmt imho so nicht) usw
usf

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/

 

[Sebastian Fahrner]

Hallo,

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

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

 

[Jan-Hinnerk Reichert]

Michael Eggert wrote:

On Tue, 2 Sep 2003 14:22:14 +0000 (UTC), mwnews@pentax.boerde.de
(Matthias Weingart) wrote:

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 [...]

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

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