Forum: Mikrocontroller und Digitale Elektronik Atmega und Langzeitlieferbarkeit


von Anselm 6. (anselm68)


Lesenswert?

Hoi,

nun habe ich es geschafft meinen Chef davon zu überzeugen ein Gerät 
anstatt 2Platinen Analog, mit einer 3/4 und µC zu machen.
Nun fragt er mich, wie lange die lieferbar sind.
Er träumt von 10 Jahren oO
geplant ist ein Atmega128 (ist eh arg überdimensioniert)

Weiss da jemand drüber Bescheid?

Gruß Anselm

von Gast (Gast)


Lesenswert?

>Er träumt von 10 Jahren oO
>geplant ist ein Atmega128 (ist eh arg überdimensioniert)

Einen Prozessor zu nehmen, der überdimensioniert ist, verursacht nur 
Kosten ohne Nutzen.
Wenn z.B. ein ATmega32 reichen würde, nimm diesen und lege im 
Zweifelsfall soviel auf Lager, daß zwei Monate Fertigungsreserve sind. 
Zum Mega32 gibt es pinkompatible Nachfolger, sodaß man nicht auf diesen 
speziellen Typ angewiesen ist.

In der heutigen Zeit, kann keiner sagen, welche Firmen in zehn Jahren 
noch existiern werden.

von tüddel (Gast)


Lesenswert?

die neuen atmegax8 (48/88/168/328) sind bei atmel die sozusagen neue 
plattform. von daher würde ich sagen das diese derivate länger verfügbar 
sein werden

von Thorsten S. (thorsim)


Lesenswert?

Hallo Anselm 68,

evtl. macht's auch Sinn einen Teil der Schaltung (uC + 
Grundbeschaltung) als Steckmodul auszuführen und bei 
Beschaffungsproblemen nur ein neues Modul zu stricken.
Sowas gibt's entweder fertig zu kaufen oder Du definierst was Eigenes.
Ob's sich in Deinem Fall lohnt kann ich natürlich nicht sagen.

Gruß,
Thorsten

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Gast wrote:
> Einen Prozessor zu nehmen, der überdimensioniert ist, verursacht nur
> Kosten ohne Nutzen.

Das kommt darauf an - handelt es sich nur um geringe Stückzahlen und 
haben die Entwicklungskosten hohen Anteil am Endpreis, so würde ich 
lieber eine Nummer größer wählen.
Erfahrungsgemäß kommen immer noch viele Kundenwünsche, wenn die 
Entwicklung schon läuft - da ist man für Reserve sehr dankbar.
Das Design komplett umzuschmeißen, weil man einen größeren Controller 
benötigt, kann da unter Umständen deutlich teurer werden.
BTDT.

Bei hohen Stückzahlen kann der Preis natürlich wieder wichtig sein - wie 
gesagt: es kommt darauf an.

> Wenn z.B. ein ATmega32 reichen würde, nimm diesen und lege im
> Zweifelsfall soviel auf Lager, daß zwei Monate Fertigungsreserve sind.
> Zum Mega32 gibt es pinkompatible Nachfolger, sodaß man nicht auf diesen
> speziellen Typ angewiesen ist.

Ja, das ist ein guter Vorschlag.

Oder direkt auf 8051-Architektur setzen - die Dinger gibt es von 
Dutzenden von Herstellern und wohl auch noch in 50 Jahren ;-)

> In der heutigen Zeit, kann keiner sagen, welche Firmen in zehn Jahren
> noch existiern werden.

Das stimmt leider - deswegen möglichst einen Typen nehmen, den mehrere 
Anbieter produzieren.

Chris

von DerDan (Gast)


Lesenswert?

Hallo,

zugegeben gibts die 8051 schon ne ganze Weile, aber sich deshalb mit den 
8051 rumzuärgern ???


Wenn es nicht so sehr auf den Stückpreis ankommt, dann kann man auch 
über 32Bit Typen nachdenken, Irgendwas mit ARM oder so. Die gibt es auch 
von verschiedenen Herstellern und sind preislich auch nicht so 
unterschiedlich zu den Atmegas. Gerade weil das offensichtlich eine 
Mess- oder Regelanwendung gibt, gehen die Berechnungen mit 32Bit einfach 
schöner.


mfg DerDan

von Christoph Z. (rayelec)


Lesenswert?

>zugegeben gibts die 8051 schon ne ganze Weile, aber sich deshalb mit den
>8051 rumzuärgern ???

Rumärgern?

Nimm einen Silabs C8051Fxxx, den kannst du bequem in C programmieren und 
in-Circuit debuggen. Allzuviel Ärger sehe ich da nicht...

...hingegen gibt's auch da wieder keine echte Second Source...

Gruss
rayelec

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Der Trend geht vor allem zu immer kleineren Betriebsspannungen. Es kann 
sein, dass 3,3V in zehn Jahren schon zu viel ist. Also beim Design auf 
diesen Punkt achten. Ein Controller läßt sich irgendwie ersetzen, aber 
die vielen Schnittstellenanpassungen über Pegelwandler kosten Platz.

von DerDan (Gast)


Lesenswert?

Das man den 8051 in C programmieren kann hab ich ja nicht bezweifelt.

Alleine schon die vielen unterschiedlichen Datenbereich für Variablen 
...
(idata, bdata, xdata ...)

Wo man von Hand dafür sorgen muss alles ausgewogen zu allozieren.

Damit der 8051 Daten umkopieren kann, haben die meisten irgendwelche 
sogenannten Erweiterungen z.B. in Form von zusätzlichen Datenpointern.

Die Compiler ignorieren solche Erweiterungen weitgehend. Damit man sie 
nutzen kann, muss man in Assembler schreiben.

Meist kann man durch Assembler Programme 8051 Funktionen um den Faktor 2 
bis 10 beschleunigen. Was dazu führt, dass die meisten 8051 Projekte 
einen erheblichen Assembler Anteil haben.

Bei den Atmegas z.B. habe ich auch Funktionen gesehen, die durch 
Assembler Unterstützt sind. Dabei ist der Geschwindigkeitsvorteil 
maximal Faktor 1.5
Sodas man eigentlich nicht darauf angewiesen ist.

Bei einem neuen Projekt wurde ich schon darauf achten, dass man es 
vollständig in C programmieren kann, was meiner Ansicht nach den 8051 
deutlich ausschließt.

Richtig Portierbar ist C im embedded Bereich sowieso nicht. Aber sich 
dann auch noch mit Assembler rumärgern? Und das auch noch einem Neuling 
empfehlen?

mfg DerDan

von Gast (Gast)


Lesenswert?

>DerDan (Gast)

Was war nun Deine Frage?

von (prx) A. K. (prx)


Lesenswert?

Man kann auch 8051 anständig in C programmieren, sollte dies aber (wie 
auch bei den PICs) mit der Schere im Kopf tun, d.h. wissen was gut und 
was schlecht umsetzbar ist. Bei AVRs ist dies nicht in gleichem Umfang 
notwendig.

Man wird letztlich Prioritäten setzen müssen. Langfristige 
Verfügbarkeit, niedrige Kosten und gute Programmierbarkeit ohne 
spezifische Hürden kriegt man nicht oft alles zusammen.

von Peter D. (peda)


Lesenswert?

DerDan wrote:

> Meist kann man durch Assembler Programme 8051 Funktionen um den Faktor 2
> bis 10 beschleunigen. Was dazu führt, dass die meisten 8051 Projekte
> einen erheblichen Assembler Anteil haben.

Lach.

Nur wenn man mit der Holzhammermethode programmiert, ohne Rücksicht auf 
die Architektur des 8051, also das LARGE-Modell.

Ich habe null Assembler drin, weil damit höchstens vielleicht 5% zu 
schaffen sind, d.h. das lohnt nicht den Aufwand.
Besonders Interrupts sind sehr effektive, z.B.:
1
stmt level    source
2
3
   1          #include "main.h"
4
   2
5
   3          bit main_timer0;
6
   4
7
   5          static uchar count_main_timer0;
8
   6
9
   7
10
   8          void t0_interrupt( void ) interrupt INT_T0
11
   9          {
12
  10   1        TH0 = 0xFF & (-T0_PRELOAD >> 8);
13
  11   1        TL0 = 0xFF & -T0_PRELOAD;
14
  12   1        if( --count_main_timer0 == 0 ){
15
  13   2          count_main_timer0 = MAIN_TIMER0 / 1e-3;
16
  14   2          main_timer0 = 1;
17
  15   2        }
18
  16   1      }
19
C51 COMPILER V5.02,  TIMER
20
21
ASSEMBLY LISTING OF GENERATED OBJECT CODE
22
23
24
             ; FUNCTION t0_interrupt (BEGIN)
25
                                           ; SOURCE LINE # 8
26
                                           ; SOURCE LINE # 10
27
0000 758CF9        MOV     TH0,#0F9H
28
                                           ; SOURCE LINE # 11
29
0003 758A81        MOV     TL0,#081H
30
                                           ; SOURCE LINE # 12
31
0006 D50005  R     DJNZ    count_main_timer0,?C0002
32
                                           ; SOURCE LINE # 13
33
0009 750013  R     MOV     count_main_timer0,#013H
34
                                           ; SOURCE LINE # 14
35
000C D200    R     SETB    main_timer0
36
                                           ; SOURCE LINE # 15
37
                                           ; SOURCE LINE # 16
38
000E         ?C0002:
39
000E 32            RETI
40
             ; FUNCTION t0_interrupt (END)

Das ist exakt so gut wie Assembler.


> Bei den Atmegas z.B. habe ich auch Funktionen gesehen, die durch
> Assembler Unterstützt sind. Dabei ist der Geschwindigkeitsvorteil
> maximal Faktor 1.5

Naja, der AVR-GCC macht doch einige Sachen sehr unglücklich, da kann 
Assembler wesentlich mehr bringen.
Insbesondere die R0,R1-Orgie in Interrupts ist teuer, weil ja R0,R1 für 
MUL,LPM,SPM reserviert sind.


> Sodas man eigentlich nicht darauf angewiesen ist.

Leider manchmal doch.


Peter

von DerDan (Gast)


Lesenswert?

Hallo peda,

Ich will ich jetzt hier nicht streiten, aber es ist immer einfach, ein 
Funktion zu finden, welche der 8051 auch gut umsetzt. Mit dem Faktor 
2..10 hab ich auch Fälle gemeint, bei denen man die 8051 Erweiterung 
braucht, aber kein Compiler richtig einbaut. z.B. größere Mengen 
Speicher verschieben.

Warum gibt es beim 8051 die unterschiedlichen Speichermodelle überhaupt?

Bei der 16Bit Erweiterung des 8051 nämlich der 166 Familie hat man 
diesen Mist gleich wieder mitgenommen.

Beim Avr gibt es keine unterschiedlich Speichermodelle.

Das der AVR-GCC manche Sachen nicht optimal löst ist schon richtig, aber 
normalerweise ist er immer Dicht dran.
Schlimm wird es im AVR-C-Quelltext, wenn man Daten im Flash ablegen 
will.

Ansonsten kann man eben ohne große Rücksicht auf die Architektur des 
Atmegas in C programmieren.

Übrigens solle die MPS340 da noch besser sein.

Es gibt doch einen BEitrag in dem die C-Programmierbarkeit einzelner 
Familien gegenüber gestellt wird.


http://www.mikrocontroller.net/articles/AVR_PIC_51-Vergleich

mfg

DerDan

von (prx) A. K. (prx)


Lesenswert?

DerDan wrote:

> Warum gibt es beim 8051 die unterschiedlichen Speichermodelle überhaupt?

Langfristiges Denken war bei Intel früher kaum anzutreffen - und wo 
doch, dort ging es gründlich in die Hose (iAPI432). Und so war der 8051 
auf 128 Bytes RAM optimiert mit Option auf 256. Mehr war nie vorgesehen.

Das war damals eine durchaus natürliche Menge und passt ja auch prima zu 
einem 8bitter. Dass diese Architektur auch 3 Jahrzehnte später noch 
verwendet wird, das war damals so nicht geplant.

Für mehr hatte Intel eigentlich die 8096 Architektur vorgesehen. Der 
Markt sah das anders. Kennt noch wer 8096? Mit 8086 war's ja ähnlich, 
auch die war nicht auf Dauer geplant.

> Beim Avr gibt es keine unterschiedlich Speichermodelle.

Weil AVR Mitte der 90er konzipiert wurde, also fast 2 Jahrzehnte später. 
Und trotzdem im ersten Entwurf mit Banking, wogegen Leute mit mehr 
Einblick in Compiler ihr Veto einlegten. Anno Design des 8051 hat man 
Controller fast nur in Assembler programmiert, und vielleicht ein paar 
unverzagte in PL/M oder auch mal Basic.

Kannst dir ja mal ein paar Vorläufer von 8051 ansehen, also 8048 
(Intel), 3850/F8 (Fairchild) oder PIC (General Instrument). Dagegen 
wirkt 8051 direkt modern.

von Stefan W. (wswbln)


Lesenswert?

DerDan wrote:
>... Irgendwas mit ARM oder so.
> Die gibt es auch von verschiedenen Herstellern...

LOL!

Dann tausche in einem Design schnell mal 'nen AT91SAMxxx mit 'nem 
STR7xx. Sind beides ARM7-Controller...

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
Noch kein Account? Hier anmelden.