atmega2561 endlich lieferbar

und hier ist er...
gruss stefan

Super. Wen juckts? Das ist doch die totale Krücke. Die Architektur ist
für sowas gar nicht ausgelegt. 256kB Flash, aber nur 8kB SRAM, einfach
lächerlich. Wenn man viel Flash braucht, dann nimmt man eine
Architektur die darauf ausgelegt ist, sprich ARM oder M16C.

Und was nimmt man, wenn man einen AVR mit mehr als 4kB SRAM braucht?
Wohl nicht gleich einen ARM...

Zwischen 4kB und 256kB ist wohl ein kleiner Unterschied. Ein AVR mit
32kB Flash macht Sinn. Ein AVR mit 256kB (und dann nur 8kB SRAM)
nicht.

Und dann noch zu diesem Preis! Der Renesas M30626 ist fast 1 Euro 50
billiger, und der hat 384kB Flash, 31kB SRAM und einen Haufen Features,
die dem Mega2561 fehlen.

Gute Programmierer kommen auch mit 8kb RAM aus ;-)

@horst-otto

und was macht man bei bereits fertiger hardware mit einem haufen
zeitintensiv entwickelter software...??? etwa mit einem neuen design
bei 0 anfangen ??? dein vergleich mit anderen mcu's ist schon wirklich
oberschlau. deren eigenschaften sind mir sowas von schnuppe, interessant
ist für mich einzig und allein das plus an speicher, welches ich schon
lange benötige und nun ENDLICH erhalte !

stefan

ACK :-)

Bei viel Applikationen hab ich mir auch schon oft mehr Flash, als RAM
gewünscht. Z.B. in Applikationen mit einen LCD. Fonts oder Graphicen -
teilweise sogar Animationen. Wüsste nicht, wofür ich da mehr RAM
brauchen sollte.

Ich finde das Kindergartenverhalten immer so lästig hier ... wenn
jemand was braucht oder was will, hält sofort jemand dagegen und will
ihm einreden, dass er ein Idiot ist, weil man das doch garnicht braucht
und weil man gleich auf eine andere Plattform umsteigen soll.

Aber der OP hat sicher gute Gründe, die nicht diskutiert werden müssen,
weil er darum nicth gebeten hat!

Hiho,
ruhig, Jungs. Ball flachhalten und nicht ueber so einen Kram streiten.
Jeder Controller hat seine Vor- und Nachteile (welch schlaue
Erkenntnis). Sonst waere es doch langweilig

ich warte nicht auf diese krücke.
wer gibt mir den compiler dafür he....
wer gibt mir die paltinen dafür..he
wer schreibt für diese krücke bücher zum nachlesen ..he

ne..ne.. ich bleibe beim avr8 bis avr64. vielleicht später mal den
avr128.
ich bin halt altmodisch.
ich bastele gerne mit mehren avrs parallel, vielleicht altmodisch aber
interessant.

castle

Außerdem eignen sich die AVRs für Geräte mit Batterien sehr gut,
da sie einen Powerdown-Modus haben, der auch wirklich funktioniert.
Bei den Renesas-Typen ist mir das Stromsparen nie gelungen, die
saufen noch mehr Strom im Ruhezustand als die ARMs.

@castle

bist ganz und gar nicht altmodisch!
mulithreaded software liegt doch absolut im trend!
wo die paltinen für meinen mega her kommen sollen,
weiss ich allerdings auch noch nicht...

stefan

Hiho nochmal,
fuer Anwendungen, wo es auf jedes mA/µA ankommt, kann ich den MSP430
empfehlen. Der ist genau fuer diese Anwendungen hin entwickelt worden.
Hier mal ein paar Beispiele:
Active Mode: 200 µA at 1 MHz, 2.2 V
Standby Mode: 0.7 µA
Off Mode (RAM Retention): 0.1 µA

Sorry, aber da gibts nichts zu diskutieren:

Mega2561:

- langsamer
- weniger Speicher
- weniger Features
- höherer Preis

Das sind alles objektive Kriterien.

Ach ja, mit GCC funktioniert er auch nicht. Vielleicht nie. Also viel
Spaß beim Software migrieren.

@Horst-Otto:

Du hast uns schon in anderen Threads bewiesen, wie inkompetent du
bist!
Mach uns deshalb den gefallen und such dir ein anderes Forum für deinen
Quark...!

Pro MEGA 1281 und 2561:
Neben dem verdoppelten SRAM wurde auch noch die Pinzuordnung deutlich
verbesert. Alle Ports liegen auf niedrigen Speicherplätzen und fast
alle Port sind über einen Interrupt ansprechbar (wenn ich mich nicht
irre ;-) ). Bei schnell Portabfragen hat man so deutlich mehr Pins zur
Auswahl.

Hoffentlich nehmen die verbalen Entgleisungen nicht Überhand.
Auch in anderen Beiträgen häufen sich in letzter Zeit die destruktiven
Äußerungen
(siehe z.B.
http://www.mikrocontroller.net/forum/read-3-289943.html#new)

Euer moin

@Horst-Otto: Wenn der 2561 so sinnlos ist, wie du behauptest, würde mich
interessieren warum ATMEL den überhaupt auf den Markt gebracht hat.

Vielleicht bist du auch nur voreingenommen und weißt garnicht was
dessen vorzüge sind?!

Und ganz nebenbei: Geht zurück in euer Heise-Forum, ihr Trolle ;-)

XYZ: Da hast Du es mir aber gegeben. Ach halt, Du bist ja in
Wirklichkeit "Der wahre (Techniker)" aus dem anderen Thread:
http://www.mikrocontroller.net/forum/read-1-290896.html

Und ich glaube, dort warst Du es, der bewiesen hat wie inkompetent er
ist. Geh lieber wieder mit Deinem Barbie-Fön spielen.

Tja, Du solltest Dir eben abgewöhnen, Deine Sätze immer abwechselnd mit
"!" und "...!" zu beenden, das ist ziemlich verräterisch, weil die
wenigsten Leute so schwachsinnig schreiben.

Zurück zum Thema: bei GCC ist das Problem, daß er mit CPUs, die eine
unterschiedliche Breite für Daten und Code haben nicht zurechtkommt. Es
wären also wohl größere Modifikationen nötig, falls es überhaupt möglich
ist.

Thomas: ich weiß auch nicht, was Atmel sich gedacht hat. Aber
anscheinend werden dort in letzter Zeit suboptimale Entscheidungen
getroffen:
http://www.mikrocontroller.net/forum/read-1-290794.html#291426

Hmm - hoffentlich vernachlässigen sie die AVRs nicht, weil sie sich mehr
auf die SAM7S konzentrieren (wie bei Borland, die 10 Baustellen
aufreißen und nichts fertig machen)... Aber ich hab in
de.sci.electronics auch schonmal was von ATTINYs gelesen, die garnichts
gemacht haben. Ist wohl noch die selbe Chage?!

Ich glaub ich muss mir den 2561er auch mal genauer anschauen. Warum
soll der GCC nicht mit dem klarkommen? Das musst du mir genauer
erklären. Die Datenbreite war bisher immer 8Bit und die Instructions
immer 16 und mehrfache davon. Was hat sich da jetzt geändert?

Es kommt ganz auf die Anwendung drauf an, wievel SRAM und Flash man
braucht. Es gibt mit Sicherheit einen Markt für Prozessoren mit viel
Flash und wenig SRAM.

Meine Motorsteuerung im Auto braucht auch keine 80GB Festplatte, nur
mal so als Denkanregung.

horst-otto ist scheinbar einer, der eine kaffee-maschine mit
web-auftritt hat. Da hängt dann ein PC dran, auf dem ein schönes
progamm läuft, dass mindestens 20 TCP-Verbindungen gleichzeitig
aufmacht, um den wasser-stand abzufragen. dann braucht man viel SRAM
;)

Aber wozu braucht eine kaffee-maschine einen web-auftritt???

Hab jetzt mal gekuckt, seh aber keine wesentlichen Unterschiede.
Die Flashgröße von 256kb dürfte nicht besonders große Probleme machen -
der Instructionset sieht z.B. beim JMP-Befehl seit den allerersten AVRs
bereits einen Flash-Bereich von 4M (words) vor. Also wo ist das Problem
mit dem GCC?

Das Problem sind die Pointer. Bis zum Mega128 sind die 16bittig, weil
der Code ja wortweise adressiert wird. GCC macht andererseits keinen
Unterschied zwischen Code- und Datenpointer.

Also geht erstmal garnichts und GCC muss angepasst werden. Und dann
werden entweder alle Pointer 24bittig, oder alle Entrypoints müssen in
den ersten 128K liegen (ähnlich realisiert beim M16c).

Was A.K. gesagt hat. An der Unterstützung für die AVRs mit 3-Byte PC
wird schon ne Weile rumgepfriemelt, hingekriegt hats aber noch keiner.
Dafür sind tiefgreifende Modifikationen in gcc nötig. Also nix mit
GCC-Code migrieren. Bleibt die Wahl: schweineteuren Compiler kaufen
oder Assembler benutzen. Womit wir wieder bei meinem ursprünglichen
Argument angelangt wären: lieber ARM benutzen, wenn man so viel Flash
braucht.

tja, dann bin ich ja froh, nicht auf die "einfachere"
programmierung via gcc und konsorten angewiesen zu sein.

in assembler jedenfalls sehe ich keine grossen probleme
auf mich zukommen: elpm/spm verwende ich nicht ohne rampz
vorher zu laden und jump/call springen seit jeher durch
den vollen 4M adressraum, wie schon angemerkt wurde.
die selteneren indirekten calls/jumps sind schliesslich
noch durch ihre extended-varianten zu ersetzen- das wars.

performanceprobleme ("lahme krücke") sind einem so natürlich
genauso fremd (zugegeben: komme mit meiner applikation noch
vom alten z80). mit einem taktzyklus pro befehlswort ist man
doch gut dabei (manches ist freilich mit diesem befehlsvorat
nur umständlich konstruierbar).

ich finde, man sollte in dieser frage mal die kirche im dorf
lassen. es hängt schliesslich vom einsatz ab, welche leistungs-
klasse zu wählen ist. bezüglich des zugehörigen stromverbrauchs
ist man beim mega auf der richtigen seite. fairerweise sollte
man auch einmal die chipgrösse berücksichtigen. der m16c etwa
ist immerhin doppelt so gross.

das alles sollte niemandem hier wirklich neu sein...

stefan

@stefan
Du schreibst (lässt schreiben) 256kByte Code in Assembler von Hand? Das
finde ich beeindruckend - oder sind das meiste Daten/Texte/Grafiken?

Wenn du wirklich so riesige Assembler Programme schreibst, würde mich
interessieren, ob du eine spezielle Technik entwickelt hast. Vielleicht
hast du ja auch eine Statistik, z.B. wieviel Bytes Code / Stunde ein
dann wohl extrem schneller Programmierer schafft.

Grüße
 SU

P.S:
Mich würde der 256 einfach wegen der 8kByte S-RAM interessieren. Auch
wenn ich mit gcc nur die unteren 128kByte Flash ansprechen kann. D.h.
ein simpler Port ist erst mal o.k. Die oberen 128k Flash könnte man
dann ja für Grafiken etc. benutzen - oder das allseits beliebte memory
paging benutzen.

Hier sind ja mächtige Streithammel am Werk gewesen.

Ist doch gar nicht die Frage, welche CPU in irgendwas besser ist oder
nicht. Die beste gibt es eh nicht, jede hat auch Nachteile.


Interessant ist die Frage aber schon, welches Feature am M2561 so
wichtig ist.

Ich komme in der Regel mit dem M8 voll aus und notfalls könnte ich auf
den M168 aufsteigen.


Ich habe aber einen Kollegen, der arbeitet nach der Copy+Paste
Methode.
Die Programme sehen oft so aus, als stünde 5-mal das Gleiche
hintereinander. Nur bei ganz genauem Hinsehen merkt man, daß in jedem
Zweig einige Parameter ein kleines bischen anders sind. Der Kollege
nimmt daher gerne 16k Flash.
Ich finde solche Programme sehr unübersichtlich.


Ich versuche immer das Gemeinsame und das Unterschiedliche zu
separieren Und dann eine Unterfunktion zu schreiben, der nur die
Unterschiede übergeben werden.
Man braucht dann diese gemeinsame Grundfunktion nur einmal zu verstehen
und nicht 5-mal.
Und Änderungen müssen dann auch nur einmal gemacht werden.


Peter

hallo superuser,

um gottes willen. das meiste flash dient textstrings und ganzen screens
für ein grafik-display. mehr sram ist mir für eine dynamisch erstellte
webpage von nutzen. der eigentliche programmanteil bei meinem jetzigen
mega128 ist unter 10%. dennoch, selbst das braucht eine menge zeit- die
hat man aber, wenn's nur ein hobby ist und programmieren spass macht!
der mega2561 soll dafür & für die nächsten jahre genug platz bieten!

mit besonderen techniken kann ich leider nicht dienen. man sollte auf
jeden fall seinen code äusserst modular und gut dokumentiert halten.

stefan

@peter

na ja, wenn der speicher schonmal vorhanden ist! die vorgehensweise
deines kollegen spart in jedem falle zeit. zeit, die er womöglich
braucht, um seinen schlechten programmierstil an anderer stelle
auszugleichen...

"das gemeinsame und das unterschiedliche zu separieren" ist nach
meiner erfahrung leider oft erst mitte bis ende einer
programmentwicklung möglich und mehrere "rückkopplungsschleifen" sind
erforderlich, bis das hehre ziel eines effizienten, platzsparenden und
übersichtlichen codes erreicht ist.

stefan

Die copy&paste Methode ist für mich assoziales Programmierverhalten.
Assozial deshalb, weil die arme Sau, die nach dir kommt und einen Bug
rausmachen muss, den Bug an vielen Stellen im Programm fixen muss.

PS: fürs Hobby ist das natürlich egal, da bestraft man sich ja selbst

@Horst-Otto:

Nö, muß dich leider enttäuschen..! (<- Satzzeichen beachten!)
Und nun husch-husch, du Troll! :-D

Nenene, sei stefan doch der ATmega2561 gegönnt. Wenn er damit nichts
anfangen könnte, hätte er sich den nicht gekauft.......

Ansonsten erinnert der Thread an:
http://www.mikrocontroller.net/forum/read-7-287619.html#new



Mfg Sascha

@Horst-Otto: Danke für die Info mit dem GCC! Das ist dann wirklich ein
böses K.O.-Kriterium, das noch viel objektiver ist als die anderen
Punkte, die du oben noch aufgezählt hast.

Nach einigen Jahren Assembler - darunter auch sehr anspruchsvolle
Projekte wie den AVRMP3Car (damals '99 sogar von mp3.com verlinkt g)
programmierte ich zu 100% in Assembler. Sogar rekursive Sachen wie
Dateiensuche über komplette FAT32-Medien mit Windows-Langen-Dateinamen
usw ...

Aber mittlerweile will ich eigentlich mit Assembler nichts mehr zu tun
haben - dafür gibt es ja den GCC, der sogar objektorientierten C++ Code
effizient auf dem AVR umsetzt. Natürlich nur Subjektiv - zu meiner
Überraschung ist mir der objektorientierte C++ Code nicht langsamer
vorgekommen als in C :-)

Ich bin wohl in letzter Zeit wirklich "hochsprachen-verweichtlicht" -
aus diesem Grunde würde ich persönlich dann tatsächlich auch die Finger
vom MEGA2561 lassen, solange es den GCC nicht dafür gibt.

Mfg
Thomas Pototschnig

Privat würde ich den Controller auch (noch) nicht einsetzen, solange gcc
den nicht unterstützt.
Dienstlich benutze ich demnächst (wenn Ineltek endlich gelieferthat )
IAR...

Dann nehmt doch den CodeVision. Für einen akzeptablen Preis unterstützt
der alle Prozessoren (Ich glaube der liegt gerade bei 175 Euro). Der
Support ist auch sehr gut.

Ehrlich gesagt, hab ich den 2561er nicht so nötig um 175EUR für einen
Compiler dafür auszugeben. Dann nehm ich doch lieber einen anderen MCU,
der auch unterstützt wird :-)

256k/8k Speicher und dann in Assembler programmieren, das müsste mir mal
passieren.

Programmiere den 2560 aktuelle mit Codevision und bin sehr zufrieden mit
dem Controller, wobei er bei mir auch erst zu 30% voll ist. Ich denke
über 50% werde ich auch nicht kommen. Der 1280 läßt ja leider noch auf
sich warten.

@Horst-Otto:
Zum Posting vom 23.01.2006 20:51:

Hä?!? Was hast du für ein Problem?
Hab diesen Thread gerade erst entdeckt, weil
ich den neuen Atmel 2561 mal testen möchte.

Kurz gesagt, ich finde du bist ein richtiges...
..naja, kannst dir schon denken was - gelle? ;)

Gruß,
Techniker