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