Ich bin gerade am überarbeiten eines Designs und frage mich ob der ATmega32 heutzutage noch zeitgerecht ist. Ich hatte im letzten Projekt mit ATtiny gearbeitet und die sind echt toll im Stromverbrauch. Wie lange wird es den ATmega32 noch geben? Viele Grüße! Marko
Habe ich angefragt. Ich bin hier noch der letzte DinoSaurier der 8Bit-Kontroller einsetzt wenn sie reichen. Alle anderen nehmen Standardmäßig einen SAM32, auch wenn die Aufgabe mit einen Flip-Flop machbar wäre... Marko
Was wäre denn zeitgemäß in dieser Pin/Speicher/Periferie-Klasse? Marko
Marko R. schrieb: > Alle anderen nehmen Standardmäßig einen SAM32, auch > wenn die Aufgabe mit einen Flip-Flop machbar wäre... Das ist natürlich Wahnsinn. Aber einen z.B. STM32F0 in TSSOP für < 1,50€ würde ich heute bei Neuprojekten einem AtmegaX immer vorziehen.
Beim letzten Projekt, bei dem ich einen ATmega32 eingesetzt habe, habe ich mich tüchtig geärgert. Nicht, weil die Leistung irgendwann zu klein wurde, sondern einfach, weil ich mich an die Debug-Möglichkeiten der ARMe gewöhnt hatte. Mein persönlicher ATmega32-Ersatz ist irgendein STM32Lxxx (stromsparend) oder ein STM32F10x, meist ein STM32F103C8 (auch nicht mehr zeitgemäß, aber sehr gut erhältlich).
STM32F0 bedeutet aber sofort Eclipse? Das habe ich nie so schön am laufen gehabt wie dsa Atmel-Studio. Marko
Ist wohl auch die Frage, wie aufwändig das Redesign sein soll/darf. Vielleicht tut's ja auch ein uC aus der Gruppe ATmega324/644/1284.
EmBitz (auch nicht mehr zeitgemäß, ich weiß :-) ) läßt sich ähnlich handlich wie Atmel Studio installieren. Für einen schnellen Test würde ich das als die IDE der Wahl bezeichnen.
Der AtXMega war damals auch für mich der Grund mit STM32 anzufangen. Für Kleinkram setze ich aber auch immernoch AtTiny 13/84/85 bzw. AtMega328 ein. Aber ich bin auch jemand der lieber einen Tiny13 als einen NE555 verbaut...
Marko R. schrieb: > STM32F0 bedeutet aber sofort Eclipse? Das habe ich nie so schön am > laufen gehabt wie dsa Atmel-Studio. Atollic Studio installieren, es läuft und fertig - wo ist das genaue Problem?
Marko R. schrieb: > Wie lange wird es den ATmega32 noch geben? Der wird wohl auslaufen, man sollte auf den ATmega32A umsteigen. Pinkompatibel ist auch der ATmega324PB (3 UARTs, 3 Timer 16Bit).
:
Bearbeitet durch User
Curby23523 N. schrieb: > Marko R. schrieb: >> Alle anderen nehmen Standardmäßig einen SAM32, auch >> wenn die Aufgabe mit einen Flip-Flop machbar wäre... > > Das ist natürlich Wahnsinn. Aber einen z.B. STM32F0 in TSSOP für < 1,50€ > würde ich heute bei Neuprojekten einem AtmegaX immer vorziehen. Ah ja, Umstieg auf einen Atmel-ARM ist „Wahnsinn“, aber einen STM32 würdest du „immer vorziehen“. Das verstehe wer will … Peter D. schrieb: > Der wird wohl auslaufen, man sollte auf den ATmega32A umsteigen. Ich würde sogar sagen, dass der schon ausgelaufen ist, aber der ATmega32A natürlich ein hinreichender (und billigerer) Ersatz ist. Marko R. schrieb: > Ich hatte im letzten Projekt mit ATtiny gearbeitet und die sind echt > toll im Stromverbrauch. Wobei „mit ATtiny“ natürlich auch eine außerordentlich breit gefasste Aussage ist. :)
Marko R. schrieb: > STM32F0 bedeutet aber sofort Eclipse? Das habe ich nie so schön am > laufen gehabt wie dsa Atmel-Studio. Du kannst auch VSCode oder Emacs oder Vim oder sogar Notepad nehmen. Die Architektur des Zielsystems hat ja wohl keinen Einfluß darauf womit man Textdateien mit Quelltext bearbeitet.
Hallo, wenn du bei 8Bit bleiben möchtest und dir der ATmega32 zu alt ist, dann kannste die neue ATmega Serie verwenden. Ob das für dich Sinn macht weiß ich nicht. Wenn deine Kollegen alle SAM verwenden, würde es auch Sinn machen sich dem anzupassen. Zwecks Austausch bei Problemen. Wenn ich das Forum so beobachte sind die STM32 auch beliebt.
Meinst du mit "neuer" ATmega-Serie die ATXmega ? Marko
Hi >Meinst du mit "neuer" ATmega-Serie die ATXmega ? Eher die MegaAVR® 0-Serie: http://ww1.microchip.com/downloads/en/DeviceDoc/40002015A.pdf MfG Spess [Mod: URL vervollständigt, damit sie als Link angezeigt wird.]
:
Bearbeitet durch Moderator
Sieht garnicht mal so uninteressant aus, wobei der Name natürlich mehr als suboptimal gewählt ist. Wo liegen die denn preislich?
Jörg W. schrieb: > Da haben sie offenbar die Peripherals der SAMD-Serie mit dem AVR-Core > verheiratet … Und dieses, ähm Gebilde, soll jetzt irgendwie erfolgreich gegen ARM anstinken können? In tausend kalten Wintern nicht.
Cyblord -. schrieb: > Jörg W. schrieb: >> Da haben sie offenbar die Peripherals der SAMD-Serie mit dem AVR-Core >> verheiratet … > > Und dieses, ähm Gebilde, soll jetzt irgendwie erfolgreich gegen ARM > anstinken können? In tausend kalten Wintern nicht. Preisfrage
Tim T. schrieb: > Wo liegen die denn preislich? Schau doch einfach beim Distri deines geringsten Misstrauens vorbei. Der billigste davon bei RS (was bestimmt nicht der billigste Distri ist :) ist für weniger als 1 Euro zu haben.
Cyblord -. schrieb: > Und dieses, ähm Gebilde, soll jetzt irgendwie erfolgreich gegen ARM > anstinken können? Warum sollte es? Wenn man ARM haben will, kann man ihn aus gleichem Hause mit gleichen Peripherals haben (oder aus anderen Häusern mit völlig anderen Peripherals). Da hätten sie sich gewiss nicht selbst Konkurrenz machen müssen. Wenn es nach dem Anspruch geht, dass es dir gefällt, wird das wohl schwer für einen Halbleiterhersteller … aber üblicherweise ist deren Anspruch, dass sie Kunden haben, denen es gefällt. Ohne solche leistet sich niemand eine Millionen teure Entwicklung.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > aber üblicherweise ist deren > Anspruch, dass sie Kunden haben, denen es gefällt. Ohne solche leistet > sich niemand eine Millionen teure Entwicklung. D.h. es gab noch nie Fehlentwicklungen die sich nicht gut verkauft haben?
Cyblord -. schrieb: > Jörg W. schrieb: >> aber üblicherweise ist deren >> Anspruch, dass sie Kunden haben, denen es gefällt. Ohne solche leistet >> sich niemand eine Millionen teure Entwicklung. > > D.h. es gab noch nie Fehlentwicklungen die sich nicht gut verkauft > haben? Manche Annahmen sind so dermaßen falsch, dass noch nicht mal das Gegenteil richtig ist.
Marko R. schrieb: > Ich bin hier noch der letzte DinoSaurier der 8Bit-Kontroller einsetzt > wenn sie reichen. Naja, die AVRs haben eben den Langweiligkeitsfaktor. Man schreibt Code hin und er läuft einfach. Ich nehme daher auch gerne AVRs. Beim 32Bitter kann man dagegen manche Überraschung erleben, z.B.: Beitrag "Riesen Problem: Timer in Timer-Interrupt starten" Ein Kollege hat mal beim LPC4357 einen Pin als Ausgang gesetzt, der mit GND verbunden war. Danach war der Pin tot. Vom AVR bin ich gewohnt, daß ich zur Fehlersuche mal einen Output mit GND/VCC "overdriven" kann.
Peter D. schrieb: > Beim 32Bitter kann man dagegen manche Überraschung erleben, z.B.: Hat aber wohl weniger was mit 32bittern zu tun denn mit diesem Codegenerator-Zeug.
Marko R. schrieb: > Ich bin gerade am überarbeiten eines Designs und frage mich ob der > ATmega32 heutzutage noch zeitgerecht ist. Es ist doch die Frage, wofür: - privates Hobby-Bastelprojekt, Stückzahl eins bis zehn, - komerzielle Kleinserie, - komerzielle Großserie. Lustig finde ich immer, wenn Bastler seitenlang solche Fragen diskutieren.(Bitte: jedem das seine, aber: macht doch einfach, was Euch den meisten Spaß bringt oder was Euch am leichtesten fällt.)
:
Bearbeitet durch User
Marko R. schrieb: > Ich bin gerade am überarbeiten eines Designs und frage mich ob der > ATmega32 heutzutage noch zeitgerecht ist. > > Ich hatte im letzten Projekt mit ATtiny gearbeitet und die sind echt > toll im Stromverbrauch. Ich bin für kleinere Sachen auf PIC24/dsPIC umgestiegen. Das ist letztendlich eher noch einfacher zu handhaben, die Peripherie ist leistungsfähiger, das Debuggen bequemer, und 5V und DIL-Optionen gibts immer noch, wenn ich das unbedingt brauchen sollte. Auf der anderen Seite geht diese Serie bis 144 Pins und 200 MHz Dual-Core hoch. Reicht also auch. fchk
Wenn der Bastler halt 100Stk/Jahr über die nächsten 10 Jahre basteln will dann denkst man eben doch schon wieder drüber nach... Marko
Marko R. schrieb: > über die nächsten 10 Jahre Da wirst du wohl nicht allzu viele Konstanten finden über solch einen Zeitraum. Gut, einen NE555 wird's dann vielleicht sogar noch geben …
Marko R. schrieb: > Wenn der Bastler halt 100Stk/Jahr über die nächsten 10 Jahre basteln > will Ambitioniert! :)
Marko R. schrieb: > Wenn der Bastler halt 100Stk/Jahr über die nächsten 10 Jahre basteln > will Mit anderen Worten zwei Stück pro Woche für die nächsten 10 Jahre. Das nenne ich mal sportlich für einen Bastler. Daumen hoch! Jens
M.A. S. schrieb: > Marko R. schrieb: >> Wenn der Bastler halt 100Stk/Jahr über die nächsten 10 Jahre basteln >> will > > Ambitioniert! :) Du meinst so wie jemand der 1000 Kondome mit Ablaufdatum des gleichen Jahres kauft?
Jörg W. schrieb: > Da wirst du wohl nicht allzu viele Konstanten finden über solch einen > Zeitraum. Ich setze seit 15 Jahren ATmega8 in diversen Projekten / Kleinserien ein, und stelle einige jetzt auf ATmega328 um. Bisher gab nicht die Notwendigkeit.
Zeitgerecht ist immer eine Frage. Aus klassischer Ingenieurssicht ist die Lösung die optimale, die das gesetzte Problem mit minimalem Aufwand löst. Wenn ein Problem mit einem ATMega erschlagen werden kann ohne dass man Verrenkungen machen muss, dann ist der Controller angemessen; da der allerdings seit geraumer Zeit durch pinkompatible nachfolger abgelöst wird, sollte man zu selbigen greifen. Ich habe schon mehr als ein großes Projekt gesehen, wo man für irgendeinen Käse meinte, einen "zeitgemäßen" LPC oder STM32 oder wasauchimmer zu nutzen und sich damit drölf Baustellen ins Nest geholt hat, die monatelang gekracht und das Projekt aufgehalten haben. Wenn ein AVR8 ein Problem ohne Bauteilzoo drum rum, der mit einem anderen Controller nicht nötig wäre, löst, gibt es keinen Grund da auf Biegen und Brechen einen ARM oder PIC32 (MIPS) reinzudesignen. Man sollte aber halt ggf prüfen ob der eingeplante Chip eventuell einen kompatiblen Nachfolger hat oder etwa ganz abgekündigt ist. Wer anderes behauptet ist verblendet von der Idee es besser zu wissen und glaubt zumeist, nur weil etwas alt ist, sei es schlecht. Wenn man sonst nur zB ARM Cortex-M einsetzt und irgendwas in der Leistungsklasse eines 8Bitters sucht, ist es allerdings das selbe wie oben, nur andersrum. Da gibt es wenig Grund eine extra Architektur dafür zu nehmen, solange es aus der gleichen Familie was passendes gibt.
Wenn du die Eclipse basierten IDEs für STM32 nicht magst, kannst du mit CubeMX auch ein Makefile Projekt erstellen und an der Kommandozeile compilieren. Zum Debuggen kommst du Eclipse aber wohl nicht herum - es sei denn du kannst Dir Keil leisten.
Stefanus F. schrieb: > Zum Debuggen kommst du Eclipse aber wohl nicht herum Er kann auch den nackten gdb nehmen, evtl mit ddd oder KDbg als GUI-Frontend. Nichts anderes macht Eclipse ja im Hintergrund auch (gdb verwenden). Eventuell geht auch das Debugger-Plugin von vscode (würd mich ehrlich gesagt wundern wenn nicht)
:
Bearbeitet durch User
Stefanus F. schrieb: > Zum Debuggen kommst du Eclipse aber wohl nicht herum - es sei denn du > kannst Dir Keil leisten. EmBitz basiert auf CodeBlocks. VisualGDB auf Visual Studio. Die Welt ist manchmal größer, als es auf den ersten Blick aussieht.
Bernd K. schrieb: > Eventuell geht auch das Debugger-Plugin von vscode > (würd mich ehrlich gesagt wundern wenn nicht) Bitteschön: https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug ;-)
Stefanus F. schrieb: > Zum Debuggen kommst du Eclipse aber wohl nicht herum - es sei denn du > kannst Dir Keil leisten. Von Keil und IAR gibt es kostenlose Demoversionen. Und von ST gibt es einen neuen STM32G071KBT8 im TQPF32 mit 0,8 mm Pinabstand. Wenn einem die ATmegas nicht mehr ausreichen, findet man hier einen lötfreundlichen Einstieg in die ARM-Welt. Aber: solange die ATmegas ausreichend sind, nimm einen neueren Typen mit passendem Pinout. Von der MegaAVR® 0-Serie würde ich aber die Finger lassen.
Marko R. schrieb: > STM32F0 bedeutet aber sofort Eclipse? Das habe ich nie so schön am > laufen gehabt wie dsa Atmel-Studio Wenn Du das Atmel-Studio mochtest würdest Du VisualGDB lieben. Ist zwar nicht kostenlos aber jeden Cent wert.
Visual Studio Code mit dem Cortex-Plugin, ARM-GCC und OpenOCD machen eine ganz gute Figur. Installieren muss man die Komponenten jedoch selbst.
Cyblord -. schrieb: > Du meinst so wie jemand der 1000 Kondome mit Ablaufdatum des gleichen > Jahres kauft? Ich finde, der Vergleich ist nicht sooo weit hergeholt. :)
M.A. S. schrieb: > Cyblord -. schrieb: >> Du meinst so wie jemand der 1000 Kondome mit Ablaufdatum des gleichen >> Jahres kauft? > > Ich finde, der Vergleich ist nicht sooo weit hergeholt. :) Es heißt ja immer man solle sich große Ziele setzen.
Wie sieht's denn mit RISC-V aus? Gibt's da inzwischen günstige Mikrocontroller?
Nano schrieb: > Wie sieht's denn mit RISC-V aus? Noch 'ne neue Dose aufmachen? Das dürfte für diesen Thread keinen Sinn haben.
Bernd K. schrieb: > Er kann auch den nackten gdb nehmen, evtl mit ddd oder KDbg als > GUI-Frontend. Lazarus soll auch STM32 können, ich habs selbst noch nicht probiert.
Nano schrieb: > Wie sieht's denn mit RISC-V aus? Diese Frage stellt sich in vielleicht 5 Jahren. Heute ist das nur spannend, wenn Du selber ein SoC entwickeln möchtest.
Stefanus F. schrieb: > Wenn du die Eclipse basierten IDEs für STM32 nicht magst, kannst > du mit CubeMX auch ein Makefile Projekt erstellen und an der > Kommandozeile compilieren. Dafür braucht man kein CubeMX. Ein Makefile ist auch nur Text. > Zum Debuggen kommst du Eclipse aber wohl nicht herum - es sei denn du > kannst Dir Keil leisten. Weder noch. Einfach arm-gdb und irgendein Frontend [1] dafür. Sofern man nicht gleich gdb --tui nutzen will. Läuft bei meistens darauf hinaus. [1] xxgdb, ddd oder irgendeine IDE
Axel S. schrieb: > Dafür braucht man kein CubeMX. Ein Makefile ist auch nur Text. Stimmt, aber wenn man noch nicht weiss, was da rein gehört, hilft CubeMX schon.
Die neuen Megas (mega-0/1 Serie) und die neuen Tinys (tiny1 serie), explizit nutze ich die ATmega4808 und Tiny1614 (Tiny3217 ist auch toll) sind m.E. sehr zeitgemäße und vor allem günstige 8 Bitter. Klar, Ein STM32 ist teils weitaus günstiger und hat mehr performance, aber wie oben auch geschrieben wurde, ich liebe Visual Studio (und damit Atmel studio), Eclipse ist eine Pest, gleiches bei Atollic Stuido. EMBitz war noch ok (meine Meinung). Beim Tiny1614 (gleiches auch bei dem Mega4808), laufen mit int. 20 Mhz mit Uart problemlos, man spart sich viel Hühnerfutter bei den Teilen. Einen "klassischen" Mega/Tiny würde ich nicht mehr nutzen, die neuen Serie sind einfach mächtiger und auch viel günstiger wenn man mal auf Microchip-Direct die Preise vergleicht mit einem ATtiny84 oder Mega328P bspw. Ich kann die sehr empfehlen, vor allem da die Konfig etc.. weiterhin weitgehenst genauso einfach ist wie bei den alten Megas/Tinys.
Ups. Und ich dachte ich bin modern, wenn ich bei Schaltungen ab 10 TTL-ICs oder 4 Opamps über Ersatz durch einen Mikrocontroller nachdenke... Allerdings finde ich Atmegas mittlerweile im Elektroschrott (ähnlich wie Rechner mit USB3, was vor einigen Jahren noch nicht der Fall war), das ist ganz unwissenschaftlich ein gewisses Zeichen dafür daß mindestens der Zenit überschritten ist.
Wollvieh W. schrieb: > Und ich dachte ich bin modern, wenn ich bei Schaltungen ab 10 > TTL-ICs oder 4 Opamps über Ersatz durch einen Mikrocontroller > nachdenke... OPV-Schaltungen kann ich nicht durch MCs ersetzen. Aber >=3 Logik-ICs und sämtliche 555-Schaltungen ersetze ich durch einen MC. Besonders der Ersatz des 555 bringt viele Vorteile (definiertes Power-On, Brownout, Entprellung, keine Erholzeit, kein Abgleich, keine Mengen an Hühnerfutter nötig).
Peter D. schrieb: > OPV-Schaltungen kann ich nicht durch MCs ersetzen. Wohl: Analog-Comparator, Gain und differentielle Eingänge beim ADC, PWM Erzeugung... Und viele Sensoren sind heute digital. Meine Heizungssteuerung läuft noch mit PT1000, würde ich heute nicht mehr machen. Temp, RH, Drucksensoren, Lichtsensoren mit I2C, SPI. Der Bedarf an OPV in dem Bereich ist arg zurückgegangen. Und TTL ICs hab ich das letzte Mal eingesetzt, als ich einen Quarztakt 10:1 bis 0.01 Hz als Zeitbasis runtergetaktet habe. Hätte man auch mit einem uC machen können, aber mir war das saubere Taktverhältnis wichtig.
Karl K. schrieb: > Wohl: Analog-Comparator, Gain und differentielle Eingänge beim ADC, PWM > Erzeugung... Ich kann jedenfalls keinen einzigen OPV durch MCs ersetzen. Ich benötige sie z.B. zur Signalkonditionierung vor dem ADC bzw. nach dem DAC. Einen MC, der z.B. +/-10V liefern kann, kenne ich nicht. Auch als Transimpedanzverstärker ist ein MC nicht geeignet.
Peter D. schrieb: > Karl K. schrieb: >> Wohl: Analog-Comparator, Gain und differentielle Eingänge beim ADC, PWM >> Erzeugung... > > Ich kann jedenfalls keinen einzigen OPV durch MCs ersetzen. Ich benötige > sie z.B. zur Signalkonditionierung vor dem ADC bzw. nach dem DAC. > Einen MC, der z.B. +/-10V liefern kann, kenne ich nicht. > Auch als Transimpedanzverstärker ist ein MC nicht geeignet. Nur zur Info: Die STM32F303 enthalten programmatisch konfigurierbare Operationsverstärker.
Stefanus F. schrieb: > Axel S. schrieb: >> Dafür braucht man kein CubeMX. Ein Makefile ist auch nur Text. > > Stimmt, aber wenn man noch nicht weiss, was da rein gehört, hilft CubeMX > schon. Notfalls kann man mal kurz google anwerfen und schauen ob schonmal jemand ein minimales funktionierendes Makefile-Projekt für diesen Prozessor gemacht hat. Die am schwierigsten aufzutreibenden Teile sind ein passender Startupcode und eine SystemInit. Man kann aber meist vom Hersteller oder von Keil die entsprechende .pack Datei herunterladen, selbst für völlig obskure fernöstliche ARMs von denen noch nie einer was gehört hat bekommt man die, dort drin findet man einen Startup für Keil (den muß man auf gcc portieren, oder einen existierenden gcc startup nehmen und die Vektortabelle entsprechend austauschen) eine SystemInit und die Header für die Peripherieregister (oder zumindest ein SVD aus dem man die automatisch generieren kann). Und ein Linkerscript braucht man noch, das ist aber auch kein Hexenwerk, da kann man einfach ein existierendes und passt es an mit den Werten aus dem Datenblatt. Am Makefile selbst ist überhaupt nichts besonderes, das ist völliger Standard. Musst halt in Erfahrung bringen welche Optionen der gcc braucht um die Architektur festzulegen, das kann man auch leicht nachlesen. Wenn man das einmal im Leben gemacht hat (sollte jeder mal gemacht haben) dann wird jedes weitere Mal zum Spaziergang denn danach muß man nur noch ein paar Dateien austauschen und ein paar kleine Änderungen vornehmen ohne lange rumzurätseln. Wenn man es noch nie gemacht hat zieht man sich irgenwo ein Minimal-Makefile-Blinky von github für den gleichen oder einen ähnlichen Prozessor, das simpelst gestrickte das man finden kann, und schaut sich gründlich an was da alles drin ist und wie alles zusammengedengelt ist und nimmt das als Ausgangspunkt.
:
Bearbeitet durch User
Peter D. schrieb: > Einen MC, der z.B. +/-10V liefern kann, kenne ich nicht. Zwei PWM Ausgänge in Reihe schalten... ;-) Ich behaupte ja nicht, dass sich alle OPV ersetzen lassen, ich verwende sie ja auch noch. Aber einige uC enthalten durchaus interne OPV wie die Gainverstärkung für ADCs, so dass ich mir den OPV für eine Stromshunt sparen kann, wenn ich die Schaltung entsprechend auslege. Ist doch nett...
Wenn ich mich richtig erinnere - und ich habe mich durch Zurückscrollen noch einmal dessen vergewissert - geht es dem TO um einen Ersatz für die Kombination ATmega32 und Atmel Studio. Gesucht scheint also eine Brot- und Butter-Kombination, um mit möglichst wenig Einarbeitungsaufwand klein- bis mittelaufwendige Projektchen zu stemmen. Leider wurde nicht erwähnt, ob kommerzieller, privater oder Hochschuleinsatz. Aber wir können mit guter Wahrscheinlichkeit davon ausgehen, dass handgeschriebene Makefiles, VIM, RISC-V und exotische Peripherie eher nicht Teil der Wunschliste sind. Eher so Zusammenstellungen wie "STM32F10x-Familie, ST-Link V2 und EmBitz" oder "LPC1768, J-Link-Edu und Embedded Studio". Oder so. Eigentlich ging es auch um die Frage des "Ob". Welchen Vorteil man sich verspricht. Die Rechenleistung und Peripherie nicht - die reicht ja offensichtlich. Die Verfügbarkeit auch nicht. Mit den (P)A-Typen ist die ja noch lange gesichert. Eher so handfeste Vorteile wie "On-Chip Debugging" oder integrierte Pull-Down-Widerstände oder "wenn die Pins doch mal knapp werden, ist nach oben hin immer noch viel möglich" oder so. Wenn ich da falsch liege, möge der TO mich korrigieren.
:
Bearbeitet durch User
Walter T. schrieb: > Eher so handfeste Vorteile wie "On-Chip Debugging" Das konnte aber seit dem ATmega16 (und damit auch dem größeren Bruder 32) jeder „echte“ ATmega ohnehin. :) (ATmega8 und Nachfolger sind in dieser Hinsicht keine Mega-AVR-Architektur, weshalb man bei den Nachfolgern dann auf das vom ATtiny stammende debugWIRE gesetzt hat.) Also gibt's auch diesbezüglich eher keinen handfesten Grund zum Wechsel. Dennoch wäre der TE sicher gut beraten, insgesamt mal einen Blick auf ARM zu werfen. Wenn er gern beim Atmel Studio bleiben will, dann wären Atmel, ähem, Microchips SAMD und Verwandte die naheliegende Wahl.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Das konnte aber seit dem ATmega16 (und damit auch dem größeren Bruder > 32) jeder „echte“ ATmega ohnehin. :) Stimmt, ich habe implizit angenommen, dass der TO eher nicht mit gehobener Ausstattung (ISP vs. JTAG) vorgeht. Da kann ich natürlich grottenfalsch liegen.
Dann: Gar nicht. Ich hatte den ATmega32 in meiner Heizungssteuerung, und jetzt - glücklicherweise auf DIL40 Sockel - problemlos durch einen ATmega1284 ersetzt. Das Programmieren in Pascal macht soviel Spass, dass ich immer weitere Menus eingebaut habe und die Displaystrings fressen halt Flash. ;-) Das Geniale an den AVRs ist halt, dass man sie mit wenig Code in Betrieb nehmen kann und dann wahlweise Peripherie - ADC, Timer, Uart... zuschalten kann, ohne erst aufwendige Initialisierungsroutinen durchlaufen zu müssen. Und es gibt Alternativen zur Programmierung, von ASM über C, ADA, Pascal, selbst Basic. Und durch die weite Verbreitung dank Arduino werden zumindest die dort verwendeten ATmega328... noch eine Weile verfügbar sein. Microchip wäre ja bescheuert die einzustellen, und wenn da bauen die Chinesen die nach. Sind eigentlich inzwischen ATmega328 Clone aufgetaucht?
Karl K. schrieb: > Sind eigentlich inzwischen ATmega328 Clone aufgetaucht? Meines Wissens nur Recycling-Material. Das aber reichlich.
Jörg W. schrieb: > Meines Wissens nur Recycling-Material. Das aber reichlich. Ja ok. Das gibts auch bei Pollin. ;-)
Karl K. schrieb: > Jörg W. schrieb: >> Meines Wissens nur Recycling-Material. Das aber reichlich. > > Ja ok. Das gibts auch bei Pollin. ;-) Dort ist es aber zumindest als solches deklariert … bei den Chinesen kannst du „ATmega128A“ kaufen, die sich am Ende als recyclete, alte ATmega128 entpuppen, die von völlig verschiedenen Losnummern stammen. Das sieht man aber nur, wenn man sich die Rückseiten ansieht, denn die haben sie nicht gefaket. Auf der Vorderseite sind sie schön neu gelabelt, und sie sind wahre Meister darin, die Pins so sauber zu bekommen, dass sie wirklich wie neu aussehen.
Jörg W. schrieb: > und sie sind wahre Meister darin, die Pins so sauber zu > bekommen, dass sie wirklich wie neu aussehen. Wie bekommt man das hin? Chemisch? Mit viel Gefummel (Schleifpapier, Glasfaserstift und Skalpell) habe ich schon ein paar Chips von Lot befreit und in meine "Museum-Sammlung" (eine Vitrine) gelegt. TQFP64 war da der grösste bisher und man sieht deutlich, dass da dran herumgepfuscht wurde...
Mob schrieb: > Jörg W. schrieb: >> und sie sind wahre Meister darin, die Pins so sauber zu >> bekommen, dass sie wirklich wie neu aussehen. > > Wie bekommt man das hin? Chemisch? Keine Ahnung, ich habe nur Fotos von solchen Teilen gesehen.
Mir sind schon etliche ATXMEGA32E5 vom Chinesen untergekommen (beruflich), die eine zerschossene Production-Row hatten und demzufolge mit falscher Geschwindigkeit liefen, da die OSCCAL-Werte nicht passten. Händisch kalibriert liefen sie ohne Probleme. Will sagen, dass Chips, die bei der Endkontrolle ´rausfliegen, dennoch gern weiterverkauft werden. Die müssen noch nicht mal umgelabelt werden. Bei den Chargen vom autorisierten Fachhändler ist das noch nicht vorgekommen.
H0 schrieb: > Will sagen, dass Chips, die bei der Endkontrolle ´rausfliegen, dennoch > gern weiterverkauft werden. Sollten eigentlich nicht, aber wer weiß, auf welch dunklen Wegen sie dann doch die Fab verlassen haben.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.