Erscheinungsdatum Atmega 2560

Ich nicht. Aber im Datenblatt müsste ein Datum stehen. Am besten Version 
1.0 angucken, der müsste nahezu passen.

Hallo Jan,

Kannst Du bitte auch verraten, warum das wichtig sein könnte?

Für den Freak ist das nicht wichtig.

Der Aufsteiger muss mit Powerpoint darlegen, wie sehr der aktuell im 
Produkt eingesetzte Atmega 2560 schon veraltet ist, um zu begründen, wie 
wichtig ein Facelift ist. Und Jahreszahlen, die weit in der 
Vergangenheit liegen, sorgen für kräftige Emotionen - aber man muss die 
Zahlen halt belegen können...

Bologna Consultant schrieb:
> Für den Freak ist das nicht wichtig.
>
> Der Aufsteiger muss mit Powerpoint darlegen, wie sehr der aktuell im
> Produkt eingesetzte Atmega 2560 schon veraltet ist, um zu begründen, wie
> wichtig ein Facelift ist. Und Jahreszahlen, die weit in der
> Vergangenheit liegen, sorgen für kräftige Emotionen - aber man muss die
> Zahlen halt belegen können...

Und der Entwickler muss sich überlegen, ob er das 12 Jahre alte Teil 
noch wirklich in ein Produkt einbauen soll, das in 2 Jahren erscheint, 
und dann für 15 Jahre produziert werden soll.
Während der Zeit soll das natülich gepflegt werden.

Wenn der ATMEGA jetzt schon 12 Jahre auf dem Buckel hat, wird er gegen 
Ende der Produktlebensdauer schon 29 Jahre alt sein, soll aber weiter in 
großen Mengen kostengünstig beschaffbar sein, und die Firmware soll auch 
noch gepflegt werden.

Wer schon mit 30 Jahre alten Microcontrollern arbeiten musste, kann sich 
überlegen, was das heißt. Das KANN noch ok sein, muss aber nicht.

Ich bin bei einigen älteren STM32-Derivaten schon am Grübeln, ob man die 
noch verwenden sollte. Eben, weil mein Arbeitgeber sogar noch längere 
Laufzeiten hat.

Für die "LED-Steuerung mit ATMEGA" auf Lochraster spielt das alles 
natülich keine Rolle.

Moin,

das Problem hast Du grundsätzlich aber immer. Vorhersagen sind 
schwierig, vor allem, wenn sie die Zukunft betreffen...

Auch eine nagelneue MCU kann morgen irgendwelchen 
"Produktlinienoptimierungen" zum Opfer fallen.

Wenn die entsprechenden Stückzahlen gebraucht werden, langfristige 
Lieferverträge abschliessen oder eben einlagern.

svensson schrieb:
> Auch eine nagelneue MCU kann morgen irgendwelchen
> "Produktlinienoptimierungen" zum Opfer fallen.

Die Wahrscheinlichkeit der Abkündigung einer frisch releasten MCU ist 
allerdings doch deutlich geringer als die einer seit 14 Jahren 
produzierten (unter der Prämisse ansonsten gleicher Bedingungen, d. h. 
z. B. vergleichbar "beliebte" Architektur und Hersteller).
Ansonsten stimme ich Dir zu - allerdings diente soso...'s Beitrag auch 
in erster Linie dazu, Bologna Consultant's Geschwafel etwas den Wind aus 
den Segeln zu nehmen.
Natürlich wird man für ernsthafte (TM) Anwendungen immer versuchen, 
möglichst unmittelbar entsprechende Langzeitverträge mit dem Hersteller 
einzugehen - vielen KMUs fehlt dazu aber schlichtweg das notwendige 
Standing in Form genügend hoher Stückzahlen bzw. Umsätze. Und wer sich 
schon einmal mit dem Thema "Einlagerung" befasst hat, weiß, dass auch 
das nicht ohne ist, womit es durchaus auch eine valide Strategie sein 
kann, auf eine möglichst lange Serienlaufzeit der MCU zu pokern.

Toni Tester schrieb:
> Die Wahrscheinlichkeit der Abkündigung einer frisch releasten MCU ist
> allerdings doch deutlich geringer als die einer seit 14 Jahren
> produzierten

Du hast noch nie mit Bauteilen von Maxim gearbeitet?

Marten Morten schrieb:
> Du hast noch nie mit Bauteilen von Maxim gearbeitet?

Erfahrene Entwickler meiden Bauteile von Maxim.
Ich kenne Firmen, wo Maxim auf der schwarzen Liste steht.

Infineon und OSRAM arbeiten derzeit auch in diese Richtung.

svensson schrieb:
> Auch eine nagelneue MCU kann morgen irgendwelchen
> "Produktlinienoptimierungen" zum Opfer fallen.

Wenn man ein Produkt plant, und der ATMEGA hat am Ende der 
Produktlebenszeit 30 Jahre drauf, ist das eine Fehlplanung. Microchip 
kündigt ja nicht ab, sondern erhöht die Preise.
Es wäre ziemlich dämlich, ausgerechnet bei ATMEGAs Uraltteile zu 
verwenden, wo doch die Serie ngelneue zu bieten hat. Warum wollte man 
das tun?

Alex D. schrieb:
> Ein ganz einfacher Grund wäre, dass der Entwickler bzw. die
> Entwicklungsabteilung den ATMega2560 schon länger verwendet und
> eventuell Erfahrung oder fertige interne Libraries hat, deren Portierung
> Aufwand mit sich bringt. Besonders der Umstieg auf die AVR-0 Serie ist
> aufwendiger, da sich an der Peripherie doch einiges geändert hat.

Wie stellt ihr euch das vor, bis in alle Ewigkeit auf dem uralten Ding 
verharren, weil man nichts neues lernen darf? Auch nicht so was minimal 
neues, wie einen neuen Abkömmling der gleichen Familie?
Für immer neue Projekte?

Was macht ihr in 20 Jahren, Museen plündern? In Elektroschrott wühlen?

Wir reden hier nicht von einer großen Umstellung wie ATMEGA -> STM32 
oder dergleichen, sondern minimalen Änderungen in der gleichen 
µC-Familie. Gleiche Toolchain, gleiche Arbeitsweise, ähnliche 
Datenblätter...

Die µC-Familien, mit denen ich bisher gearbeitet hatte, haben keine so 
gewaltingen Unterschiede gehabt, dass ein kompetenter Firmwareentwickler 
damit einen nennenswerten Prozentsatz seiner Zeit verbracht hätte.

> Microchip kündigt ja nicht ab, sondern erhöht die Preise.

Na und? Wenn ein Kunde unbedingt auf ein Ersatzteil angewiesen ist, dann 
zahlt er eben gerne auch etwas mehr.

So sollte ich letztes Jahr einen Server neu kaufen, der mit 32-Bit 
Win2K3 läuft. Preis spielt da keine Rolle, da das daranhängende Gerät 
hoch sechsstellig kostet.

nehmt einen Z80 oder 8051, die wird es noch in 100 Jahren geben  :-)

Karl M. schrieb:
> Hallo Jan,
>
> Kannst Du bitte auch verraten, warum das wichtig sein könnte?

Das möchte ich nicht verraten und hat auch garnichts mit dem Thema zu 
tun!

soso... schrieb:
> Wie stellt ihr euch das vor, bis in alle Ewigkeit auf dem uralten Ding
> verharren, weil man nichts neues lernen darf?

Nicht ganz so extrem. Immer gleiche auf alles neue zu wechseln ist Zeit- 
und Geldverschwendung. Nicht nur in diesem Fachbereich.