z.b. bei http://dkc1.digikey.com/de/digihome.html meine bestellung ist jedenfalls unterwegs... nur mal so zur info für alle, die seit monaten schon sehnsüchtig warten!
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.
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.
@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
Thomas Pototschnig schrieb: ""Ich finde das Kindergartenverhalten immer so lästig hier ..."" Zustimm Erinnert mich immer so an die Windows-vs-Linux-Klopperei. Und das muss nun wirklich nicht sein. @stefan: Es gibt Universal-Adapterplatinen, da kann man den Controller auflöten, da werden einfach alle Pins auf Lötlöcher im 2.54mm-Raster rausgelegt. Oder Methode 'Elm-Chan'. Sprich, Chip mittels lötfestem doppelseitigem Klebeband auf die Lötseite einer Lochrasterplatine kleben und von dort aus mit feinem Lackdraht verkabeln. Siehe hier: http://elm-chan.org/docs/wire/wiring_e.html Nichts für nervöse Leute. ;-) Gruss Jadeclaw.
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: Und meiner ist länger als deiner. Ok, jetzt mal ernsthaft. einen Controller wählt man nicht nach Schönheit aus, sondern nach Anforderungen, eigenen Kenntnissen und vorhandener Entwicklungsumgebung aus. Und sich extra für ein Projekt in ein komplett neues System einzuarbeiten, ist meistens nicht sehr wirtschaftlich, es sei denn die Anforderungen verlangen dies, weil eine Controllerarchitektur oder der Stammhersteller dies nicht leisten kann. Und ich denke, das sollten wir dem guten Stefan dann doch mal selbst überlassen, was er wie macht. Ok? Gruss Jadeclaw.
@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...!
@Horst-Otto: Noch nicht, aber das kennen wir ja von OSS generell, das kann sehr schnell gehen. Gruss Jadeclaw.
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 :-)
Cool, ich habe mich schon auf die Mega256x Reihe gefreut. Mit diesem Flash passen auch noch umfangreichere Programme rein. Warum ein Compiler? Kann der Mega2561 kein Assembler? ;) Ach ja und Hans Otto ist doch wirklich jemand zum Liebhaben. Passiert ja öfter mal, daß er jemanden seine Weltansichten aufs Auge drücken will...
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.