Forum: Mikrocontroller und Digitale Elektronik Atmel ist unter "Profis" nicht gerade beliebt - Warum?


von Thomas A. (Gast)


Lesenswert?

Hallo Leute,

ich habe nun schön öfter davon gelesen / gehört, dass Atmel (AVR's) 
unter "Profis" nicht gerade bleibt sein soll. Keiner konnte mir 
allerdings sagen weshalb dem so ist.

Ich selbst bin kein "Profi", weshalb ich auch keine Antowort dafür parat 
habe!

Kann jemand etwas dazu sagen, bzw. kann begründen weshalb die Controller 
mehr im Hobby- als im Profibereich Gefallen finden?

Danke vorab.

Thomas

von Frank N. (arm-fan)


Lesenswert?

Atmel produziert die AVRs mit Sicherheit nicht (nur) für den Hobby-
Bereich! Sie werden dafür schon ihre Kunden in der Industrie haben.

Welche das sind, kann ich dir jedoch auch nicht sagen.

von hoerst (Gast)


Lesenswert?

Uns z.B.
Steuerungshersteller.

Finden Verwendung in Billigstmodulen wo der 8051er zu langsam ist bzw. 
schneller dann auch gleich mehr kosten.

von Jörg B. (manos)


Lesenswert?

Die Aussage finde ich persönlich ein wenig vage.
Was ich mir vielleicht denken könnte ist, dass man eine bisher verbaute 
Hardware nicht ohne weiteres wechseln möchte da vielleicht Know-How 
aufgebaut wurde und das entsprechende Testumfeld bereits vorhanden ist 
(8031er, PIC etc.).
Gründe die explizit gegen Atmel sprechen würden mir sonst keine 
einfallen.

von Matrix (Gast)


Lesenswert?

Das würde ich so nicht sagen. In dem Großbetrieb in dem ich meine 
Ausbildung gemacht habe werden in sämtlichen neuen Geräten AVRs verbaut 
(zB Mega8, 16, 128 hab ich da schon gesehen)

Der AVR wird vlt nicht so weit verbreitet sein wie andere Controller 
aber in einigen neuen (hochwertigen) Produkten kannst du ihn sicher 
finden.


Du solltest aber nicht vergessen das Atmel noch weitausmehr verkauft wie 
AVR Controller. Ich hatte schon haufenweiße Geräte wo ein Atmel IC drauf 
ist. Von Festplatten über WLAN-Module bis hin zu Switches hab ich schon 
ICs von denen gefunden ^^

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Wir verwenden ATMega128, ATMega168, ATMega1280 und ATTiny2313 in unseren 
Produkten (Netzwerk-Management-System). In meinem Zweitjob verwende ich 
alle möglichen ATMegas und ATTinys zur technischen Unterstützung 
(Tonstudio).

von Hauke R. (lafkaschar) Benutzerseite


Lesenswert?

Ja oft findet man Flash speicher und EEPRoms.
Außerdem sind wie gesagt die Atmels noch lange nicht so "alt" wie 8051 
und PIC. Im Hobby bereich fängt man eben schneller mal mit nem neuen 
controller an.

von Hauptschul-Ing (Gast)


Lesenswert?

Atmel hat sich offenbar im Automotive Bereich unbeliebt gemacht. 
Qualitaet, Zuverlaessigkeit, Abkuendigung, ... Grosse Unternehmen haben 
eine Rangliste an Zulieferern in dem es auch einen Bereich "Zu 
vermeiden" gibt. Eine derartige Rangliste dient als Druckmittel fuer 
Zulieferer. Atmel hat sich offenbar ein paar Patzer geliefert wonach sie 
nun erstmal nicht mehr in Betracht gezogen werden.

von Mario H. (djacme)


Lesenswert?

Vor einigen Jahren war Atmel im Vergleich zum Wettbewerb zu teuer 
(Jahres-stückzahlen im Bereich von 50k)Ob das jetzt noch so ist kann ich 
nicht sagen. Zu der Zeit waren für uns vergleichbare Pics deutlich 
günstiger.

von Punktrichter (Gast)


Lesenswert?

Früher waren sie sehr EMV-labil. Das hat sich aber geändert.
Abkündigungen und falsche Lieferzeitangaben über Nachfolgeprodukte gibt 
es aber leider immer noch und das kommt nicht gut an.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Preislich und funktionell gibt es für die laufende Serie der AVRs keine 
Alternative. Früher oder später werden das auch noch die stursten 
Ingenieure begreifen (Anwesende ausgeschlossen). Der kommende XMega wird 
die Lücke zwischen 8- und 32Bittern schließen, was Performance, Preis 
und Bedienerfreundlichkeit angeht. Erst recht, wenn man sich schon 
jahrelang mit AVRs beschäftigt hat. Fairerweise muß ich sagen, daß wir 
2004 mit den AVRs gestartet sind und da waren sie schon so stabil, daß 
sie für unsere Anwendungen mehr als ausreichten. Bis heute gab es nicht 
einen Grund, den Hersteller oder gar die Architektur zu wechseln.

von Kai (Gast)


Lesenswert?

in elektrischen Zahnbürsten und Rasierern einer großen mit "B" 
beginnenden Firma sind die auch verbaut.
Denke aber auch, dass sobald die Xmegas kommen noch mehr auf AVRs 
umsteigen werden

von Robin T. (rotoe) Benutzerseite


Lesenswert?

Hoffentlich gibts fürs STK500 ne Erweiterung für Xmegas's wenns soweit 
ist.

von Kai (Gast)


Lesenswert?

für die xmegas ist das STK600 vorgesehen, was mir privat aber zu teuer 
ist...

von Patrick S. (kof)


Lesenswert?

Wir verwenden AVRs recht ungerne - haben sie aber trotzdem in einigen 
Entwicklungen.
Grund hierfür sind u.a. die Fusebits und das es keinen seriellen 
Bootloader gibt. Es ist für unsere Fertigung mit zusätzlichen Kosten 
verbunden diese zu Prorammieren... und da wir oft nur kleine Typen 
benutzen dazu meist auch keine großen Stückzahlen bzw Kleinserien und 
Prototypen ist kaum ein finanzieller anreiz da extra Hardware für sie zu 
benutzen, wenn ein preisgleicher/funktionsähnlicher uC mit Bootloader 
keine weitere Hardware benötigt.

von Sebastian (Gast)


Lesenswert?

Also wir verwenden von Atmel nur die ASK/FSK Transceiver. Ansonsten 
arbeiten wir mit den uC von NEC aber warum das weiß irgendwie niemand 
hier

von Rufus (Gast)


Lesenswert?

Und immer noch beachten, dass Atmel als parallele Linie auch reichlich 
viele 8051er neu entwickelt und herstellt, die also noch lange nicht tot 
sind.
So ziemlich alle 8051er mit CAN-Bus ON-Chip (z.B. der CC03er) haben 
bereits seit Jahren die Automobil-Zulassung und werden dort in Mengen 
eingesetzt !
Da können die AVRs (noch) von träumen.

Rufus

von JÜrgen G. (Firma: 4CKnowLedge) (psicom) Benutzerseite


Lesenswert?

Patrick S. wrote:
> Wir verwenden AVRs recht ungerne - haben sie aber trotzdem in einigen
> Entwicklungen.

Geschmackssache

> Grund hierfür sind u.a. die Fusebits und das es keinen seriellen
> Bootloader gibt.

Bootloader -> gibts sehr wohl!

> Es ist für unsere Fertigung mit zusätzlichen Kosten
> verbunden diese zu Prorammieren...

Ponyprog Script macht alles automatisch... Muss sich halt mal einer 
hinsitzen und das schreiben ^^

von Sven P. (Gast)


Lesenswert?

Patrick S. wrote:
> Grund hierfür sind u.a. die Fusebits und das es keinen seriellen
> Bootloader gibt. Es ist für unsere Fertigung mit zusätzlichen Kosten
> verbunden diese zu Prorammieren...

Das verstehe ich absolut nicht. AVRs machen doch in 90% der Fälle nix 
anderes als In-system-programmierung, und die per SPI, also seriell. Und 
da werden in einem Rutsch auch die Fuses mitprogrammiert... was soll 
dadran zusätzliche Kosten verursachen? Ich meine, komfortabler kanns 
auch der beste Fertigungsroboter nicht haben, als lediglich vier 
Kontakte zu verbinden...

von Mike (Gast)


Lesenswert?

Bei uns werden AVR's nur für Betriebsmittel, Kleinserien etc. verwendet. 
Grund ist im Wesentlichen das mangelnde Vertrauen in die langfristige 
Lieferbarkeit. Im Gegensatz zu Architekturen wie 8051, ARM etc. gibt es 
keinen Zweithersteller, auf den man im Notfall ausweichen könnte. Sollte 
Atmel z.B. mal Konkurs gehen, muessten wir saemtliche Software auf eine 
andere Architektur portieren. Bei weitverbreiteten Architekturen müsste 
man nur den Chip wechseln und einige IO Routinen anpassen, den Compiler 
und damit den Grossteil der Software kann man im Allgemeinen 
weiterverwenden.

Gruss
Mike

von gast (Gast)


Lesenswert?

> sollte Atmel z.B. mal Konkurs gehen, (...)
hmmmm... war ja nur ein Beispiel ;-)

von Rufus (Gast)


Lesenswert?

Konkurs ist nicht das Problem, sondern die komplette Abkündigung von 
Chips, auf die man als (kleiner) Mittelständler wohl kaum einen Einfluss 
hat.
Und das ist dann das Aus für das Produkt.

Rufus

von Marvin M. (Gast)


Lesenswert?

@Rufus:
Bislang gabs aber eigentlich immer ein pinkompatibles Nachfolge-Modell 
(zumindest ist mir da keine Ausnahme bekannt).
Zum Beipiel: AT90S2233 / 4433 -> Mega 8, AT90S2313 -> Tiny2313....

von holger (Gast)


Lesenswert?

>Bislang gabs aber eigentlich immer ein pinkompatibles Nachfolge-Modell

Sicher, aber ATMEL ändert dauernd Register und Bitnamen.
Das nervt gewaltig. Jedesmal muss man die Sources neu anpassen.

Da gibts dann schöne #ifdef #else #endif Kaskaden im Code.
Eine gewisse Durchgängigkeit wäre schon wünschenswert.

von crazy horse (Gast)


Lesenswert?

naja, also zumindest im meiner Firma ist es auch nicht mehr wie früher, 
dass da Produkte jahrelang vom Band laufen. 2 Jahre ist heute schon 
viel. Ich setze sehr viele AVRs ein, aber auch andere MCs. Es gibt oft 
genug auch in dieser kurzen Produktlaufzeit Softwareupdates - es wäre 
also auch kein Problem, einen pinkompatiblen Ersatztyp mit leichten 
Softwaremodifikationen einzusetzen. Ich bin von Atmel immer rechtzeitig 
informiert worden, wenn sich was tut - war nie ein Problem.
Insgesamt setze ich pro Jahr um die 40.000 MCs um, ca. 80% davon AVR. 
Für mich ist es oft genug der ideale Prozessor. Und ohne guten Grund 
gehe ich davon nicht ab.
Ausnahmen sind:
-ausdrücklicher Kundenwunsch
-mangelnde Rechenleistung
-fehlende Peripherie (insbesondere CAN und Ethernet)

von Chris (Gast)


Lesenswert?

Das liegt an alten Sturköpfen, die ihre Meinung so weitergeben.

Ich dachte ich glaubs nicht als ich an einem Tag der offenem Tür vor 
etwa einem Jahr an der Hochschule, an der ich jetzt selber bin, von 2 
Studenten beim Wort Atmel schon fast belächelt wurde. Das wäre ja eher 
was für Bastler ...

Und das von Figuren, die wahrscheinlich noch nie was anderes gesehen 
haben als das Inventar der Hochschule. Woher also die Meinung nur kommt 
?

von Jadeclaw D. (jadeclaw)


Lesenswert?

holger wrote:
>>Bislang gabs aber eigentlich immer ein pinkompatibles Nachfolge-Modell
>
> Sicher, aber ATMEL ändert dauernd Register und Bitnamen.
> Das nervt gewaltig. Jedesmal muss man die Sources neu anpassen.

Das nervt in der Tat. Und manchmal frage ich mich, ob den Entwicklern 
irgendwas in den Kaffee gerührt wird.
Point in Case: ATMega48. Ein kleineres Projekt sollte vom ATMega16 in 
den ATMega48 umziehen. Und dann ging es los, jede Menge IN/OUT durch 
LDS/STS ersetzen, weil die Schlafmützen bei Atmel es nicht geschafft 
haben, alle Peripherieregister im regulären Bereich unterzubringen. 
Platz wäre ja genug gewesen.

--------------------------------------------------------
Zur Originalfrage: Atmel unbeliebt? Oder besser gesagt: AVR unbeliebt?
Glaube ich nicht. Aber die 8051er Schiene ist in der Industrie noch sehr 
stark vertreten. Ist ja auch kein Wunder bei mehr als 15 Jahren 
Vorsprung.

@Chris: Es begann im Embedded-Bereich mit 2 Linien: Intel und Motorola. 
Motorola mit 6801, später dann 6805, Intel mit 8048 und folgend 8051. 
Und damit folgten die Anbieter von Lehrmaterial eben auch diesen 2 
Linien. Und das Zeug ist noch vorhanden und muß eben genutzt werden. 
Ausnahmen gibt es auch, da ist doch mal einer mit 8085-Fortbildung hier 
aufgeschlagen. Bei soetwas muß man sich nicht wundern, wenn da ein 
gewisser Elfenbeinturm-Effekt eintritt.


Gruß
Jadeclaw.

von Walther Z. (chilipower)


Lesenswert?

Hallo,

ich programmiere schon seit Jahren den AVR (gezwungenermassen) und bin 
eigentlich in der Assemblerszene um die 8086 Cpu heimisch. Für mich ist 
der Befehlscode einfach extrem schlecht und ineffektiv im Vergleich zu 
anderen Cpus. Man merkt bereits an der Zusammensetzung der Befehle (und 
auch am Codeaufbau), dass bei der Entwicklung keine Könner am Werk 
waren. Dazu kommt noch, dass die (so hochgelobte) RISC-Architectur einen 
sehr klugen Compiler benötigt der von Atmel einfach nicht geliefert 
wird. (Aus Kompatibilitätsgründen arbeite ich nur mit diesem.) Auch 
Gnu-Compiler sind absolut keine Lösung um schnelle und flexible Routinen 
zu schreiben.

Dazu kommt noch, wenn ich mir die Entwicklung des Original-Compilers 
(über die letzten 6 Jahre) anschaue, ein ganz schlechter Support.
Auf gemeldete Bugs werden automatisierte Mails geschrieben die den 
Anschein erwecken sollen, sie wären direkt von Personen verfasst worden. 
Viele einfache Fehler werden überhaupt nicht sauber oder viel zu spät 
gefixt. Dazu zählt z.B die bedingte Programmierung die am Anfang 
überhaupt nicht sauber funktioniert hat und erst nach einem Jahr gefixt 
wurde. (In meiner Firma wären dafür schon lange Köpfe gerollt und ich 
habe mich darüber immer sehr geärgert). Atmel ist für nur noch Bah!

 (Konnte man früher höchstens des Preises wegen kaufen)


mfg

von Andreas K. (a-k)


Lesenswert?

Jadeclaw Dinosaur wrote:

> weil die Schlafmützen bei Atmel es nicht geschafft
> haben, alle Peripherieregister im regulären Bereich unterzubringen.
> Platz wäre ja genug gewesen.

Ich glaube das war andersrum gemeint. Nach dem Wildwuchs vorher sollte 
wohl mit der neuen I/O-Map etwas mehr Einheitlichkeit einziehen.

Weil du sonst beim Upgrade von Mega48 auf Mega164 (oder was auch immer) 
auch genau dieses Problem hättest.

Ausserdem sollte man die Dinger in C programmieren.

von Andreas K. (a-k)


Lesenswert?

Walther Z. wrote:

> Dazu kommt noch, wenn ich mir die Entwicklung des Original-Compilers
> (über die letzten 6 Jahre) anschaue, ein ganz schlechter Support.

Gibt es von Atmel tatsächlich einen Original-Compiler?

von crazy horse (Gast)


Lesenswert?

ich kenn keinen.

von NO8086 (Gast)


Lesenswert?

@ Walther Z.
> ich programmiere schon seit Jahren den AVR (gezwungenermassen) und bin
> eigentlich in der Assemblerszene um die 8086 Cpu heimisch. Für mich ist

Also du bist Assembler-8086 Obermaker.

> der Befehlscode einfach extrem schlecht und ineffektiv im Vergleich zu
> anderen Cpus. Man merkt bereits an der Zusammensetzung der Befehle (und
> auch am Codeaufbau), dass bei der Entwicklung keine Könner am Werk
> waren. Dazu kommt noch, dass die (so hochgelobte) RISC-Architectur einen
> sehr klugen Compiler benötigt der von Atmel einfach nicht geliefert

Braucht man für Assembler ein !Compiler! ???

> wird. (Aus Kompatibilitätsgründen arbeite ich nur mit diesem.) Auch
> Gnu-Compiler sind absolut keine Lösung um schnelle und flexible Routinen
> zu schreiben.

Ja aber wenn du als Assembler-Obermaker in Assembler schreibst bestimmst 
du doch wie deine Routinen sind? oder nicht?

Irgendwas stimmt mit dir nicht :-)

von holger (Gast)


Angehängte Dateien:

Lesenswert?

>> Sicher, aber ATMEL ändert dauernd Register und Bitnamen.
>> Das nervt gewaltig. Jedesmal muss man die Sources neu anpassen.

Und die Namen der Interruptvektoren. Nur mal so nebenbei.

>Das nervt in der Tat. Und manchmal frage ich mich, ob den Entwicklern
>irgendwas in den Kaffee gerührt wird.
>Point in Case: ATMega48. Ein kleineres Projekt sollte vom ATMega16 in
>den ATMega48 umziehen. Und dann ging es los, jede Menge IN/OUT durch
>LDS/STS ersetzen, weil die Schlafmützen bei Atmel es nicht geschafft

@ Jadeclaw
Du programmierst in ASM. Da wirds ja richtig eklig.
In C versuche ich sowas durch ein paar #define gerade zu biegen.

Dann kommt die neue Compiler Version und die macht in ähnlicher
Weise genau das was ich auch schon versucht habe.
Ja Klasse ! Da gibt es dann Fehlermeldungen ala "already defined".
Und schon muss ich in meinen Header Dateien auch noch eine
Abfrage der Compiler Version einbauen. Es ist echt ein Krampf
mit den Atmels.

Wieso durfte der erste UART nicht einfach weiter UART, und nicht
UART0 heissen ?

Der zweite UART ist dann halt UART1.

Im Anhang mal eine Headerdatei mit den fast vergeblichen Versuchen
da Ordnung in den ersten UART rein zu bringen.

von Gast (Gast)


Lesenswert?

@OT
@serial.h
Schau dir die Libs von Fleury an...

http://homepage.hispeed.ch/peterfleury/avr-software.html#libs

von Stefan M. (Gast)


Lesenswert?

Mit Original-Compiler meint er wahrscheinlich den IAR.

Zum Assembler muß ich mal sagen: Wer heute Mikrocontroller noch in 
Assembler programmiert, hat echt einen an der Klatsche. Oder er ist in 
den 60ern stehen geblieben. Und gerade bei x86 ist das doch der größte 
Unfug. Im Hobby-Bereich mag das ja noch alles gehen, da sag ich ja nix. 
Aber wenn ich die Entwicklungskosten für Software in Assembler gegen 
irgendeine Hochsprache stelle, dann steht der Assembler sehr schlecht 
da. Wie macht Ihr das in Euren Firmen? Wird dort immer noch in Assembler 
gecodet?

Und warum Gnu-Compiler unflexibel sind, das muß mir der 
8086-Assembler-Oberguru auch mal erklären.

ciao, Stefan.

von holger (Gast)


Lesenswert?

>Schau dir die Libs von Fleury an...

Wozu ?

von Mehmet K. (mkmk)


Lesenswert?

Falls die Tatsache, dass ich meine Brötchen mit Elektronik verdiene, es 
mir erlaubt, mich in die Rige der Profis einzuordnen:
Angefangen habe ich mit Z80, dann 8051, kurze Bekanntschaft mit 
Microchips, 2 Projekte mit Rabbit, ein echtes Verliebtsein mit dem C166 
von Siemens (wegen Flash Problemen gebrochene Herzen) .... und dann 
landete ich bei Atmel's AVR's.
Ich arbeite nun jetzt seit weiss-nicht-mehr-wievielen Jahren mit diesen 
MCU's und das einzige, worüber ich meckern könnte, waeren die für meinen 
Geschmack etwas zu kleinen RAM-Grössen.
Anfaenglich arbeitete ich mit dem Compiler von Imagecraft, wechselte 
aber dann über zu GCC. Und den Support, den ich hier finde, kann man 
sich anderswo bestenfalls ertraeumen. Sicher ist GCC nicht für einen 
8-Bitter geschrieben. Aber bei all meinen Projecten, die ich von 
Imagecraft auf den GCC umgeschrieben habe, schnitt der GCC weitaus 
besser ab.

Natürlich gibt es bessere Controller. Eine zeitlang habe ich mit Renesas 
geflirtet. Aber dann kam ich zum Schluss: eine Nummer zu gross für mich. 
Macht ja wenig Sinn, mit Kanonen auf Spatzen zu schiessen.
Sicher würde es mehr Eindruck machen, wenn ich in meine Broschüre einen 
etwas bekannteren Namen einsetzen könnte ... aber was soll's. :)

Also ich bin mit Atmel's Atmega's mehr als nur zufrieden.


Grüsse aus Istanbul

von hellboy (Gast)


Lesenswert?

tja es gab sogar mal eine untersuchung dazu ... effizienz c vs asm ....
c hat gewonnen und das nicht umsonst .... die optimierungen die ein 
compiler macht kann das menschliche hirn kaum leisten und dann noch in 
so nem spagetti code

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Mehmet Kendi wrote:

> Falls die Tatsache, dass ich meine Brötchen mit Elektronik verdiene, es
> mir erlaubt, mich in die Rige der Profis einzuordnen:

Etwas anderes heißt ,,Profi'' ja gar nicht, als dass du damit deine
Brötchen verdienst.

von Mehmet K. (mkmk)


Lesenswert?

@ Jörg Wunsch
:D ich kenne viele "mit-Elektronik-seine-Brötchen-Verdienende" bei denen 
die Bezeichnung 'Profi' echt nicht angebracht waere.

von Uhu U. (uhu)


Lesenswert?

Walther Z. wrote:
> ich programmiere schon seit Jahren den AVR (gezwungenermassen) und bin
> eigentlich in der Assemblerszene um die 8086 Cpu heimisch. Für mich ist
> der Befehlscode einfach extrem schlecht und ineffektiv im Vergleich zu
> anderen Cpus.

Das Maschinendesign ist nicht für ASM-Programmierung gedacht, sondern 
für den Einsatz von Compilern - die kommen damit sehr gut zurecht.

Wenn du einen schönen ASM-µC willst, dann nimm MSP430 - das ist eine 
abgespeckte PDP-11

von Martin (Gast)


Lesenswert?

Hallo,

@Hauptschul-Ing

>Atmel hat sich offenbar im Automotive Bereich unbeliebt gemacht.
>Qualitaet, Zuverlaessigkeit, Abkuendigung, ... Grosse Unternehmen haben
>eine Rangliste an Zulieferern in dem es auch einen Bereich "Zu
>vermeiden" gibt.

nicht so ganz!!

@Frank N. (arm-fan)

>Atmel produziert die AVRs mit Sicherheit nicht (nur) für den Hobby-
>Bereich! Sie werden dafür schon ihre Kunden in der Industrie haben.

>Welche das sind, kann ich dir jedoch auch nicht sagen.

in der Welt der Autombil Industrie wird oder werden schnelle BUS-Systeme 
eingesetzt da, mit hoch geschwindigkeit Daten hin und zwischen Roboter 
und Roboter, Roboter und SPS'en usw. gesendet werden, da kommen nur BUSe 
wie Profibus oder INTERBUS in frage, INTERBUS (Phönix) hat in jeder 
seine Module (also in Herz) ein AVR drin !!!

Gruß
Martin

von Malte _. (malte) Benutzerseite


Lesenswert?

Marvin M. wrote:
> @Rufus:
> Bislang gabs aber eigentlich immer ein pinkompatibles Nachfolge-Modell
> (zumindest ist mir da keine Ausnahme bekannt).
> Zum Beipiel: AT90S2233 / 4433 -> Mega 8, AT90S2313 -> Tiny2313....

Den AT90S2343 gab es nicht mehr zu kaufen es hat doch einige Zeit 
gedauert, bis es ein Nachfolgermodell gab, ansonsten fällt mir aber kein 
weiteres Beispiel ein.

von Mehmet K. (mkmk)


Lesenswert?

Atmega8 ist kein vollwertiger Ersatz für den AT90S2233 / 4433.
Port C kann beim Atmega8 nur als Input benutzt werden. Beim AT90S2333 
ist dieser Port bidirektional.

von Andreas K. (a-k)


Lesenswert?

Mehmet Kendi wrote:

> Port C kann beim Atmega8 nur als Input benutzt werden.

Bitte genauer, das kann ich jetzt nicht nachvollziehen.

von STK500-Besitzer (Gast)


Lesenswert?

>Port C kann beim Atmega8 nur als Input benutzt werden.

Wo steht das? Ich habe die Schnelle nichts gefunden, und in der 
Übersichtszeichnung hat der Port Pfeile in beide Richtugen.

von Peter D. (peda)


Lesenswert?

Mehmet Kendi wrote:
> Port C kann beim Atmega8 nur als Input benutzt werden.

Hä?

Dann bilde ich mir wohl nur ein, daß die LEDs an Port C meines Mega8 
blinken.


Peter

von Mehmet K. (mkmk)


Lesenswert?

In der Tat; womit habe ich das nur verwechselt? Tut mir leid für diese 
falsche Behauptung.

von Tomino (Gast)


Lesenswert?

Die Automobilindustrie setz fast ausschließlich auf HC12/Super12 (z.B. 
Body-Computer), die Einspritzung MPC5xx oder TriCore 32-Bit, ABS/ESP hat 
oft zweimal ARM7-Core, Battery-Sensor ARM7-Clone, NEC850 (Body-Computer, 
Servolenkung), Fujitsu M16 (z.B. Klimaanlage). Ein Grund ist, dass alle 
Autozuliefern zertifizierte Compiler verwenden, oder mind. mit Support 
und Garantie - siehe IEC61508 Table E.3 §5a, weil alle Steuergeräte 
unter SIL-2 oder SIL-3 sind. Bei gcc könnte niemand nix verlangen. Die 
zweite Frage ist Second-Source" für CPU. Deswegen hat AVR geschlossene 
Türe in die Automobilindustrie.

von Jadeclaw D. (jadeclaw)


Lesenswert?

Ich kenne nur einen Controller, der einen dedizierten Eingangsport hat:
ATTiny28. Und da ist es PortB. Macht so aber auch Sinn, da der ATTiny28 
für IR-Fernbedienungen gedacht ist. Bei allen anderen Controllern sind 
alle Ports bidirektional. Auch wenn es oft in der Übersicht anders 
gezeichnet ist. Im nachfolgenden Text ist es dann richtig.

Holger schrieb:

> @ Jadeclaw
> Du programmierst in ASM. Da wirds ja richtig eklig.
Ja. Und in die kleinen Controller (<= 4kB) kommt auch nichts anderes 
rein.
Der Defaultcode, der bei C grundsätzlich mit eingebunden wird, ist mir 
für die kleinen Controller zu groß. Anders würde es bei bei großen 
Projekten und entsprechend großen Controllern aussehen, da fällt das 
dann kaum ins Gewicht. Einen ATMega2560 wird mit Sicherheit niemand mit 
Assemblercode füllen, bei diesen Teilen ist eine Hochsprache die erste 
Wahl.

Gruß
Jadeclaw.

von fubu1000 (Gast)


Lesenswert?

Da muss ich Jadeclaw zustimmen, in C wird zu viel RAM verbraucht der 
unter ASM
nicht anfallen würde.

Kleinere bis mittlere Projekte unter ASM zu programmieren, sehe ich eher 
als Vorteil an, in Richtung Timing oder Übersicht der benutzten 
Resourcen.
Bei grösseren Projekten über 10kB, muss ich zustimmen wird ASM 
irgendwann zu unübersichtlich und langwierig.

Oder die kleineren Attinity's da gibts kein RAM da kann man C vergessen.
Und da bei den AVR's RAM nicht so grosszügig bestückt wird, benutze ich 
meist ASM(aber nichts gegen C++ natürlich).     ;-)

PS:
Wurde schon beschimpft das ich nen MP3-Player in ASM programmiert habe, 
wobei ich in C genauso lang gebraucht hätte. Und ich so vom Mega32 so 
wenigstens die mageren 2kB RAM ausnutzen konnte, für den FAT16 und MP3 
Teil.     ;-/

GRUSS fubu

von Walther Z. (chilipower)


Lesenswert?

> Gibt es von Atmel tatsächlich einen Original-Compiler?
Der Standard Assembler ist gemeint.

>Ja aber wenn du als Assembler-Obermaker in Assembler schreibst bestimmst
>du doch wie deine Routinen sind? oder nicht?

>Irgendwas stimmt mit dir nicht :-)
Schau Dir erstmal mal an welche Features andere Assembler bieten und 
dann reden wir weiter. Atmel hat ja noch nicht einmal ein automatische 
Sprungweitenanpassung. (=> Weitere Diskussion zwecklos!)

>Zum Assembler muß ich mal sagen: Wer heute Mikrocontroller noch in
>Assembler programmiert, hat echt einen an der Klatsche.
Das hängt ja wohl vom Einsatzgebiet und dem Preis/Leistungsverhältniss 
ab. Vor 6 Jahren gab es zu Atmel noch keine grossen Alternativen ausser 
teure ARM-Prozessoren. Heute gibt es billigere und leistungsstärkere 
Cpu's oder Fpga's

>Aber wenn ich die Entwicklungskosten für Software in Assembler gegen
>irgendeine Hochsprache stelle, dann steht der Assembler sehr schlecht
>da.
Eine Menuführung oder Tastatureingaben würde ich auch nicht in Assembler 
programmieren. Aber wenn es auf Platz und Geschwindigkeit ankommt (z.B 
MotorSteurung oder Datenverarbeitung) haste halt keine Alternative. Und 
was Schnelligkeit angeht, haste auch in Assembler Code-Biliotheken die 
du schnell einbinden kannst (einmal programmiert).

>Und warum Gnu-Compiler unflexibel sind, das muß mir der
>8086-Assembler-Oberguru auch mal erklären.
Ich habe den Gnu-Compiler von 6 Jahren eingesetzt. Bei einem 
Interruptaufruf hat er damals alle 16 oder 32 Register auf den Stack 
gepusht und es war nicht abzustellen. Für eine Motorsteuerung höchst 
ineffektiv. (Ich weiss nicht ob es heute anders ist, aber ich mutmasse, 
dass nicht)

>Das Maschinendesign ist nicht für ASM-Programmierung gedacht, sondern
>für den Einsatz von Compilern - die kommen damit sehr gut zurecht.
Ja, das stimmt natürlich. Dennoch sind die Befehle einfach nicht 
ergiebig. Ein Beipsiel sind z.B. die Shift-/Rotataionsbefehle oder ein 
fehlender Bit-Test-Befehl (als And-Verknüpfung) oder das Verhältniss 
zwischen And/Cbr Befehlen (verwirrend). Es gibt einfach zu viele 
unsinnige Befehle die nicht wirklich gebraucht werden und besser hätten 
eingesetzt werden können. Auch der C-Compiler nutzt nur einen kleine 
Codeauswahl aus dem gesamten Befehlscode-Raum. Dies macht die Cpu 
unnötig langsamer verglichen mit anderen Modellen.

walther

von Mehmet K. (mkmk)


Lesenswert?

Meine obige Aussage:
"Atmega8 ist kein vollwertiger Ersatz für den AT90S2233 / 4433. Port C 
kann beim Atmega8 nur als Input benutzt werden. Beim AT90S2333 ist 
dieser Port bidirektional."
.. ist natürlich in dieser Form falsch. Asche über mein Haupt. Der 
Grund, warum ich zu dieser Aussage kam, war der, dass ich hauptsaechlich 
mit TQFP arbeite und einmal, ohne Prototype direkt in die 
Serienanfertigung ging und dabei ADC7 und ADC6 als Outputs benutzten 
wollte. Ging aber nicht. Weil:

ATmega8 in TQFP (and MLF) package supports two ADC channels – ADC6 and
ADC7– on pin 19 and pin 22 respectively. These pins are inputs only

Nach dieser Erfahrung hat sich bei mir vermutlich der Satz "PortC ist 
input, basta" als pawlowsche Reaktion etabliert.

von Paul (Gast)


Lesenswert?

Für Microchip (und gegen Atmel) spricht unsere Erfahrung, daß seit der 
Einführung der PICs vor etwa 20 Jahren sämtliche Typen in jeder 
beliebigen Menge problemlos beschafft werden konnten. Neben der sich 
ständig vergrößernden Typenvielfalt sind aber auch ältere Typen nahezu 
immer lieferbar. Bestehende Layouts können auch ohne Änderunegn für neue 
Typen verwendet werden, die Aufwände für die Softwareanpassungen sind 
verhältnismäßig gering. Auch gibt es nichts am Support und bei der 
Musterbeschaffung zu bemängeln.

Wieso sollten wir also auf andere Familien wechseln, wo wir in der 
Vergangenheit und auch aktuell an vielen Stellen Kosten kleinhalten 
konnten/können? Atmel bietet da offensichtlich deutlich weniger.

Gruß Paul

von Stefan M. (Gast)


Lesenswert?

> Aber wenn es auf Platz und Geschwindigkeit ankommt (z.B
> MotorSteurung oder Datenverarbeitung) haste halt keine Alternative. Und
> was Schnelligkeit angeht, haste auch in Assembler Code-Biliotheken die
> du schnell einbinden kannst (einmal programmiert).


Das sind immer die Killerargumente, die von den Assembler-Profis 
aufgeführt werden. Was ist aber mit anpassbarem, portablen Code? Das 
Stichwort lautet Wartbarkeit. Deine Argumente sind überholt, sie stammen 
aus den 60ern und 70ern. Für Mikrocontroller lasse ich geradeso die 90er 
noch gelten.

Zur Geschwindigkeit wurde weiter oben auch schonmal was gesagt. Für 
Platz gilt dasselbe. Die heutigen CPU-Architekturen schreien geradezu 
nach Compilern. Das was Du mühsam in Assembler aus dem Controller 
rausquetscht, macht der Compiler mit Links. Und alle Atmels, selbst die 
kleinsten Tiny haben mittlerweile RAM.

ciao, Stefan.

von Thomas A. (Gast)


Lesenswert?

Ich bin wirklich begeistert, dass so eine angeregte Diskussion 
entstanden ist... Als Résumé kann man denke ich festhalten, dass es zwei 
Lager gibt.

Lager 1: pro Atmel
Lager 2: contra Atmel

Letztendlich ist wohl das Einsatzgebiet entscheident und jeder 
Controller hat  seine Stärken oder Schwächen in unterschiedlichen 
Anwendungen.

von ... .. (docean) Benutzerseite


Lesenswert?

holger wrote:
>>Schau dir die Libs von Fleury an...
>
> Wozu ?

Da ist das super gelöst...

Was alle AVRs inkl. die mir 2USARTS werden unterstützt

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Tomino wrote:

> Deswegen hat AVR geschlossene
> Türe in die Automobilindustrie.

Ach, und nur für die geschlossenen Türen produzieren sie dermaßen
viele AVRs mit automotive grade?

Du kannst mir viel erzählen, aber diese Zertifizierungen macht wohl
keiner, wenn er nicht auch Kunden dafür hat.  Ich hab nicht nachgesehen,
aber ich vermute mal, dass IAR gegen viel Geld auch die nötigen
Garantien zu geben bereit ist... (vermutlich gegen sehr viel Geld,
denn viel Geld nehmen sie ja schon für die Standardlizenzen :).

von Jens P. (Gast)


Lesenswert?

Thomas A. wrote:

> entstanden ist... Als Résumé kann man denke ich festhalten, dass es zwei
> Lager gibt.
>
> Lager 1: pro Atmel
> Lager 2: contra Atmel

Verzeih mir den blöden Post, aber bist du Hellseher oder woher weisst du 
das?
;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Walther Z. wrote:

>> Gibt es von Atmel tatsächlich einen Original-Compiler?

> Der Standard Assembler ist gemeint.

Der ist auch nur Spaß.  Der Fokus lag offensichtlich von vornherein
darauf, dass ernsthafte Kunden eher in C arbeiten und dass man einen
Controller hat, der gut für einen Compiler ist.  Controller, die man
nur in Assembler ordentlich programmieren kann, gab's schließlich
schon zu Hauf, dafür hätte man nicht erst einen AVR erfinden müssen. ;-)

(C-Compiler bringen ja auch nochmal jeweils ordentliche Assembler
mit, die von den Features her um einiges über dem Atmel-Assembler
liegen.)

von Thomas A. (Gast)


Lesenswert?

> Verzeih mir den blöden Post, aber bist du Hellseher oder woher weisst du
> das?

Ich hatte heute morgen eine göttliche Eingebung :-)

Heute Nachmittag hab ich Atmel in der Firma, da werde ich die Argumente 
mal gegeneinander abwägen lassen :-)

von Punktrichter (Gast)


Lesenswert?

Atmel wird zu Abkündigungen und Lieferzeitproblemen sagen:
"Das gibt es bei anderen Firmen auch"
Sonst haben sie ungeeignete Leute eingestellt.

Wer aber einmal damit Ärger gehabt hat, der vergisst das nicht.
Ich hatte Ärger. Mit PICs aber nie.

Ich mag beide µC-Familien, aber verlässlicher ist Microchip.

von Stefan M. (Gast)


Lesenswert?

@Jörg, da Du sehr aktiv an der AVR Libc und scheinbar auch am Compiler 
mitarbeitest, würde mich Deine Meinung zum gcc für AVR interessieren. 
Kannst Du mal vergleichen, wie gut/schlecht/überragend der gcc gegenüber 
kommerziellen Compilern ist? Ich habe bisher sehr unterschiedliches 
darüber gehört (über sechs Ecken ohne Beleg). Von überragend bis totaler 
Bockmist und für ernsthafte Anwendungen nicht zu gebrauchen. Peter 
Dannegger darf auch gerne seine Meinung sagen, auch wenn ich die Antwort 
schon fast kenne. :-)

mfg, Stefan.

von Michael König (Gast)


Lesenswert?

Was mich an den AVRs etwas stört ist die Tatsache, daß man die Fuse-Bits 
explizit setzen muß. Beim PIC ist das Teil des Hex-Files und dadurch 
deutlich einfacher handhabbar.
Allerdings hat hier jemand PonyPorg Script erwähnt. Vielleicht sollte 
ich mal herausfinden, ob man darüber die Produktion etwas vereinfachen 
kann.

Primär haben wir Erfahrung mit PIC, aber gelegentlich gehen mir da die 
ganzen Errata auf die Nerven. Insbesondere seitdem Microchip versucht 
hat Autobauding einzubauen, sind die UARTs irgendwie ständig verbuggt.

Als wir ein Hardwaredesign mit AVR möglichst schnell fertigstellen 
mußten, hat mir das WinAVR-Tutorial hier sehr viel geholfen. Insgesamt 
kam ich eigentlich vergleichsweise schnell in die unbekannte Architektur 
rein und die Codequalität des GCC hat mich auch positiv überrascht.

Da sich AVR und PIC preislich sehr ähnlich sind und wir mit PIC einfach 
mehr Erfahrung haben, gehe ich aber davon aus, daß wir dennoch 
überwiegend bei PIC bleiben werden.

@Walther Z.:
Für jemanden, der 8086-Assembler programmiert, entbehrt es schon kaum 
Komik, wenn man sich über die Architektur des AVR beschwert. Ich kenne 
nun wirklich einige Architekturen, aber kaum eine führt bei mir so oft 
zu Kopfschütteln wie die IA-32!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Stefan May wrote:

> Kannst Du mal vergleichen, wie gut/schlecht/überragend der gcc gegenüber
> kommerziellen Compilern ist?

Compiler zu vergleichen, ist einfach immer mal sehr schwierig.  Siehe
auch Johan Ekdahl:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=44588

GCC leidet zuweilen darunter, dass der AVR bei den GCC-Entwicklern
eine relativ untergeordnete Rolle spielt.  Insbesondere gibt es immer
noch keinen so weit etablierten Simulator, dass es den GCC-Leuten
möglich wäre, Verschlechterungen, die nur die AVR-Plattform betreffen,
im Rahmen automatisierter Tests bereits während der laufenden Entwick-
lung festzustellen.  Daher braucht es immer erst einmal den `round
trip' über die Endanwender (die das Ganze eben typischerweise auch erst
mit jedem neuen Release von WinAVR testen, da kaum einer von ihnen den
Compiler bereits zwischendurch mal selbst baut).

Eric Weddingtons erklärtes Ziel ist es, einen Simulator so zu
etablieren, dass das AVR-Target bei GCC aus der dritten (,,ferner
liefen'') in die zweite Kategorie wandert.  Damit würden kritische
Bugs bei der Codegenerierung für AVR zum Blocker für ein GCC-Release,
und schlechtere Optimierungen durch Compileränderungen zumindest
rechtzeitig das Augenmerk der Entwickler finden.

Ansonsten ist der GCC, gemessen an seiner Herkunft (Unix-Compiler,
der für 32-Bit-CPUs mit von-Neumann-Architektur konzipiert worden
ist) alles andere als schlecht für den AVR.  Von der Kompaktheit des
generierten Codes schneidet er zumindest bei größeren Projekten in
der Regel kurz hinter dem IAR auf Platz 2 ab, geschwindigkeitsmäßig
kann er (mit -O3) sogar einiges größeren aber deutlich schnelleren
Code generieren als IAR.  Das Handling des Sourcecodes für Zugriffe
auf den Flash-ROM und EEPROM ist auf Grund der von-Neumann-Orientierung
mit nur einem einzigen Adressraum umständlicher als bei anderen
Compilern, aber das kann man sich normalerweise schnell in ein paar
Makros kapseln.

Die übrigen Compiler (Imagecraft, Codevision) kenne ich selbst gar
nicht, ich sehe deren Stärken eher im Drumrum, also in Codegeneratoren
etc., was sie so noch mitbringen.  Dafür nehmen sie's zuweilen mit
dem C-Standard nicht ganz so genau (siehe Dinge wie PORTB.0, die der
Syntax von C zuwider sind und daher weder bei GCC noch bei IAR je zu
finden sein werden), und C99 scheinen sie sich allesamt noch gar nicht
auf die Fahnen geschrieben zu haben.

Jungs, bitte macht für Diskussionen zu diesem Artikel aber einen
separaten Thread auf!  Bezieht euch auf den Artikel über folgenden
Link: Beitrag "Re: Atmel ist unter "Profis" nicht gerade beliebt - Warum?"

von Hauke S. (hauke)


Lesenswert?

@walther
>Schau Dir erstmal mal an welche Features andere Assembler bieten und
>dann reden wir weiter. Atmel hat ja noch nicht einmal ein automatische
>Sprungweitenanpassung.
Was meinst du jetzt damit?
Benutzt du keine Label?
Nimmst du nur absolute Sprungadressen?
Mal was davon gehört?:
1
loop:
2
  ;macht irgenwas
3
  ...
4
  CPSE r0,r1
5
JMP loop
(Schleite wird so lange durchlaufen bis r0=r1 ist)

>Ein Beipsiel sind z.B. die Shift-/Rotataionsbefehle oder ein
>fehlender Bit-Test-Befehl
Wie bitte?
Wie wäre es mit:
1
BST r0,3
2
BRTS bit3_gesetzt
3
BST r0,5
4
BRTC bit5_nicht_gesetzt

Das einzige was ich mnchmal vermisse ist eine Rotation ohne Carry 
(welche es im DMG90 und Z80 gibt)

bis dann
Hauke

von Sebastian (Gast)


Lesenswert?

>Das einzige was ich mnchmal vermisse ist eine Rotation ohne Carry
???
Es gibt doch lsl und lsr. Die sind doch ohne Carry. Ok, sie beeinflussen 
das Carryflag, aber es wird immer 0 reingeschoben.
Oder hab ich dich jetzt falsch verstanden?

Sebastian

von Herbert vom Kaventsmann (Gast)


Lesenswert?

Er meint vermutlich eine 8-Bit-Rotation, bei der das rausgeschobene Bit 
sofort am anderen Ende wieder reingeschoben wird.

Bert

von Sebastian (Gast)


Lesenswert?

Achso. Ja, das müsste man sich wohl händisch basteln. Gebraucht hab ich 
das aber noch nie...

Zu der Sprungweitenanpassung:
Ich denke er meint, dass man z.B. immer jmp schreibt, der Assambler dann 
aber ein rjmp draus macht, wenn es geht und eben ein jmp wenn der Sprung 
zu groß ist. Wäre in der Tat nett.

Sebastian

von yalu (Gast)


Lesenswert?

Walther Z. schrieb:

> Dennoch sind die Befehle einfach nicht ergiebig. Ein Beipsiel sind
> z.B. die Shift-/Rotataionsbefehle oder ein fehlender Bit-Test-Befehl
> (als And-Verknüpfung) ...

Der Befehlssatz des AVR (RISC, 8-Bit) ist im Vergleich zu einem x86
(CISC, 16- bzw. 32-Bit) naturgemäß eingeschränkt, was Vor- und
Nachteile hat. Immerhin können die meisten typischen CISC-Befehle
durch 2 bis 3 AVR-Befehle nachgebildet werden. Insgesamt macht der
AVR-Befehlssatz auf mich einen wesentlich "runderen" Eindruck als
derjenige des x86, der eben doch ziemlich "gewachsen" aussieht.

> ... oder das Verhältniss zwischen And/Cbr Befehlen (verwirrend). Es
> gibt einfach zu viele unsinnige Befehle die nicht wirklich gebraucht
> werden und besser hätten eingesetzt werden können.

Wirklich überflüssige Befehle gibt es eigentlich nicht. Der von dir
kritisierte CBR ist kein eigener Befehl, sondern lediglich eine andere
Schreibweise für den ANDI-Befehl. Ob du ihn benutzt oder nicht, ist
dir überlassen. Auf jeden Fall belegt CBR weder in der ALU noch im
Befehlsdekoder Chip-Fläche. Von dieser Sorte "überflüssiger", aber
kostenloser Befehle gibt es noch ein paar mehr, z.B. CLR, LSL, ROL,
TST und SBR. Sie schaffen einfach etwas mehr Klarheit im Programmcode,
mehr nicht.

> Auch der C-Compiler nutzt nur einen kleine Codeauswahl aus dem
> gesamten Befehlscode-Raum.

Mir fallen auf Anhieb kaum Befehle ein, die der Compiler (ich kenne
allerdings nur den GCC) nicht benutzt. Darunter fallen allenfalls die
Half-Carry-Befehle, die ich aber auch in einem Assemblerprogramm
äußerst selten verwenden würde. Aber ansonsten nutzt der Compiler den
Befehlssatz ziemlich erschöpfend aus.

von Peter D. (peda)


Lesenswert?

Stefan May wrote:
> Bockmist und für ernsthafte Anwendungen nicht zu gebrauchen. Peter
> Dannegger darf auch gerne seine Meinung sagen, auch wenn ich die Antwort
> schon fast kenne. :-)


Also ich finde den AVR-GCC so gut, daß ich bisher keinen kommerziellen 
Compiler probiert habe.
An kommerziellen Compilern stört mich nicht der Preis, sondern die 
Nutzergängelung. Ich möchte den Compiler auf jedem Rechner laufen lassen 
können ohne Dongle umstecken zu müssen.

Beim AVR-GCC sollte man aber unbedingt zu jedem Projekt die 
Compilerversion aufheben (bei professionellen Compilern wohl auch).

Da inzwischen alle Pinversionen des AVR bis zu 8kB Flash haben (Ausnahme 
ATTiny2313) kann man auch ruhig mal suboptimalen Code schreiben (float, 
printf auf nem 8-Pinner).


Peter

von Andreas K. (a-k)


Lesenswert?

Ob CPSE wohl verwendet wird? Auch das "T" Flag nebst seinen Befehlen 
dürfte der Compiler standhaft ignorieren, es findet allerdings in der 
Library Verwendung.

Die meisten 8-Bit-Controller-Architekturen entstammen einer Zeit, in der 
man keinen C Compiler in deren Nähe liess, allenfalls Minimalcompiler 
wie Intels PLM. Und so sehen sie auch aus, optimiert auf 
Assembler-Programmierung und sie tun sich mehr oder weniger schwer mit 
Compilern. Nur wenige Architekturen dieser Abstammung kommen mit Daten 
auf dem Stack gut zurecht, statt dessen werden lokale Daten (auto) oft 
statisch angelegt, mit erheblichen Nebeneffekten. Und Verabeitung von 
Daten mit mehr als 8 Bit Breite ist bei Akkumulator-orientierten 
Architekturen auch nicht wirklich effizient.

AVR ist erkennbar für Programmierung mit Compilern konzipiert, wenn auch 
nicht ausschliesslich. Das gilt generell für alle RISCs, die ja aus der 
Erkenntnis heraus entstanden, dass man mit Compilern meist besser dran 
ist. Und man den Aufwand nicht in den Befehlsdekoder sondern in den 
Compiler stecken sollte.

Am anderen Ende der Skala stecken Architekturen wie beispielsweise 
M16c/84. Ein Traum für den Assembler-Programmierer - aber kein Compiler 
wird auch nur die Hälfte von dessen Komplexität wirklich produktiv 
nutzen.

von Peter D. (peda)


Lesenswert?

Michael König wrote:
> Was mich an den AVRs etwas stört ist die Tatsache, daß man die Fuse-Bits
> explizit setzen muß.

Ja, das ist nicht schön gelöst.
Bei den 8051 von Silabs ist das besser. Die haben garkeine Fusebits, 
sondern starten immer mit dem internen Takt und man kann dann ganze 
bequem per Software z.B. nen externen Quarz auswählen.


Man sollte beim AVR auch die Fusebits per SPM-Befehl setzen können.


Peter

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Sebastian wrote:

> Zu der Sprungweitenanpassung:
> Ich denke er meint, dass man z.B. immer jmp schreibt, der Assambler dann
> aber ein rjmp draus macht, wenn es geht und eben ein jmp wenn der Sprung
> zu groß ist. Wäre in der Tat nett.

Macht der GNU-Linker mit --relax (linker relaxations).

von Johannes M. (johnny-m)


Lesenswert?

yalu wrote:
> Von dieser Sorte "überflüssiger", aber
> kostenloser Befehle gibt es noch ein paar mehr, z.B. CLR, LSL, ROL,
> TST und SBR. Sie schaffen einfach etwas mehr Klarheit im Programmcode,
> mehr nicht.
"Ein paar" ist aber ne ganz schöne Untertreibung. Schätzungsweise 40% 
des Befehlssatzes sind solche Pseudo-Befehle, deren Opcode identisch ist 
mit dem anderer Instruktionen. Dazu zählen (neben den bereits genannten) 
z.B. die ganzen speziellen Branch-Befehle, die alle auf brbs und 
brbc beruhen, clr als alternative Schreibweise zu eor des 
betreffenden Registers mit sich selbst, sbr und cbr , sämtliche 
Befehle zum Setzen und Löschen eines bestimmten Flags im SREG, die alle 
auf bset bzw. bclr zurückzuführen sind, wobei das betreffende Bit 
eben im Befehl bereits drinsteckt usw...

von Michael Wilhelm (Gast)


Lesenswert?

>Von der Kompaktheit des generierten Codes schneidet er zumindest bei >größeren 
Projekten in der Regel kurz hinter dem IAR auf Platz 2 ab, >geschwindigkeitsmäßig 
kann er (mit -O3) sogar einiges größeren aber >deutlich schnelleren Code 
generieren als IAR.

Da müsste man sich aber auch die Optimierungen des IAR anschauen. Da 
kann man schon eine Menge schrauben. Wenn jemand einen 
Vergleichsquellcode hat, bin ich gerne bereit, diesen auf dem aktuellen 
IAR zu kompilieren.

Aber mal zurück zum Thema:

Da ich nur in C programmiere, ist mir der Assembler ziemlich egal. Das 
Ergebnis ist entscheidend. Bisher habe ich nur eine Schwäche 
festgestellt: wenn ich den Quellcode schützen möchte per Fusebits, ist 
automatisch auc das EEPROM lesegeschützt. Da ich das aber des öfteren 
benötige für z. B. Betrienszeit messen, Temperatur loggen, usw. bleibt 
das Programm auslesbar. Da sehe ich noch Verbesserungsbedarf.

MW

P.S. Das mit dem nur Leseport war ich glaube Port F des Mega 103. Die 
nachgeschobenen 64er und 128er hatten da mit gesetztem 
Kompatibilitätsbit einige Verwirrungen gestiftet.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Michael Wilhelm wrote:

> Da müsste man sich aber auch die Optimierungen des IAR anschauen.

Ich habe für den AVR keine nennenswerten Unterschiede im generierten
Code zwischen -z6 (Optimierung auf beste Größe) und -s6 (Optimierung
auf beste Geschwindigkeit) feststellen können.  Folglich war der
Code in beiden Fällen nicht nur nahezu gleich groß, sondern auch gleich
schnell.  Ich sehe diese beiden Optionen (zumindest von der Dokumen-
tation her) als einigermaßen vergleichbar mit GCC's -Os bzw. -O3, die
dort aber einen krassen Unterschied im erzeugten Code verursachen
(20...30 % größer durch inlining und loop unrolling, aber entsprechend
schneller).

Wirklich gemessen habe ich aber seinerzeit nur das Timing für das
Senden des acknowledgment in einer IEEE-802.15.4-Implementierung.
Das muss innerhalb von 192 µs erfolgen.  Am Ende habe ich aber
wirklich lieber den Quellcode optimiert (angefangen habe ich mit
ca. 700 µs Antwortzeit), sodass die Zeit dann sowohl mit IAR -s6/-z6
als auch mit GCC -Os eingehalten worden ist.

von Michael Wilhelm (Gast)


Lesenswert?

> -s6

Das ist nu auch schon ein bischen älter. Hoffentlich hattest du die 
Option --no_cross_call gesetzt. Ansonsten bremst es ehr bei Speed.

MW

von Fred S. (Gast)


Lesenswert?

Hallo,

noch einen Beitrag zur Meinungsbildung: Meine Erfahrungen mit dem 
Service bei Atmel sind 1A: Mehrere technische Fragen (seit Ende der 90er 
Jahre; es ging dabei sowohl um AVRs als auch um das AVR Studio) sind 
persönlich und kompetent von Experten bei Atmel (meist aus Norwegen; 
nicht von Marketing-Personal!) per e-mail beantwortet worden, obwohl ich 
immer dargestellt hatte, dass es sich bei meinen Projekten 
ausschließlich um Einzelentwicklungen handelt, also nicht um den Verkauf 
in großen Stückzahlen geht.

Gruß

Fred

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Michael Wilhelm wrote:

>> -s6

> Das ist nu auch schon ein bischen älter. Hoffentlich hattest du die
> Option --no_cross_call gesetzt.

Sicherlich nicht.  Die Beschreibung liest sich auch eher so, als sollte
man diese Option unbedingt ausschalten, wenn es auf Geschwindigkeit
ankommt.

Da aber IAR es nie vermocht hat, ihr Lizenzgeraffel für das Windows
in meiner VMware auf die Reihe zu bekommen, habe ich mittlerweile auch
leider keinen IAR mehr zur Hand, gegen den ich mal schnell vergleichen
könnte.  Das ist bei IAR wirklich ätzend, der ganze Lizenzhickhack.

von sous (Gast)


Lesenswert?

Die Behauptung "Atmel bei Profis unbeliebt" ist einfach vollkommener 
Quatsch!

von Patrick (Gast)


Lesenswert?

>Die Behauptung "Atmel bei Profis unbeliebt" ist einfach vollkommener
>Quatsch!
Genau!! Wir setzen fast ausschliesslich AVRs ein. Hauptsächlich den 
AT90CAN128.

von crazy horse (Gast)


Lesenswert?

Lizenzgerödel: da kann ich auch nur sagen - ich mach den Scheiss nicht 
mehr mit. Hatte dasselbe Gedrisse mit CodeVision, Lizenz hin- und her 
exportieren, rauf auf den Laptop, wieder runter auf den Schreibtisch-PC, 
dabei zwischendurch mal ganz abgekackt. Oder doch mal beim Kunden 
gewesen und vorher vergessen, die Lizenz draufzutun - super.
Pistole auf die Brust: freie Version oder Schluss mit CodeVision -> hat 
geklappt.
Deshalb kommt IAR für mich auch nicht in Frage, schau ich mir nicht 
einmal die Testversionen mehr an.
Mit anderen Werkzeugen halte ich es ebenso, ich habe nichts irgendwie 
geschütztes mehr in Gebrauch (ausser Windows, habe ich mit VM auch 
jedesmal Theater, tel. klappts aber immer).

von Tobi. S (Gast)


Lesenswert?

Das Atmel in der Inustrie unbeliebt ist, wiederlegt der extrem
starke Andrang am Atmel Stand auf der Embedded World.
Klar, die meisten Hobbyisten können das nicht wissen ...

von yalu (Gast)


Lesenswert?

Johannes M. schrieb:

> Dazu zählen (neben den bereits genannten) z.B. die ganzen speziellen
> Branch-Befehle, die alle auf brbs und brbc beruhen, clr als
> alternative Schreibweise zu eor des betreffenden Registers mit sich
> selbst, sbr und cbr , sämtliche Befehle zum Setzen und Löschen eines
> bestimmten Flags im SREG, die alle auf bset bzw. bclr zurückzuführen
> sind, wobei das betreffende Bit eben im Befehl bereits drinsteckt
> usw...

Die Branch- und die SREG-Befehle habe ich bei den Beispielen
absichtlich weggelassen, weil es nicht nur beim AVR üblich ist,
verwandten Befehle ähnliche Opcodes zu verpassen, die sich nur in den
paar Bits, die das jeweilige Flag adressieren, unterscheiden. Trotzdem
bekommt jeder Branch und jede Statusbitmanipulation ein eigenes
Mnemonic. Die Alternative, den Statusbitnamen als Befehlsargument zu
übergeben, sieht man auch stellenweise, aber deutlich seltener. Die
anderen von dir erwähnten Befehle habe ich oben schon genannt.

Aber wie gesagt, letztendlich stören diese zusätzlichen Befehle
überhaupt nicht, da sie nur dem Assembler bekannt sind und weder bei
der Chipherstellung noch im Betrieb Geld kosten. Wer sie nicht mag,
ignoriert sie einfach.

von Michael (Gast)


Lesenswert?

Meine persönliche Einschätzung ist, dass der Mikrokontroller-Markt groß 
genug ist für mehrere Halbleiterhrsteller mit verschiedenen 
Mikrokontrollerfamilien. Die Eierlegendewollmilchsau gibt es auch unter 
den Mikrokontrollern nicht. Von daher hat jeder Mikrokontroller irgendwo 
mit Sicherheit seine Berechtigung. Soll im Bezug auf den AVR heißen, es 
gibt mit Sicherheit Anwendungen, wo man ihn gut und gerne verwendet, es 
gibt aber auch Anwendungen, wo er aus verschiedenen Gründen nicht in 
Frage kommt.

Ansonsten orientiert man sich als Halbleiterhersteller natürlich stark 
an Großkunden und ihren Wünschen. Also da wird es auch bei Atmel welche 
geben, die die Mikrokontroller in richtig großen Stückzahlen verwenden.

Was mir immer ein bischen Bauchschmerzen macht, wenn ich an Atmel denke, 
ist deren Support in Kombination mit der Lieferbarkeit. Mir ist es schon 
mehrmals passiert, das ein Mikrokontroller monatelang nicht lieferbar 
war, so das man das Gefühl kriegt, die müssen in Taiwan erst noch die 
Fab bauen und gleichzeitig wird einfach nicht mit offenen Karten 
gespielt (morgen werden die Controller geliefert, morgen wirklich).

Das ist so meine persönliche Einschätzung.
Michael

von Carsten (Gast)


Lesenswert?

Ich denke nicht dass Atmel unbeliebter als andere Hersteller ist. Es ist 
eher so, dass im "Profi"-Bereich mehr Hersteller zur Auswahl stehen und 
somit der Marktanteil geringer ist. Es sind ja, wie man in diesem Forum 
öfters lesen kann, etliche Halbleiterhersteller oben in den 
Verkaufs-Rankings vertreten, aber im Hobby-Bereich eher unbekannt (da 
gab's doch mal den NEC-Thread). Als Bastler ist man doch auch auf ander 
Merkmale angewiesen (z.B. DIL-Package, bei einem Katalog-Distri 
bestellbar, etc.) - da kommt dann z.B. Infineon, Fujitsu, NEC etc. meist 
nicht in Frage.

von Michael L. (nemesisod)


Lesenswert?

Ich würde eher sagen das der Mensch, und somit auch die Ingenieure 
Gewohnheitstiere sind. Da viele Ingenieure schon der älteren Generation 
angehören sind diese nicht mehr so Experimentierfreudig, deshalb werden 
diese nicht einen neuen uC ausprobieren, solange sie mit dem aktuellen 
die Aufgabe auch erfüllen können. weil ein neuer uC heißt wieder anderer 
Compiler, stundenlanges datenblatt studieren anderer Programmierstil 
etc. .

Ich selbst arbeite an der Uni, und bei uns werden auch Atmels verwendet, 
aber meist aus dem Grund, weil die Hilfswissenschaftler "freie" Auswahl 
der Hardware haben. Da viele auch privat gute Erfahrungen mit Atmel uC 
gemacht haebn landet dann schon öfters mal ein socher im Schaltplan.

In der Industrie in der nicht im 5 Jahres wechsel die Mitarbeiter kommen 
und gehen ist es daher schwieriger neue uCs einzusetzen.

ciao

von Michael (Gast)


Lesenswert?

Naja, aber das Gewohnheitsargument tritt mit zunehmenden Stückzahlen 
immer weiter in den Hintergrund. Irgedwann zählen dann wirklich nur noch 
die besten sachlichen Argumente.

von Gast (Gast)


Lesenswert?

Hallo,

ich habe folgende die Erfahrung gemacht :

Da ATMEL die AVR´s von Anfang an ausschließlich nur als Flash-Typen 
anbietet , standen diese bei uns in der Firma quasi auf einer "schwarzen 
Liste". Weil gerade bei großen Stückzahlen in der Vergangenheit OTP´s 
bzw. Masken wesentlich günstiger waren. Doch in der Zwischenzeit gehen 
alle Hersteller von Masken bzw. OTP´s weg (z.B. bei Microchip sind z.B. 
Masken erheblich teurer als ein Flash µC). Weiterhin ist auch eine 
Online_programmierung der Flash in der laufenden Serie ein z.Z. 
unerwünschter Punkt. Und eine Vorabprogrammierung kostet halt auch 
nochmal Geld.

Für den Hobbybastler ist ein Flash-µC natürlich super, und da es die 
AVR´s an jeder Ecke in DIP´s zu kaufen gibt. Sind sie in diesem Segment 
sehr beliebt. Obwohl ich mir vorstellen kann, das für ATMEL die 
Hobby-Lobby nur ein Bonusgeschäft ist.

Fazit:
Der AVR ist nicht unbeliebt, seine Flash-Technologie war halt 1997 
seiner Zeit voraus und heute gibt´s hat gleichteure leistungsfähigere 
µC´s (s. ARM). Daher bleibt abzuwarten ob der "richtige" Schritt zum 
XMega auch von der Industrie angenommen wird. Die Konkurenz ist hat sehr 
groß.

von utah (Gast)


Lesenswert?

@ Michael Leske

Da jeder Ingenieurestunde mit > 50 EURO anzusetzen ist, hat ein 
Ingenieure schon aus rein wirtschaftlichen Gründen nicht die Muße, die 
man vielleicht noch an der Uni hat.

Außerdem gibt es meistens für bereits verwendete Controller schon gut 
getestete Software im Erstellungswert von >> 100.000 EURO.

Da ein Ingenieure in einer Firma arbeitet um Gewinne zu erzielen und er 
zudem gegen Wettbewerber antritt ist jeder Systemwechsel sehr gut zu 
Überlegen.

Der Aufwand, sich in einen neuen Controller, bzw. einer neuen 
Controller-Familie einzuarbeiten ist überigens für jemanden, der es 
vielleicht schon zehnmal gemacht hat nicht besonders groß. Die 
Einarbeitungszeiten betragen nur einen Bruchteil der Zeiten, die 
Studenden üblicher Weise benötigen. Da er sich aber nicht nur mit 
Controllern beschäftigt, sind selbst diese Zeiten oft nicht vorhanden. 
Viele Ingenieure wenden nicht selten 10 bis 20% ihrer Arbeitszeit auf, 
um sich in neue Techniken und Produkte einzuarbeiten.

Deine Vorstellung der geringen "Experimentierfreudig" von älteren 
Ingenieuren entspringt wohl eher der Märchenwelt.

MfG
utah

von Walther Z. (chilipower)


Lesenswert?

> Das sind immer die Killerargumente, die von den Assembler-Profis
> aufgeführt werden. Was ist aber mit anpassbarem, portablen Code? Das
> Stichwort lautet Wartbarkeit.
Wieviele Prozessorfamilien setzt du denn für ein und dieselbe 
Boardsteuerung ein?
In der Praxis sieht es so aus, dass ich mich für ein Projekt auf ein 
Modell fixiere und gut ist. (Im übrigen kann man auch Assemblercode 
komfortabel warten)

> Deine Argumente sind überholt, sie stammen
> aus den 60ern und 70ern. Für Mikrocontroller lasse ich geradeso die 90er
> noch gelten.
Klingt wie ein Kind, dem man den Lutscher weggenommen hat. Nur weil ich 
Atmel nicht mag, muss das ja im Gegenzug nicht für dich gelten.

>Zur Geschwindigkeit wurde weiter oben auch schonmal was gesagt. Für
>Platz gilt dasselbe. Die heutigen CPU-Architekturen schreien geradezu
>nach Compilern. Das was Du mühsam in Assembler aus dem Controller
>rausquetscht, macht der Compiler mit Links. Und alle Atmels, selbst die
>kleinsten Tiny haben mittlerweile RAM.

Ein Compiler ist mir hinsichtlich Entwicklungszeit (und auch nur da) 
erst dann wirklich überlegen, wenn es sich bei der CPU um eine 
Pipelined-Architektur handelt. Denn hier spielt die Anordnung der 
Befehle bei der Ausführungsgeschwindigekeit eine massgebliche Rolle. 
Dies ist beim AVR aber nicht der Fall. Für die Geschwindigkeit kann ich 
auch ein kleines Beispiel geben.

Für die Stackbearbeitung muss der Compiler regelmässig auf den 
Stackpointer zugreifen. Dazu muss er:

-das flagregister sichern
-die interrupts sperren
-den stackpointer lesen (falls er ihn nicht irgendwo schon in den regs
 speichert und damit platz belegt)
-ihn manipulieren
-zurückschreiben
-flags zurückladen

Ich kann den Compiler hier ganz leicht an die Wand spielen. Indem ich 
Funktionsaufrufe nur durch Register bearbeite und damit keiner 
restriktiven Prozesspolitik durch statischen Registerzuweisungen 
unterliege. (Es ist auch so in Gnu-C nicht möglich, mal eben 16 Register 
oder mehr freizuräumen, um sie für eine schnelle Registerdivison zu 
verwenden. Ein echtes Manko.)

In der Hinsicht ist es auch interessant, warum man dem AVR keinen 
eigenen Befehl für die Stackbearbeitung spendiert hat. Stattdessen gibt 
es "Adiw" was keiner braucht.

Ein grosses Problem ist auch restriktiver Befehlscode. Z.B folgendes:

ldi   r20, 0
ldi   r21, 0
ldi   rzero, 0
subi  r20, 1
sbc   r21, rzero

vs.

ldi   r20, $FF
ldi   r21, 0
ldi   rzero, 0
subi  r20, -1
add   r21, rzero

Das sind echte Stolpersteine. Ein weiteres Problem, sind Makroaufrufe 
die sich nicht rückwärts analysieren lassen. Bedingt verschachtelte 
Makroaufrufe sind damit z.B. nicht möglich um solche Probleme elegant 
aufzulösen.

Der Teufel steckt einfach im Detail. Nur eine Handvoll Menschen ist 
prinzipiell bemüht ständig die Grenzen zu testen. Kann die Hard- und 
Software "ihren" Anforderungen genügen, so wird sich auch echte Liebe 
entwickeln und wenn nicht, dann eben nicht. Ist alles eine 
Anspruchsfrage. Mein Ding ist der AVR eben nicht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Walther Z. wrote:

> Klingt wie ein Kind, dem man den Lutscher weggenommen hat.

Stimmt, so klingst du. ;-)

> Ein Compiler ist mir hinsichtlich Entwicklungszeit (und auch nur da)
> erst dann wirklich überlegen, wenn es sich bei der CPU um eine
> Pipelined-Architektur handelt.

OK, dann nimm einen Entwickler, der C genauso gut versteht wie du
Assembler (nur, damit deine offenbar nicht vorhandenen C-Fertigkeiten
aus der Rechnung rausbleiben).

Ich würde auf Grund eigener Erfahrungen (die ich mit C und Assembler
habe) die Wartungskosten (also nicht nur die initiale Erstellung) auf
ca. 1:10 ansetzen.  Klar kann man Assembler auch wartbar schreiben,
aber dann steckt man halt (noch) mehr Aufwand initial rein.

> Ich kann den Compiler hier ganz leicht an die Wand spielen. Indem
> ich Funktionsaufrufe nur durch Register bearbeite...

Das macht der Compiler auch.  Den Stack nimmt er nur, wenn wirklich
Platz gebraucht wird.  Wenn du im Assembler Platz brauchst, musst du
auch irgendwo RAM benutzen.  Es ist dann relativ egal, ob du ihn
irgendwo statisch im RAM unterbringst (kannste ja in einer Hochsprache
auch haben) oder auf dem Stack.  Bei letzterem können sich halt die
Variablen mehrerer Funktionen überlagen.  Solange man genügend RAM
hat, isses egal.

Klar kannst du bei guter Assemblerprogrammierung immer besser werden
als ein Compiler (der arbeitet ja nur seine Strickmuster ab), aber du
musst dafür einen höheren Aufwand treiben.

> In der Hinsicht ist es auch interessant, warum man dem AVR keinen
> eigenen Befehl für die Stackbearbeitung spendiert hat.

Weil die Erfinder des AVR nicht mit Compilern vertraut waren.  Sie
haben sich daher bei diesen Entscheidungen von den Compilerbauern bei
IAR assistieren lassen (das ist irgendwo ja dokumentiert), und da IAR
anders als Unix/GCC mit zwei separaten Stacks für den Return- und den
Parameterstack fährt, brauchen sie die SP-Zugriffe nicht.  Für den
Framezugriff via Y-Register wiederum ist im Prozessor alles drin.
(Der Nachteil dieses Modells ist aber, dass man nur einen von beiden
Stacks dynamisch anlegen kann, den anderen muss man statisch
vorbelegen.)

> Das sind echte Stolpersteine. Ein weiteres Problem, sind Makroaufrufe
> die sich nicht rückwärts analysieren lassen.

Was hat das mit dem Prozessor zu tun?

Dass der Assembler nicht wirklich für produktive Tätigkeit geeignet
ist, wird kaum einer bestreiten...  Aber den musst du ja auch nicht
unbedingt benutzen.

von Andreas K. (a-k)


Lesenswert?

Walther Z. wrote:

> Für die Stackbearbeitung muss der Compiler regelmässig auf den
> Stackpointer zugreifen.

Muss er bei GCC hauptsächlich in diesen Fällen:
- Funktionsaufruf mit vielen Parameter, oder variabler Anzahl
- Adresse von Daten auf dem Stack wird benötigt.
- Grosse Anzahl lokaler Daten, mehr als in Register passt.

Ansonsten lässt GCC den Stackpointer weitgehend in Frieden und der 
bizarre Zirkus mit dessen Update entfällt. Stören tut dann nur noch die 
push/pop-Orgie, wo z.B. eine Version mit Bitmap, RISC oder nicht, 
sinnvoller gewesen wäre (abbrechbar wg. Latenzzeit).

> In der Hinsicht ist es auch interessant, warum man dem AVR keinen
> eigenen Befehl für die Stackbearbeitung spendiert hat.

Habe ich mich auch schon gefragt.

Ich bin mit anderen AVR Compilern nicht vertraut. Aber ich könnte mir 
vorstellen, dass sich dort auch ein Speichermodell mit 2 Stacks finden 
lässt. Einem Hardware-Stack für Return-Adressen und einem Software-Stack 
für lokale Daten. Damit ist dieses Problem vom Tisch.

Direkt ärgerlich finde ich, dass Atmel das anscheinend nichtmal mit den 
XMegas repariert hat. Müsste sich eigentlich langsam rumgesprochen 
haben. Oder hat IAR da ein Druckmittel gegenüber Atmel?

> Stattdessen gibt es "Adiw" was keiner braucht.

Das ist bei ebendiesem Software-Stack sehr nützlich.

> Ein grosses Problem ist auch restriktiver Befehlscode.

Hab nicht verstanden wo das Problem ist.

von Christian R. (supachris)


Lesenswert?

Ich weiß gar nicht, was diese Diskussionen immer bringen sollen? Es gibt 
ja nicht DEN Microcontroller, der alle Anwendungen erschlägt. Wir 
setzen hauptsächlich den MSP430 ein, weil es bei den wireless 
Anwendungen auf jedes µA Strom ankommt, und der gleich 16 Bit Messdaten 
durch den HW-Multiplizierer jagen kann.
Für wired Sachen kommt der TMS320F2812 zum Einsatz, weil wir da 
mittlerweile unsere Messsysteme seit Jahren mit bauen.

von chorus (Gast)


Lesenswert?

Ich finde die Diskussion hoch interessant. Es ist doch mal schön, wenn 
von Profis so richtig auf die Details eingeganngen wird.
Auf der Embedded habe ich ein wenig mit einem Vertreter von NEC 
gegenüber vom Atmel Stand diskutiert. Meine Meinung war, dass sich die 
AVR's deshalb so verbreiten, weil es die OpennSource Tools und die 
ganzen billigen Entwicklungssysteme gibt. Die Studenten von heute sind 
die Entwickler von morgen.
Seine Antwort war, dass NEC bei den Profis ( Automobilindustrie ) einen 
sehr guten Ruf geniesßt. Vor allem was Temperaturbeständigkeit, 
Lebensdauer und Flash-Haltbarkeit angeht, sei NEC wesentlich 
zuverlässiger als Atmel.
Das ist für mich schon eine interessante Frage: zwar mögen die AVR's 
günstig,  unter den Bastlern weit verbreitet und gute OpenSource Tools 
vorhanden sein, wenn aber im realen Einsatz bei z.B. 80°C das Flash nach 
5 Jahren gelöscht ist, kann das schon für manche Anwendungen ein echter 
Ausschlussgrund sein.

Meine früheren Kollegen verwendeten vorwiegen PIC für die ganz kleinen 
Dinge und 80C166 für die etwas größeren.
Deren Erfahrung mit Atmel: Abkündigungen und Lieferverzug.
Trotzdem wird aber hin und wieder ein kleineres Projekt mit den AVR's 
gestartet. Vielleicht ist die Zuverlässigkeit von Atmel in dieser 
Hinsicht inzwischen besser.

von Michael König (Gast)


Lesenswert?

@Walther Z.

> Ein Compiler ist mir hinsichtlich Entwicklungszeit (und auch nur da)
> erst dann wirklich überlegen, wenn es sich bei der CPU um eine
> Pipelined-Architektur handelt.

Dann bist du mit dem Assembler sehr vertraut und hast im Gegenzug 
eventuell mit der jeweiligen Hochsprache nicht allzu viel Erfahrung.

Als einer unserer Hardware-Designer unbedingt AVR statt PIC verwenden 
wollte, hat er angeboten ebenfalls die Firmware zu machen, weil er im 
Gegensatz zu uns mit der Architektur vorher schon öfter gearbeitet 
hatte. Eigentlich war das ganze eine relativ primitive Angelegenheit, 
aber nach einigen Monaten (ich glaube ich hatte das Gegenstück in 
unserer Firmware etwa 3 Monate davor programmiert) war das ganze Projekt 
leider über den mit dem Kunden vereinbarten Termin und ich sollte das 
ganze dann irgendwie retten.
Den Assembler-Quellcode konnte man leider vergessen, da ich mich darin 
nicht schnell genug einarbeiten konnte, die Programmierung etwas 
eigenartig war und die Firmware auch nicht wirklich das machte, was sie 
eigentlich machen sollte. Also kam der Code in die Tonne.
Ich hatte einen Tag mich über das WinAVR-Tutorial und das Datenblatt des 
Controllers (ATtiny2313) mit der ganzen Sache vertraut zu machen. Am 
nächsten Tag habe ich in maximal zwei Stunden in C eine Firmware 
geschrieben, die bis auf ganz kleine Details auch auf anhieb 
funktionierte. Am meisten Zeit wurde dann eigentlich mit einer wackligen 
Resetschaltung vergeudet und daß die Optokoppler unserer alten 
I/O-Testschaltung für die vom Kunden geforderte Frequenz einfach zu 
langsam waren. Ich glaube ich habe noch einen dritten Tag dafür 
verwendet, das ganze dann noch auf Herz und Nieren zu testen, aber das 
war es dann auch schon.
Der größte Witz ist, daß der Designer wochenlang an der Firmware auf 
einem ATmega8 gearbeitet hatte und dann sehr viel ändern mußte, damit 
das ganze in das kleinere Flash des ATtiny2313 überhaupt reinpaßte. Mein 
C-Code dagegen belegt vielleicht 30% des Flashes.

> Indem ich Funktionsaufrufe nur durch Register bearbeite

Du scheinst dich nicht wirklich mit der Codeerzeugung von Compilern für 
RISC-Architekturen auszukennen, oder? Diejenigen, die ich bisher gesehen 
habe, übergeben üblicherweise die ersten vier Parametern in Registern. 
Erst wenn dies nicht möglich ist oder mehr Paramter übergeben werden 
müssen, wird der Stack eingesetzt.
Du solltest hier von deinen x86-Compilern nicht auf RISC-Compiler 
schließen, wobei erstere die Parameter auch teilweise über Register 
übergeben, aber das ist meines Wissen (zumindes früher) sehr stark 
Compiler-abhängig (gewesen). Bei RISC-Architekturen gib es aber 
üblicherweise Standards (beispielsweise APCS = ARM Procedure Call 
Standard), die beschreiben wie die Parameterübergabe ablaufen muß, und 
dann haben sie die Compiler auch daran zu halten.

Ich bin kein Assembler-Verächter (dazu wühle ich mich zu gerne durch die 
ISAs unterschiedlichster Prozessoren), aber es ist definitiv so, daß man 
über einen guten Algorithmus normalerweise wesentlich mehr 
Geschwindigkeit herausholt, als über handoptimierten Assemblercode mit 
einem ungünstigeren Algorithmus. Und ich bin der Ansicht, daß man in 
Hochsprache den Überblick über den Algorithmus weniger leicht verliert 
und ihn notfalls auch schneller abändern kann, falls er doch nicht die 
gewünschte Performanz bieten sollte.

> In der Hinsicht ist es auch interessant, warum man dem AVR
> keinen eigenen Befehl für die Stackbearbeitung spendiert hat.

Wahrscheinlich, weil so etwas in gewissem Maße dem RISC-Prinzip 
widerspricht. Andere Embedded-Architekturen haben es aus Gründen der 
Effizienz dennoch gemacht.

Eine Sache, die mich beim AVR etwas stört, ist der nicht ganz 
orthogonale Instruktionssatz.
Abgesehen davon verstehe ich einfach nicht, warum man selbst bei so 
einer modernen Architektur Shifts nur in 1-Bit Schritten durchführen 
kann. Der ARM2 hatte meines Wissens bereits einen Barrel-Shifter, mit 
dem man in einem einzigen Taktzyklus beliebige Shifts durchführen 
konnte, und der Prozessor hatte nur um die 8000 Transistoren, also 
sollte so ein Barrel-Shifter auch nicht so viel Chipfläche verbrauchen.

von utah (Gast)


Lesenswert?

> Ich bin kein Assembler-Verächter (dazu wühle ich mich zu gerne durch die
> ISAs unterschiedlichster Prozessoren), aber es ist definitiv so, daß man
> über einen guten Algorithmus normalerweise wesentlich mehr
> Geschwindigkeit herausholt, als über handoptimierten Assemblercode mit
> einem ungünstigeren Algorithmus. Und ich bin der Ansicht, daß man in
> Hochsprache den Überblick über den Algorithmus weniger leicht verliert
> und ihn notfalls auch schneller abändern kann, falls er doch nicht die
> gewünschte Performanz bieten sollte.

Das gilt aber nur bei unstrukturiertem Assemblercode. Behält man bei der 
Assemblerprogrammierung den Durchblick, dann ist das Ergebnis i.A. doch 
besser als bei compiliertem Code.

Ich habe in der Vergangenheit compilierten Code auf Assemblerbasis 
optimiert. Das Ergebnis war immer ein deutlich kompakterer Code 
(mindestens 10% kleiner, aber auch 60% kleiner kam vor) bei absolut 
identischer Funktion.

Zur Zeit programmiere ich viele zeitkritische Prozesse. Da verbietet 
sich ein Compiler fast automatisch. Auch habe ich bisher in jedem 
verwendeten Compiler zum Teil sehr zeitaufwendig Fehler gefunden. Über 
alles betrachtet bringt eine rein in Assembler geschriebene Software oft 
das bessere Ergebnis, wenn der verwendete Mikroconroller bis an seine 
Grenzen genutzt wird.

MfG
utah

von Peter D. (peda)


Lesenswert?

Michael König wrote:

> Ich bin kein Assembler-Verächter (dazu wühle ich mich zu gerne durch die
> ISAs unterschiedlichster Prozessoren), aber es ist definitiv so, daß man
> über einen guten Algorithmus normalerweise wesentlich mehr
> Geschwindigkeit herausholt, als über handoptimierten Assemblercode mit
> einem ungünstigeren Algorithmus. Und ich bin der Ansicht, daß man in
> Hochsprache den Überblick über den Algorithmus weniger leicht verliert
> und ihn notfalls auch schneller abändern kann, falls er doch nicht die
> gewünschte Performanz bieten sollte.


Das sollten sich mal viele Programmierer auf A0 vergrößern und übers 
Bett hängen!

Man kriegt oft das kalten Grausen, wie wenig auf den Algorithmuis 
geachtet wird.
Wenn manche Leute ihre CPU zu 20% übertakten, ist das einfach nur 
lächerlich.
Ein durchdachter Algorithmus kann oft 1000% mehr CPU-Leistung bringen.


Ich habs z.B. schon gesehen, wie jemand ne LED-Anzeige gemultiplext hat, 
indem in jedem Timerinterupt die 16Bit-Zahl per SW-Divison zerlegt, mit 
9 Vergleichen nach 7-Segment gewandelt und ausgegeben wurde. Und dann 
sich gewundert, warum die LEDs so dunkel sind, weil 50% CPU-Zeit für 
diesen Unsinn draufgeht.
Bei LCDs wird auch gerne versucht, jede 100µs einen anderen Wert 
auszugeben, bei >50ms Reaktionszeit absolut unsinnig, vom 
Aufnahmevermögen des Menschen ganz abgesehen.
Die Beispiele ließen sich endlos fortsetzen.


Es tut doch nicht weh, mal zu überlegen, was braucht viel Zeit, muß es 
wirklich so oft ausgeführt werden, kann ich nicht frühere Ergebnisse 
zwischenspeichern usw.


Peter

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Peter Dannegger wrote:

> Es tut doch nicht weh, mal zu überlegen, was braucht viel Zeit, muß es
> wirklich so oft ausgeführt werden, kann ich nicht frühere Ergebnisse
> zwischenspeichern usw.

Läuft auf den alten Spruch hinaus: “Never start optimizing before you
have profiled it.”

von Unbekannter (Gast)


Lesenswert?

Hihi, ich finde es schon lustig, wie manche Bastler hier wirklich der 
Ansicht sind, Atmel nehme Rücksicht auf sie und/oder produziert extra 
für sie DIL-Gehäuse...

Haha...

von Jens P. (Gast)


Lesenswert?

Die Produzieren DIL nur für MICH, und zwar nur um mich von den PICs 
wegzubewegen. Da das bisher nicht gefruchtet hat, geben sie eben so 
langsam auf mit DIP.

von Christian J. (Gast)


Lesenswert?

Hallo,

bei unseren Kunden ist es so, dass ATMEL nicht verwendet wird, weil er 
den Ruf eines Bastelprozessors hat und es wegen der erwähnten 
Abkündigungen Ärger gab. In Sicherheitsprodukten muss mindestens 10 
Jahre lang eine Type lieferbar sein, da ein Prozessorwechsel immer eine 
sehr teure Nachqualifizierung nach sich zieht und das garantiert zb 
Microchip, den 16C55 gibts immer noch und das seit 1995. Die meisten 
meiner Kunden setzen 8051, PIC, Motorola, NEC V850x oder ARM7 ein.

Assembler spielt fast keine Rolle mehr, seit es zertifizierte Compiler 
gibt, zudem meine Produkte immer hochpreisig sind wo es nicht drauf 
ankommt, ob der Chip 1-2€ mehr kostet oder nicht. Man kommt einfach 
schnelller zum Ergebnis und der Code ist pflegbar.

von Thomas A. (Gast)


Lesenswert?

> bei unseren Kunden ist es so, dass ATMEL nicht verwendet wird, weil er
> den Ruf eines Bastelprozessors

Und da haben wir "ihn" wieder, den Grund weshalb ich diesen Thread 
eröffnet habe...

Thomas

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

>bei unseren Kunden ist es so, dass ATMEL nicht verwendet wird, weil er
>den Ruf eines Bastelprozessors hat

Das ist schlichtweg Blödsinn und völlig subjektives Gedröhn. Vergleiche 
mal die Errata Sheets von Microchip PIC und ATMEL AVR, dann sag nochmal 
´was über Bastelprozessor.

von Jürgen (Gast)


Lesenswert?

>.... da ein Prozessorwechsel immer eine
> sehr teure Nachqualifizierung nach sich zieht und das garantiert zb
> Microchip, den 16C55 gibts immer noch und das seit 1995.

könnte es nich auch sein,
das die kunden einfach zu blöd sind sich auf einen anderen prozessor
umzuorientieren, oder zu faul sind ??

von Punktrichter (Gast)


Lesenswert?

@Jürgen
Tut mir leid, nur 0 Punkte für Dich.

von Bensch (Gast)


Lesenswert?

Er meinte natürlich 0 FEHLERpunkte...

Solche "Kunden" kenn ich auch, fliegen allerdings hier wegen Arroganz 
ziemlich schnell raus.

von STK500-Besitzer (Gast)


Lesenswert?

>könnte es nich auch sein, das die kunden einfach zu blöd sind sich auf einen 
>anderen prozessor umzuorientieren, oder zu faul sind ??

Es gitb Bereiche, in denen nur bestimmte (qualifizierte) Bauelemente 
verwendet werden dürfen.
Raumfahrt, Militär, Sicherheitseinrichtungen etc...
Da müssen die Geräte Typprüfungen bestehen, um zugelassen zu werden.
Wenn man schon einen bestimmten Controller in seinen Geräten verbaut 
hat, dann ist diese Qualifizierung (vermutlich) einfacher.

von Joerg W. (joergwolfram)


Lesenswert?

Mit dem reinen Mikrocontroller ist es ja auch nicht immer getan.
Beispiel Auto, nur um irgendwo eine kleine Lampe leuchte zu lassen 
braucht man schon etwas mehr:
-Controller
-Spannungsregler
-Bus-Interface (z.B. LIN)
-Leistungstreiber
So etwas gibt es z.B. von Freescale (MM908) auf Basis eines 68HC08 in 
einem Package. Warum sollte nun der Lampenmodulhersteller auf 
irgendetwas angeblich "zeitgemäßeres" umsteigen, wenn es letztendlich 
mit Mehrkosten verbunden ist? Auch wenn der Code in C geschrieben wird, 
heißt das noch lange nicht dass er schnell mal auf eine andere Plattform 
übertragen werden kann.

Gruß Jörg

von micro1 (Gast)


Lesenswert?

Ich selber verdiene auch mein Geld mit µC Programmierung.
Wir setzten Atmel in Medizingeräte ein.
Ebenso aber auch Infineon XC166er Reihe und PIC
Vorteil Atmel:
1 : Interner Flash schnell zum Debuggen und zum Entwickeln sowie
zum Überspielen des neuen Programms
2 : Code ist leicht portierbar von ATMega8 - AT90CAN
wenn in C geschrieben
3: Die Atmels haben viele sachen On Board
(ADC, CAN, LIN, USART, IIC, PSC usw....)
 Nachteil :
1. Die meisten Dreviate haben keinen Adress und Datenbus
2. Für Anwendungen mit LCD Controller meist zu wenig Speicher.
3. Das Interrupt handling ist nicht so robust wie jetzt z.B
XC
4. Mit gcc kein validierten Compiler

Ich denke für Anwendungen als Motorsteuerungen DC/DC Converter
oder so sind diese µCs super, wenn nicht viel Speicher benötigt wird.

Weiterhin denke ich auch das der Unterschied PIC oder Atmel nur eine
frage der Gewohnheit ist.
Ich persönlich finde aber bei Atmel das Flashen am besten, im gegensatz 
zu allen anderen Hersteller.

von Sven P. (Gast)


Lesenswert?

hellboy wrote:
> tja es gab sogar mal eine untersuchung dazu ... effizienz c vs asm ....
> c hat gewonnen und das nicht umsonst .... die optimierungen die ein
> compiler macht kann das menschliche hirn kaum leisten und dann noch in
> so nem spagetti code

Was das angeht... ich programmier hobbymäßig auch saugerne in ASM. Ganz 
einfach: ich hab Zeit genug, durch den Einstieg mit ASM weiß ich jetzt 
haargenau, was im Prozessor vor sich geht (wird ja nix von irgendwelchen 
Headern versteckt oder so). Fürs Hobby macht das dann richtig Spaß, 
finde ich. Hat für mich aber auch -lach- ästhetische Gründe. 1<<BLABLA 
sieht irgendwie hässlich aus...

Letztens hab ich mit nem Quadraturencoder rumgeschlagen und da einen 
C-Schnipsel aus diesem Forum mal compilieren lassen 
(compilieren=C-nach-ASM-wandeln). Erstaunlicherweise stimmte der vom GCC 
erzeugte ASM-Code fast haargenau mit meinem Handbetrieb-ASM überein; 
lediglich einen Sprung weniger hab ich geschafft^^

von Rüdiger K. (sleipnir)


Lesenswert?

Zur Frage Assembler/C möchte ich noch ein paar Punkte in den Topf 
werfen:
Der Assembler hat da seine Daseinsberechtigung wo es um extrem 
zeitkritische Sachen geht, also das beühmte Taktezählen. Ein weiterer 
Punkt ist das sich Compiler naturgemäß schwer damit tun Spezialbefehle 
zu verwenden. Dann wird eine Bitmanipulation, die sonst einen Befehl und 
damit einen Takt gekostet hätte, in zahlreiche Registermanipulationen 
umgewandelt.

von Christian R. (supachris)


Lesenswert?

Was ich persönlich noch besser an den MSP430 im Vergleich zu den AVRs 
finde, sind die preiswerten Debugger, die alle MSP430 unterstützen. Der 
superschnelle USB Debugger von Olimex kostet gerade mal 60€ und 
unterstützt alle MSP430, egal ob JTAG oder Spy-Bi-Wire. Bei Atmel 
bezahlt man da gleich mal 280€ für das MK II. Die AVRs an sich sind zwar 
meist billiger als die MSP430, aber da wir nur Kleinserien und 
Prototypen machen, fällt der Controllerpreis nicht ins Gewicht. Außerdem 
kann man jeden MSP430 vollkommen ohne externe Taktquelle programmieren, 
falsch gesetzte Fuses gibts da nicht :)

von chorus (Gast)


Lesenswert?

Das kommt darauf an. Wenn Du die kleine Prozessoren ohne Jtag 
verwendest, kannst Du Debug-Wire benutzen. Und dazu braucht man nur 
einen AVR-Dragon für ca. 60€.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

AVRs lassen sich generell ohne externe Taktquelle programmieren: über 
ISP und internen Taktgenerator.

von holger (Gast)


Lesenswert?

>Außerdem kann man jeden MSP430 vollkommen ohne externe Taktquelle
>programmieren, falsch gesetzte Fuses gibts da nicht :)

Das gilt in ähnlicher Form auch für die PIC16, PIC18.
Man kann sie alle ohne Taktquelle programmieren.
Probleme mit falschen Fuses gibt es nur wenn man einen
reinen LVP-Prommer verwendet. Dann kann man sich ausperren
wenn das LVP-Bit falsch programmiert wird. Falls der
PIC dieses Bit hat.

von Gottfried (Gast)


Lesenswert?

Arbeite seit 1998 mit den AVR.
gestartet hatten wir mit dem ATmega103 und dem IAR Compiler.
Seit 1999 sind die ersten Geräte in Betrieb und hunderte Regelungen 
laufen seit diesr Zeit ohne Unterbrechung durch!
Der IAR-Compiler optimiert den Code dermaßen Perfekt, das er nur die 
benötigten Register auf den Stack legt.
Da der ATmega103 abgekündigt wurde, musste das Projekt auf den ATmega128 
angepasst werden, dies dauerte nur ein paar Tage.
Der Bootloader ist sehr flexibel und kann sehr gut Angepasst werden. Wie 
viele PC werden heute noch mit Seriellen Schnittstellen gebaut? Hab 
einen Bootloader gemacht, wo der PC oder die CPU vom Strom getrennt 
werden kann ohne das die CPU von außen neu programmiert werden muss und 
die Möglichkeit einen Bootloader mit verschlüsselter Datenübertragung zu 
erstellen ist auch gegeben um ein Kopieren der Hardware auszuschließen.

Derzeit lauft ein Projekt mit einem Controler von Microchip. Es sind 
keine Informationen über die Fehler (ERATA) auf dem Chip zu Erkennen 
sondern müssen Softwaremäßig ausgelesen werden, bei REV C ist sogar 
hardwaremäßig was zu ändern damit das Ding überhaupt richtig 
funktioniert. Das Handbuch mit fast 100 Seiten hat ein 
Inhaltsverzeichnis mit ca. 10 Einträgen und es ist mühsam das 
Wesentliche herauszufinden (am Anfang das Senden, in der Mitte das 
Empfangen und später die Konfiguration und danach die Initialisierung 
...).

von Gottfried S. (gottfried)


Lesenswert?

Michael Wilhelm wrote:
> Da ich nur in C programmiere, ist mir der Assembler ziemlich egal. Das
> Ergebnis ist entscheidend. Bisher habe ich nur eine Schwäche
> festgestellt: wenn ich den Quellcode schützen möchte per Fusebits, ist
> automatisch auc das EEPROM lesegeschützt. Da ich das aber des öfteren
> benötige für z. B. Betrienszeit messen, Temperatur loggen, usw. bleibt
> das Programm auslesbar. Da sehe ich noch Verbesserungsbedarf.

Einfach die Fuse "EESAVE" mitprogrammieren, möchtest du das EEPROM 
auslesen so löscht du einfach das Device mit dem Chip-Erase und liest 
das EEPROM aus.
Anschließend programmierst du den Flashspeicher neu und setzt wieder die 
Security Bits.

Oder man schreibt ein Programm um den Inhalt des EEPROMs per 
Schnittstelle zu übertragen (UART, ...)

von Peter (Gast)


Lesenswert?

AVRs sind okay, aber die AT91SAM7 sind der letzte Schrott. Ich hab' mich 
damit einen Monat rumgeärgert und bin dann auf LPC 23xx umgestiegen.

von Steffen (Gast)


Lesenswert?

he he, ich habe noch gar nicht gewusst, das der Benz ein Bastelauto ist. 
Da ist z.B. der ATmega169 drinnen.

von Steffen (Gast)


Lesenswert?

@Peter :
>bin dann auf LPC 23xx umgestiegen.

mein BEILEID .

von Gottfried S. (gottfried)


Lesenswert?

Christian J. wrote:
> bei unseren Kunden ist es so, dass ATMEL nicht verwendet wird, weil er
> den Ruf eines Bastelprozessors hat und es wegen der erwähnten
> Abkündigungen Ärger gab. In Sicherheitsprodukten muss mindestens 10
> Jahre lang eine Type lieferbar sein, da ein Prozessorwechsel immer eine
> sehr teure Nachqualifizierung nach sich zieht und das garantiert zb
> Microchip, den 16C55 gibts immer noch und das seit 1995. Die meisten
> meiner Kunden setzen 8051, PIC, Motorola, NEC V850x oder ARM7 ein.

Im Jahr 1995 wusstest du schon, das es den 16C55 auch noch im Jahr 2005 
geben wird?

von yalu (Gast)


Lesenswert?

Steffen schrieb:
> he he, ich habe noch gar nicht gewusst, das der Benz ein Bastelauto
> ist.

A- und B-Klasse schon ein Bisschen, aber der AVR sitzt sicher in der
S-Klasse ;-)

> Da ist z.B. der ATmega169 drinnen.

Und was macht der Mega in dem Benz?

von Peter (Gast)


Lesenswert?

>@Peter :
>>bin dann auf LPC 23xx umgestiegen.
>mein BEILEID .
Hat alles Vor- und Nachteile. Beim AT91SAM7 war einiges einfacher, 
funktionierte aber nicht richtig. Beim LPC ist teilweise mehr Fummelei 
nötig, aber alles funzt exakt so, wie's im User Manual steht.

von Winfried (Gast)


Lesenswert?

In Sachen Bastelprozessor: Ich würd ja gerne mal die Zahlen sehen, wie 
viele AVR's an Bastler verkauft werden und wieviele von Firmen in 
professionellen Produkten. Ich vermute mal, der Bastelbereich wird 
deutlich unter 5 % liegen, womit dann die Aussage "Bastelprozessor" 
ziemlich unsinnig ist.

Meine Bedenken bei AVR gehen in die Richtung, was auch schon gesagt 
wurde: Keine weiteren Hersteller, man ist also sehr von Atmel abhängig. 
Und Abkündigungen bei langlebigen Produkten. In vielen Fällen kann man 
den Einsatz aber trotzdem wagen, man kann halt nicht alles haben...

von Benedikt K. (benedikt)


Lesenswert?

Winfried wrote:

> Meine Bedenken bei AVR gehen in die Richtung, was auch schon gesagt
> wurde: Keine weiteren Hersteller, man ist also sehr von Atmel abhängig.

Dasselbe gilt genauso für den PIC, Z80 und viele andere. Nur 8051, ARMs 
usw. sind von vielen Herstellern lieferbar. Wenn irgendein Projekt eine 
einmale Sache ist (die durchaus hohe Stückzahlen haben kann !), dann 
spricht eigentlich nichts gehen AVRs.

> Und Abkündigungen bei langlebigen Produkten. In vielen Fällen kann man
> den Einsatz aber trotzdem wagen, man kann halt nicht alles haben...

Außerdem hat Atmel bisher noch keinen AVR ohne Nachfolgetyp abgekündigt. 
Die compatibility mode Fuses z.B. beim mega128 ist nicht grundlos 
eingebaut.

von C. H. (_ch_)


Lesenswert?

>> Meine Bedenken bei AVR gehen in die Richtung, was auch schon gesagt
>> wurde: Keine weiteren Hersteller, man ist also sehr von Atmel abhängig.

>Dasselbe gilt genauso für den PIC...
nicht ganz. Microchip macht doch damit Werbung, dass KEINE Controller 
abgekündigt werden und somit für lange Zeit (=immer?) lieferbar sind.
Aufgrund dieser Tatsache wurde uns bei einigen Projekten wohl oder übel 
ein PIC aufgezwängt.

von Benedikt K. (benedikt)


Lesenswert?

C. H. wrote:
>>> Meine Bedenken bei AVR gehen in die Richtung, was auch schon gesagt
>>> wurde: Keine weiteren Hersteller, man ist also sehr von Atmel abhängig.
>
>>Dasselbe gilt genauso für den PIC...
> nicht ganz. Microchip macht doch damit Werbung, dass KEINE Controller
> abgekündigt werden und somit für lange Zeit (=immer?) lieferbar sind.

Aber garantieren kann das niemand. Wenn Microchip irgendwann doch mal 
merkt, dass die vielen unterschiedlichen Controller ein Verlustgeschäft 
sind, dann kann man die Firmenpolitik ganz schnell ändern.

von C. H. (_ch_)


Lesenswert?

Benedikt K. wrote:
> Aber garantieren kann das niemand.
Dessen bin ich mir auch bewusst - aber der Kunde ist König und wenn mein 
Kunde sagt, dass er gerne einen Microchip hätte, weil diese auch in 10 
Jahren noch lieferbar sind, dann bekommt er auch einen Microchip.

von Unbekannter (Gast)


Lesenswert?

> Ich vermute mal, der Bastelbereich wird deutlich unter 5 % liegen

Oh man... Manche hier haben echt Wahnvorstellungen... Genau so gut 
hättest Du sagen können, der Bastelbereich ist unter 100%.

Man, man, man...

von Hugo Walter (Gast)


Lesenswert?

Sehr interressante Diskussion. Leider kann ich mich nicht den meisten 
Vorrednern anschließen.

Bei uns in der Firma (Lichttechnik) werden seit längerem AVRs verbaut, 
und das in Stückzahlen > 100000. Wir verwenden beide 
Programmiermethoden, ASM und C. Dabei ist meine Persönliche Meinung, 
dass der C code von unserem IAR Compiler sehr effektiv umgesetzt wird, 
und die ASM schreibweise keine nennenswerten Vorteile mehr bietet.

von Sven P. (Gast)


Lesenswert?

Was die PICs angeht... Abkündigung ist wohl da weniger das Problem. Nur 
was nützt es, wenn ich einen uralten PIC-Typ verbaue, den Microchip seit 
Jahrzehnten mitschleppt, und der dann Jahr für Jahr immer teurer wird 
weil kein Mensch den mehr neu verbauen möchte? Dann setz ich mich lieber 
hin und portier den Code auf nen neueres Modell, was dann bei großen 
Stückzahlen sicherlich von Vorteil ist.

Wenn ich wirklich vorhab, mal zehn Jahre lang ein Produkt mit einem 
Controller X auszurüsten, dann unterhalt ich mich doch erstmal mit dem 
Hersteller und handle nen Vertrag aus?!

von 6645 (Gast)


Lesenswert?

Sven,
so ist die Realitaet meist nicht. Zum Einen weisst du nicht, ob das 
Produkt ueberhaupt solange laeuft, Vielleicht geht's ja nie in Serie. 
Zum anderen bedingen "Vertrag mit Hersteller aushandeln" Stueckzahlen, 
die bei einem Prototypen noch nicht absehbar sind. Und trotzdem ist beim 
Prototypen die Wahl schon gefallen.

von yalu (Gast)


Lesenswert?

Noch ein paar Worte zum Thema "Bastelprozessor":

der Begriff kann auf zwei Arten definiert werden:

1. Ein Prozessor der nur zum Basteln geeignet ist, aber nicht für
   Serienprodukte und den industriellen Einsatz.

2. Ein Prozessor, der auch zum Basteln geeignet ist, bspw. auf Grund
   der Verfügbatkeit für Privatpersonen, DIL-Gehäuse usw.

Definition 1 (wie sie von den AVR-Kritikern benutzt wird) kann kaum
die richtige sein, da es m.W. kein einziges Halbleiterbauteil gibt,
das speziell für den Hobbybereich hergestellt wird, schon gar nicht zu
dem Spottpreis, den die AVRs mittlerweile noch kosten.

Nach Definition 2 ist ein Bastelprozessor sogar etwas Positives. Die
Eigenschaften, die ein Bauteil für den Bastler interessant machen,
stellen ja in den allerwenigsten Fällen Nachteile für den
industriellen Anwender dar.

Ich frage mich allerdings, wer außer den Bastlern in nennenswertem
Umfang DIL-Gehäuse benutzt, so dass es sich für Atmel und Microchip
lohnt, ihre Controller in diesen Gehäusen anzubieten.

Bei OTP-Typen, deren Flash-Nachfolgern und nicht in-system-prgrammier-
baren Controllern ist ein Grund vielleicht die Sockelbarkeit (wobei es
dafür auch PLCC gibt). Alle größeren AVRs waren aber von Anfang an
in-system- und wiederprogrammierbar, so dass sie normalerweise nicht
gesockelt werden.

Sind speziell die DIL-AVRs (und natürlich auch -PICs), z.B. der
ATmega32 in seinem Monstergehäuse, vielleicht nicht doch
Bastelprozessoren nach Definition 1? Es ist durchaus plausibel, dass
man über Hobbyisten und Studenten eine "Hintertür" in die Industrie
sucht und sicher auch findet. Verdient wird mit den DIL-Varianten
vermutlich kaum etwas. Wenn sie den Verkauf der SMD-Varianten aber nur
um wenige Prozent steigern, haben sie sich für den Hersteller schon
gelohnt.

Gerade bei komplexen Bauteilen wie Mikrocontrollern ist es für den
Chip-Hersteller besonders wichtig, sie dem Schaltungsentwickler
schmackhaft zu machen, da - anders als bspw. bei einem neuen OpAmp -
der Entwickler bei einem Umstieg deutlich mehr Zeit investieren muss.
Die Zeit hat er in seinem Beruf oft nicht, während seiner Ausbildung
oder am Wochenende schon eher.

Da die AVRs unter Bastlern erst seit einigen Jahren so richtig hipp
und viele dieser Bastler derzeit noch studieren, kann ich mir gut
vorstellen, dass der Marktanteil der AVRs in den nächsten Jahren
deutlich steigen wird. Die Zuverlässigkeit und Verfügbarkeit der
Bauteile muss natürlich von Atmel sichergestellt werden, da
diesbezügliche Probleme sehr, sehr lange in den Köpfen der Kunden
feststecken, wie man an einigen Beiträgen in diesem Thread sieht.

von 6645 (Gast)


Lesenswert?

Die DIL Prozessoren werden vor allem an Orten verbaut wo ein SMD 
Bstueckungsautomat viel zu teuer ist, resp die Infrastruktur nicht
hinkommt. Es gibt Orte, da krieg ich jemanden zum manuell
Bestuecken fuer 2..3 Euro pro Tag. Da kann man viel Leiterplatten
bestuecken bis sich eine Maschine rechnet.

von Thilo M. (Gast)


Lesenswert?

>dann unterhalt ich mich doch erstmal mit dem Hersteller und handle nen
>Vertrag aus?!

Ich kenne das z.B. von Audi.
Wenn die eine Produktionsstraße umrüsten, dann verbauen die z.B. Siemens 
S7 nur dann, wenn der Hersteller (Siemens) 10 Jahre Verfügbarkeit der 
Bauteile garantiert. Dazu muss aber schon die richtige Lobby dahinter 
stehen, bei einer 'kleinen Klitsche' wird der Hersteller nur müde 
lächeln.

von Peter D. (peda)


Lesenswert?

Nur weil hier jemand nur SMD einsetzt, muß er nicht denken, daß alle 
anderen auch keine DILs verwenden.

Gerade bei MCs ist es oftmals einfacher, einem Kunden den Chip mit dem 
Update zu schicken, anstatt nen speziellen Programmieradapter.

Eine DIL-Fassung ist auch deutlich billiger als eine PLCC-Fassung und 
der DIP-IC läßt sich ohne Spezialwerkzeug wechseln.
Man muß immer davon ausgehen, daß der Kunde kein Bastler ist.
Bzw. der Servicemechaniker vor Ort freut sich auch über jedes Problem 
weniger, das er hat. Da kann schon das Suchen einer passenden 
230V-Steckdose für das Notebook zum Updaten per ISP ein Problem werden.
Wir haben einige Platinen, wo fast alles SMD ist, nur der MC ist ein 
gesockelter DIP.


Peter

von Bensch (Gast)


Lesenswert?

> Gerade bei MCs ist es oftmals einfacher, einem Kunden den Chip mit dem
Update zu schicken, anstatt nen speziellen Programmieradapter.

> Man muß immer davon ausgehen, daß der Kunde kein Bastler ist.

Da widersprichst du dir aber selbst.

Wir haben jedenfalls die Erfahrung gemacht, dass ein Wechsel vom Kunden 
nur Schrott produziert, der Service muss dann wirklich raus. Umbebogene 
oder raushängende Beinchen, falsch rum eingesteckte Speicher- alles 
schon gehabt. Die Anlage steht dann erstmal für ein Paar Tage.

Dann schickt man ihm besser einen Programmieradapter mit aufgespieltem 
Programm. Den steckt er nur ein, drückt aufs Knöppschen und ferdich...

von Gottfried S. (gottfried)


Lesenswert?

Mann muss bei der Entwicklung sehr viel Berücksichtigen.
Beispielsweise bei PIC
Man überlegt bei Umfangreichen und langwierigen Projekten im Voraus 
welcher Prozessor am geeignetsten ist. Wird Beispielsweise ein Prozessor 
gewählt der 512kB Flash hat. Während der Entwicklung wird festgestellt, 
das mit einem 256kB Flash auch noch reichen würde oder ein größerer 
gebraucht wird. Wenn dann zwar ein Vergleichstyp verfügbar ist aber die 
Ports anders angeordnet sind, so muss die Hardware umgekrempelt werden 
(Platinenlayout, ...). Bei Atmel kann man von ATmega128 auf ATmega64 
oder ATmega256 umsteigen ohne die Hardware umzukrempeln und nur einige 
Softwareänderungen anbringen.

Wie oben schon gesagt wurde kommt es auch darauf an, wofür man den 
benötigt. Würde ein man einen sehr guten ADC mit 12-bit oder 14-bit 
Auflösung benötigen mit geringerer Stromaufnahme im Betrieb so würde 
sich ein MSP430 vielleicht besser lohnen...

Und obige Aussage ist Falsch, das bei 80°C die Daten nur 5 Jahre im 
Flashspeicher erhalten bleiben.
Data retention: 20 years at 85°C / 100 years at 25°C
Und wer kann garantieren, das es innerhalb von 20 Jahren kein Update 
(Neuschreiben des Flashspeichers) gibt und somit den Datenerhalt um 
weitere 20 bis 100 Jahre verlängert?
Seht euch doch mal die Spezifikationen bei SD-Karten oder USB Sticks an 
wenn ihr welche findet. Die trauen sich nicht mal Angaben darüber zu 
machen.
Dies Garantiert auch nicht das der µP bei einem Blitzschlag noch Lebt 
oder nach einer statischen Entladung noch funktioniert.

von Gottfried S. (gottfried)


Lesenswert?

Bensch wrote:
> Wir haben jedenfalls die Erfahrung gemacht, dass ein Wechsel vom Kunden
> nur Schrott produziert, der Service muss dann wirklich raus. Umbebogene
> oder raushängende Beinchen, falsch rum eingesteckte Speicher- alles
> schon gehabt. Die Anlage steht dann erstmal für ein Paar Tage.

Und du schickst den Kunden einen Programmieradapter, er öffnet das 
Gehäuse und drückt den Stecker vom Programmieradapter rein, geht er ein 
wenig schwer so muss man fester drücken ... :) Viel Spass mit kaputten 
Geräten und kaputten Programmieradaptern.

Der andere Vorteil von dem Bootloader ist, das der Bootloader mittels 
Verschlüsselung programmiert werden kann und so das Kopieren der 
Hardware und das laden der Software verhindert werden kann. Oder würdet 
ihr das Begrüßen viel Energie in eine Software zu stecken und später 
steht drauf "made in ..."?
Siehe auch AES / DES Bootloader

von Bensch (Gast)


Lesenswert?

@  Gottfried S.

Bootlader oder nicht, das war hier nicht die Frage. Es ging um das 
Umstecken von DIL-ICs vom Kunden.

Ob ich jetzt mit ISP oder Bootlader programmiere, ich muss irgendwas an 
die Platine anstecken- die hat keinen seriellen oder Ethernet-Anschluss. 
Ich könnt ja auch einen Anschluss nach draussen führen- aber der kostet. 
Und einen 10pol. Pfostenstecker mit Verdrehsicherung falsch zu stecken, 
ist wohl "etwas" schwieriger als ein DIL-IC, oder?

Aber klar, manche schaffen auch das....

von Thomas (kosmos)


Lesenswert?

Man kann ja auch 9polige RS232 Stecker und Buchsen nehmen. Wenns dann 
vom Kunden immer noch verkehrt angeschlossen wird, sollte man sich mit 
Ihm zusammensetzung und eine Schulung durchführen.

von Jadeclaw D. (jadeclaw)


Lesenswert?

Hugo Walter wrote:
> Bei uns in der Firma (Lichttechnik) werden seit längerem AVRs verbaut,
> und das in Stückzahlen > 100000. Wir verwenden beide
> Programmiermethoden, ASM und C. Dabei ist meine Persönliche Meinung,
> dass der C code von unserem IAR Compiler sehr effektiv umgesetzt wird,
> und die ASM schreibweise keine nennenswerten Vorteile mehr bietet.
Kann ich zustimmen, was der GCC abliefert, ist so schlecht nicht.

Ich schrieb weiter oben:
> Und in die kleinen Controller (<= 4kB) kommt auch nichts anderes
> rein. Der Defaultcode, der bei C grundsätzlich mit eingebunden wird,
> ist mir für die kleinen Controller zu groß.
Eine Auffassung, die wohl dem Umstand zuzuschreiben ist, daß ich in 
meiner Unerfahrenheit und aus Bequemlichkeit bei ersten Versuchen 
wahllos Zeug aus den mitgelieferten Libs eingebunden habe. Das frißt 
natürlich Speicher. Also gerade nochmal was einfaches (LED-Blinker) mit 
einem ATTiny13 probiert und nur das absolut notwendigste eingebunden. 
Ergebnis: 80 Bytes will der GCC immer haben, das Blinkprogramm sind dann 
nochmal 30 Bytes. Da kann man sich nicht beklagen. Schaue ich mir das 
generierte Ergebnis an, von Hand kann man das auch kaum besser:
1
// Testdatei
2
// CPU = ATTiny13
3
#include <avr/io.h>
4
#include <util/delay.h>
5
6
#define LEDBIT 4
7
8
main (void)
9
{
10
  DDRB = 0x10;
11
  PORTB = 0xFF;
12
  for (;;)
13
  { 
14
    _delay_ms(200);
15
    PORTB |= (1 << LEDBIT);    /* setzt Bit 4 an PortB auf 1 */
16
    _delay_ms(200);
17
    PORTB &= ~(1 << LEDBIT);   /* loescht Bit 4 an PortB */
18
  }
19
  return (0);
20
}

Und das wird daraus:
1
0000004a <main>:
2
3
#define LEDBIT 4
4
5
main (void)
6
{
7
  4a:  80 e1         ldi  r24, 0x10  ; 16
8
  4c:  87 bb         out  0x17, r24  ; 23
9
10
    DDRB = 0x10;
11
  PORTB = 0xFF;
12
  4e:  8f ef         ldi  r24, 0xFF  ; 255
13
  50:  88 bb         out  0x18, r24  ; 24
14
  52:  e0 e6         ldi  r30, 0x60  ; 96
15
  54:  fa ee         ldi  r31, 0xEA  ; 234
16
 */
17
void
18
_delay_loop_2(uint16_t __count)
19
{
20
  __asm__ volatile (
21
  56:  8e 2f         mov  r24, r30
22
  58:  9f 2f         mov  r25, r31
23
  5a:  01 97         sbiw  r24, 0x01  ; 1
24
  5c:  f1 f7         brne  .-4        ; 0x5a <main+0x10>
25
    for (;;)
26
    { 
27
    _delay_ms(200);
28
    PORTB |= (1 << LEDBIT);    /* setzt Bit 4 an PortB auf 1 */
29
  5e:  c4 9a         sbi  0x18, 4  ; 24
30
 */
31
void
32
_delay_loop_2(uint16_t __count)
33
{
34
  __asm__ volatile (
35
  60:  8e 2f         mov  r24, r30
36
  62:  9f 2f         mov  r25, r31
37
  64:  01 97         sbiw  r24, 0x01  ; 1
38
  66:  f1 f7         brne  .-4        ; 0x64 <main+0x1a>
39
    _delay_ms(200);
40
    PORTB &= ~(1 << LEDBIT);   /* loescht Bit 4 an PortB */
41
  68:  c4 98         cbi  0x18, 4  ; 24
42
  6a:  f5 cf         rjmp  .-22       ; 0x56 <main+0xc>
43
44
0000006c <_exit>:
45
  6c:  ff cf         rjmp  .-2        ; 0x6c <_exit>

Alles unter 004A ist das Minimum, was der GCC immer haben will,
die Interrupt-Tabelle und eine Speicherkopier- und Löschroutine

Wird wohl Zeit, daß ich mich doch mal intensiver mit dem GCC 
beschäftige.

Gruß
Jadeclaw.

PS: Ein Blinker geht natürlich auch wesentlich kürzer mit Timer im 
CTC-Mode, aber ich wollte Compileroutput sehen.

von Gottfried S. (gottfried)


Lesenswert?

Genau, da hatten wir schon die tollsten Erlebnisse mit Steckverbindungen 
wo man meint den kann man gar nicht falsch anstecken, aber einige Wenige 
schaffen sogar das.

Ist kein Anschluss nach draußen Verfügbar, so ist die DIL Variante 
bestimmt die beste Lösung. Die Sockel für PLCC sind wirklich sehr teuer, 
geschweige denn die BGA Sockel.

von yalu (Gast)


Lesenswert?

Thomas O. schrieb:
> Man kann ja auch 9polige RS232 Stecker und Buchsen nehmen.

Nur so zum Thema "geschickte" Anwender:

In die 9-polige Sub-D-Buchse wird der Anwender alles hineinstecken,
nur nicht das, was reingehört :).

Die neueren Schnittstellen wie USB, Firewire usw. haben nicht umsonst
jeweils ihre eigene Steckergeometrie.

von Jadeclaw D. (jadeclaw)


Lesenswert?

Bensch wrote:
> @  Gottfried S.
>
> Bootlader oder nicht, das war hier nicht die Frage. Es ging um das
> Umstecken von DIL-ICs vom Kunden.
Nunja, eine Methode, die sich eher nicht empfiehlt. Zumindest nicht bei 
technisch völlig Unbegabten.

> Ob ich jetzt mit ISP oder Bootlader programmiere, ich muss irgendwas an
> die Platine anstecken- die hat keinen seriellen oder Ethernet-Anschluss.
> Ich könnt ja auch einen Anschluss nach draussen führen- aber der kostet.
> Und einen 10pol. Pfostenstecker mit Verdrehsicherung falsch zu stecken,
> ist wohl "etwas" schwieriger als ein DIL-IC, oder?
>
> Aber klar, manche schaffen auch das....
Aber sicher. Ein Blick in die Gallerien von http://www.dau-alarm.de/ 
zeigt überdeutlich, wie einfallsreich manche Leute sein können.

Wenn die zu erwartende Klientel nicht völlig neben der Spur ist, wäre 
ein SD-Card-Slot wohl das Sinnvollste, die Karten sind billig, die Slots 
ebenfalls und am Gerätegehäuse braucht es nur einen Schlitz an passender 
Stelle. Den Rest erledigt der Bootloader im Controller. Und schafft es 
der Kunde tatsächlich, die Karte falschrum einzustecken, geht nichts 
kaputt, da die Kontakte auf der Plastikrückseite der Karte landen.

Gruß
Jadeclaw.

von Sven P. (Gast)


Lesenswert?

6645 wrote:
> Sven,
> so ist die Realitaet meist nicht.

Nene, ist mir schon klar. Ich dachte mir halt, angenommen ich verbau 
einen AVR im Prototyp. Dann isser ja noch aktuell -- ich verbau ja nix 
Abgekündigtes. Und das ATMEL kurzfristig pleite macht, will ich auch mal 
nicht annehmen (ok, schon gewagter). Bis mein Dingchen dann vielleicht 
mal in Serie geht, und bis dann absehbar wird, ob sichs lohnt, bis dahin 
kann man doch davon ausgehen, dass noch genug Chips auf dem Markt 
liegen, oder? Ich meine, es gibt doch etliche Bauteile (von der Transe 
angefangen) die schon ewig abgekündigt wurden und trotzdem noch locker 
verfügbar sind.
Und wenn sichs dann lohnt, dann kann ich mich immer noch vertraglich an 
den Hersteller wenden.

Ich neige zu Gedankenexperimenten^^ tschuldigung, bin ja auch nur 
Hobbyist...

von Bensch (Gast)


Lesenswert?

> @  Gottfried S.
>
> Bootlader oder nicht, das war hier nicht die Frage. Es ging um das
> Umstecken von DIL-ICs vom Kunden.

> Nunja, eine Methode, die sich eher nicht empfiehlt. Zumindest nicht bei
> technisch völlig Unbegabten.

Genau was ich sage.....

> Wenn die zu erwartende Klientel nicht völlig neben der Spur ist, wäre
ein SD-Card-Slot wohl das Sinnvollste,

Hab ich auch schon dran gedacht, aber einen ISP-Stecker haben wir eh, 
das drängt sich geradezu auf, den auch zu nutzen. Bei unseren neuen 
grossen Boards mit eZ80 werden wir aber definitiv SD-Card oder USB zum 
Programmupdate nutzen, die Card kann man ja in einen USB-Adapter 
stecken.

Für die kleinen Boards mit AVR schwebt mir ein kleiner billiger 
Programmer mit fertigem Update (ISP oder Bootloader) in einem seriellen 
Data-EEPROM vor, denn man einfach zum Kunden schickt und den er nach 
Gebrauch zurückschickt. Bisher war noch kein Bedarf an Updates beim 
Kunden.

Speicherbausteine oder sonstiges werden wir definitiv nicht mehr 
wechseln als Update. Das ist Technik von vorgestern...

von Hardfreak (Gast)


Lesenswert?

>Die Sockel für PLCC sind wirklich sehr teuer,

PLCC != (T)QFP



Eine Quelle für einen einzelnen TQFP44 Sockel unter 30 Euro würde mich 
auch mal interessieren.

von Jadeclaw D. (jadeclaw)


Lesenswert?

Hardfreak wrote:
>>Die Sockel für PLCC sind wirklich sehr teuer,
>
> PLCC != (T)QFP
>
Ein PLCC-Sockel ist für ein kundenwechselbares Teil noch ungeeigneter. 
Raus bekommt man da Bauteil aus dem Sockel nur mit einem speziellen 
Ausziehwerkzeug und wenn man nicht sehr gut aufpaßt, kann es sehr leicht 
passieren, daß das neue Bauteil beim Eindrücken im Sockel verkantet. 
Dann viel Spaß beim Herauspopeln.

> Eine Quelle für einen einzelnen TQFP44 Sockel unter 30 Euro
> würde mich auch mal interessieren.
Mich auch.


Gruß
Jadeclaw.

von chorus (Gast)


Lesenswert?

>Und obige Aussage ist Falsch, das bei 80°C die Daten nur 5 Jahre im
>Flashspeicher erhalten bleiben.
>Data retention: 20 years at 85°C / 100 years at 25°C

Das war ja keine Aussage, sondern eine Art Gedächtnisprotokoll von einer 
Diskussion mit einem Produktmanager einer Konkurrenzfirma ( NEC ) zu 
Atmel.

Natürlich weiss ich auch, dass man auf das Geschwätz der Produktmanager 
nicht allzu viel gebem darf.
Worauf ich allerdings hinaus wollte: Hier in diesem Thread werden über 
die Vorzüge der Programmierung in Assembler oder C diskutiert, oder wie 
gut dieser Code vom Compiler umgesetzt wird.

Ein Mikrocontroller ist aber auch ein physikalischer Gegenstand. Er kann 
noch so schön zu programmieren sein, wenn er aus physikalischen Gründen 
einen Ausfall hat, sei es Temperatur, EMV oder sonst irgend etwas, sind 
die Vorteile einer solchen Architektur schnell hinüber.

Und genau hier würde mich die Erfahrung der Leute interessieren: Wie 
zuverlässig sind die AVR's ?

von Jadeclaw D. (jadeclaw)


Lesenswert?

chorus wrote:
> Ein Mikrocontroller ist aber auch ein physikalischer Gegenstand. Er kann
> noch so schön zu programmieren sein, wenn er aus physikalischen Gründen
> einen Ausfall hat, sei es Temperatur, EMV oder sonst irgend etwas, sind
> die Vorteile einer solchen Architektur schnell hinüber.
>
> Und genau hier würde mich die Erfahrung der Leute interessieren: Wie
> zuverlässig sind die AVR's ?

Genau das würde mich auch interessieren.
Gestorben ist mir jedenfalls noch keiner, was den Datenerhalt im Flash 
anbelangt, das  zu beurteilen, dafür sind meine Controller noch zu neu.
Was aber möglich ist, zeigt ein Selbstbaugerät mit einem D8748, das Ding 
läuft seit 15 Jahren ohne Probleme. Sowas erwarte ich auch von modernen 
Controllern.

Gruß
Jadeclaw.

von Spess53 (Gast)


Lesenswert?

HI

Atmel hat seine Tests unter 'Reliability Qualification Report' für die 
AVRs veröffentlicht. Zu finden unter 'AVR® 8-Bit RISC -> Other 
Documents'.

MfG Spess

von Peter D. (peda)


Lesenswert?

chorus wrote:

> Und genau hier würde mich die Erfahrung der Leute interessieren: Wie
> zuverlässig sind die AVR's ?

Also die classic-AVRs haben es bei mir nicht ins Produkt geschafft, die 
sind mir schon in der Entwicklung verreckt, z.B. EEPROM-Vergeßlichkeit 
(AT90S2313), Flash-Vergeßlichkeit (ATtiny22), Hängenbleiben (AT90S1200).
Da hat sich Atmel bestimmt nicht mit Ruhm bekleckert.

Ich hab dann erst wieder mit den ATtiny26 und ATmega8 nen neuen Versuch 
gestartet, weil die endlich ein funktionierendes Reset haben (BOD 
enabled).
ATmega168, ATtiny25, Attiny261, ATtiny84 sind noch hinzugekommen.
So und mit denen haben ich keinerlei Probleme.

Die ATtiny nehme ich gerne, weil ich die in C programmieren kann, um 
frühere TTL-Gräber (Ablaufsteuerungen) zu ersetzen.


Peter

von Thilo M. (Gast)


Lesenswert?

Wir haben diverse meg8535L in Pferdeställen seit 2004 am laufen, bisher 
nicht eine Reklamation. Die klimatischen Bedingungen 
(Temperaturschwankungen, Luftfeuchte, agressive Luft ..) konnten noch 
keinem was anhaben.
In Sachen EMV hatte ich mit einen tiny2313 das Problem, dass er neben 
einer Platine mit starker Störstrahlung saß, dort wurde der 
Tastereingang (interner Pullup) 'überfahren' und sprach ständig an. Ein 
externer Pullup (4k7) half.

Ich denke, je weniger Strom die Teile benötigen desto anfälliger werden 
sie für äußere Einflüsse.

von Peter D. (peda)


Lesenswert?

Thilo M. wrote:

> In Sachen EMV hatte ich mit einen tiny2313 das Problem, dass er neben
> einer Platine mit starker Störstrahlung saß, dort wurde der
> Tastereingang (interner Pullup) 'überfahren' und sprach ständig an. Ein
> externer Pullup (4k7) half.

Laß mich raten, Du hast nen externen Interrupt zum Tasten Abfragen 
genommen.
Sowas wird natürlich zu recht bestraft.


Peter

von Hauke R. (lafkaschar) Benutzerseite


Lesenswert?

Das liegt aber nicht an den AVRs sondern trifft auf alle Controller zu.
Flach ausgedrückt: je niederohmiger ein Eingang ist desdo mehr Energie 
muss die Störstrahlung haben um Pegelverändernde Spannungen 
einzustreuen.

von Gottfried S. (gottfried)


Lesenswert?

chorus wrote:
> Ein Mikrocontroller ist aber auch ein physikalischer Gegenstand. Er kann
> noch so schön zu programmieren sein, wenn er aus physikalischen Gründen
> einen Ausfall hat, sei es Temperatur, EMV oder sonst irgend etwas, sind
> die Vorteile einer solchen Architektur schnell hinüber.
>
> Und genau hier würde mich die Erfahrung der Leute interessieren: Wie
> zuverlässig sind die AVR's ?

Es sind 4 Regelgeräte in unserem Haus mit sehr guter Beschaltung die 
schon seit 1999 ständig am Stromnetz hängen und durchgehend bis heute 
laufen. Die Regelung wurde auch von einer Prüfstelle gegen EMV Geprüft.
http://www.tuev.at/start/browse/Webseiten/TUV%20Austria%20Holding/Dienstleistungen/Nachrichten-%20Informationstechnik%20und%20EMV/EMV%20RL%2089_3_36_EWG%20
Die Regelungen sind seit dieser Zeit im Dauereinsatz und haben weder 
einen Absturz, Reset oder sonstige Fehlsteuerungen oder Ausfälle. Hinzu 
kommt, das nur einige ausgetauscht wurden, wo Flüssigkeiten oder 
mechanische Beschädigungen aufzuweisen waren.

Ausfälle beim EEPROM haben wir nicht feststellen können. Einziges auf 
das zu Achten ist, ist das nicht ins EEPROM geschrieben wird wenn die 
Spannung unter einen bestimmten Pegel sinkt, wenn man zu oft beschreibt 
und die 100000 überschreitet, oder bei den älteren Modellen die EEPROM 
Stelle 0.

von Thilo M. (Gast)


Lesenswert?

>Du hast nen externen Interrupt zum Tasten Abfragen

Nee, war'n normaler Portpin, per Polling abgefragt. ;)

von Peter D. (peda)


Lesenswert?

Thilo M. wrote:
> Nee, war'n normaler Portpin, per Polling abgefragt. ;)

Aber dann nicht im Timerinterrupt mit 4-fach Abtastung:

Beitrag "Tasten entprellen - Bulletproof"


Peter

von Peter D. (peda)


Lesenswert?

Gottfried S. wrote:

> Ausfälle beim EEPROM haben wir nicht feststellen können.

Welcher AVR?
BOD enabled oder externer Reset-IC?


Peter

von Thilo M. (Gast)


Lesenswert?

@ Peter:
Lass' gut sein, in diesem Fall hätte keine Entprellung geholfen, da die 
Nachbarplatine (3cm Abstand) konstant mit 1MHz 'reingepfiffen hat.
War 'ne schnelle Notlösung, das ganze Gerät ist mittlerweile entsorgt. 
;)

von Gottfried S. (gottfried)


Lesenswert?

Peter Dannegger wrote:
> Gottfried S. wrote:
>
>> Ausfälle beim EEPROM haben wir nicht feststellen können.
>
> Welcher AVR?
> BOD enabled oder externer Reset-IC?
>
>
> Peter

ATmega103 - kein BOD
externe Reset Schaltung - kein IC

von Thomas W. (thomas_v2)


Lesenswert?

Mich würde ja mal interessieren, ob seitens Atmel irgendwie am GCC 
mitgearbeitet wird. Für kommerzielle Anwendungen wird wohl der IAR 
überwiegend eingesetzt, der GCC ist aber trotzdem nicht ganz 
unerheblich.

Aber wie Jörg Wunsch oben schon schrieb, gehört der AVR beim GCC nicht 
zu den preferierten Architekturen.

von Funkamateur4 (Gast)


Lesenswert?

Hallo Thomas A.,
also wenn ich deine Frage so sehe haben schon viele geantwortet. Ein 
Resumee ist vielleicht es kommt auf Service, Support, Qualität, Stand 
der Technik, Umwelt, Periepheriefreundlichkeit, Verfügbarkeit... an. Im 
Kaufmännischen ist natürlich der Preis ein wichtiges Kriterium. Bei den 
älternen OMs ist die Mutter Natur und Väterchen Zeit. Aber warum hat man 
auf den Entwickler Boards keinen Socket für SO und TSSO Gehäuse. Es gibt 
kaum Sockel oder Fassungen für SMD. Vielleicht könnte Atmel diese neben 
der XMega implementierung auf dem STK500 mit implementieren oder einen 
Bausatz zum dranstecken damit wenn wir alle irgendwann mal älter werden 
auch die SMD sehen und diese geschickt auf die alten Platinen die in 
Wartung sind einbauen können in einigen Jahren und zwar auch in kleinen 
Stückzahlen oder ein Mikrosskop als Zusatzequipment für SMD was man via 
USB and einen Laptop anschliessen kann damit wir es noch sehen können. 
Schickt die Entwickler mal in die Betriebe und zu den Wartungsfirmen und 
zu den Bastlern. Dann sehen die mehr und bauen besser.

von utah (Gast)


Lesenswert?

> Dann sehen die mehr und bauen besser.

Vielleicht sollten sich die Bastler auch mal eine Entwicklungsabteilung 
ansehen und Entwickler sprechen. Vielleicht erfahren sie dabei, wie eine 
Serie über 100 ... 1.000.000 Geräte/Jahr stabil ans laufen gebracht 
wird. Es gibt auch die Anfordeung, mittels einiger eigens konstruierter 
Sondergeräte ein 100.000 ... 1.000.000 EURO-Projekt im engen Zeitrahmen 
abzuwickeln. In beiden Fällen ist den Entwicklern eine "schöne bunte 
Entwicklungsoberfläche" vollkommen egal, wichtiger ist eine absolut 
stabile Hard- und Software binnen kürzester Zeit mit beschaffbaren 
Komponenten zu erstellen. Eine noch so toll gebaute Hard- und Software 
ist wertlos (oder wertgemindert), wenn sie nicht rechtzeitig fertig 
wird, schwer zu beschaffenden Komponenten enthält, sich nur mit erhöhtem 
Aufwand fertigen läßt oder zu viele "Kinderkrankheiten" enthält, daß 
heißt, aus zu vielen nicht bereits gut getestete Hard- und Softwareteile 
besteht.

von Winfried (Gast)


Lesenswert?

Kommt noch hinzu: Wenn man in einem Umfeld tätig ist, wo man ständig 
unter Zeitdruck zuverlässige Ergebnisse produzieren muss, wird man nicht 
das Risiko eingehen, neue Technologien auszuprobieren, wenn es technisch 
nicht nötig ist. Man wird auf altbewährtes zurückgreifen, was gut 
getestet und bekannt ist. Deshalb wird vielleicht öfters mal ein 8051 
Derivat verwendet, als ein relativ neuer AVR. Erst die nächste 
Entwickler-Generation hat vielleicht Gelegenheit, neue Technologien 
einzuführen.

von chorus (Gast)


Lesenswert?

Das ist wahr: Erfahrungen, mit einer bestimmten Problemlösungstechnik in 
vorgegebner Zeit sicher ans Ziel zu kommen, sind extrem wichtig. Da 
können die Vorzüge einer Architektur schnell mal ins Hintertreffen 
geraten.

Wenn dann aber die neue Generation der Entwickler kommt, sind die 
natürlich überlegen.

von chorus (Gast)


Lesenswert?


von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Thomas W. wrote:

> Mich würde ja mal interessieren, ob seitens Atmel irgendwie am GCC
> mitgearbeitet wird.

Für den 8-bit-AVR nicht direkt.  Das liegt aber weniger am Wollen
als mehr daran, dass bislang niemand aufgetaucht wäre, der sich mit
den nötigen soliden Kenntnissen im AVR-Teil des GCC bei Atmel
beworben hätte um eine Stelle. ;-)

Indirekt schon, wenn du den Begriff des AVR-GCC etwas weiter fasst.
Eric Weddington ist seit einiger Zeit bei Atmel angestellt und hat
nunmehr damit die dienstliche Aufgabe, WinAVR zu betreuen.

Für den AVR32 ist das anders, dort ist die GCC-Portierung komplett
innerhalb von Atmel entstanden und wird entsprechend auch dort
vorangetrieben.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

utah wrote:

> Vielleicht sollten sich die Bastler auch mal eine Entwicklungsabteilung
> ansehen und Entwickler sprechen.

Was wollte uns der Dichter eigentlich mit dieser Einlassung sagen?

Ich hab's jedenfalls nicht verstanden.  Du hast eine Reihe an Fakten
aufgeführt, aber ich sehe nicht, für oder gegen wen das in irgendeiner
Form sprechen sollte.

Machen wir uns doch nichts vor: kein Mensch könnte es sich auf dieser
Welt leisten, etwas wie einen brauchbaren Microcontroller in Serie
in Silizium zu gießen, nur um damit irgendwelche Bastlerherzen höher
schlagen zu lassen.  Dafür kostet die Entwicklung einfach zu viel.
Ergo werden alle vorhandenen Controller (so sie nicht gerade wirklich
nach dem ersten Chip im Nirvana verschwunden sind) ihre industrielle
Anwendung haben.  Damit stehen die genannten Forderungen an alle von
ihnen.

von utah (Gast)


Lesenswert?

> Was wollte uns der Dichter eigentlich mit dieser Einlassung sagen?

Hier wurde an mehreren Stellen die Vermutung geäußert, daß eine 
Entwicklung durch die Verwendung des neuesten AVRs automatisch 
erfolgreicher ist.

Dem ist leider aber nicht so. Der Erfolg (= Erfüllung aller 
Projektanforderungen zu genau 100%) hängt in ganz wesentlichem Maße von 
den genannten Bedingungen (z.B. bei Controllern: Preis, Beschaffbarkeit, 
Ausnutzung vorhandener Resourcen, Handling) ab. Somit gibt es durchaus 
sehr gute Gründe, ggf. auch noch einen 8051 einzusetzen.

Auf jedenfall liegen aber bei diesen Spielchen (oder sollte ich besser 
im Wettbewerbsumfeld von Krieg reden) die PICs ganz weit vorne. Sie 
haben neben den Vorteilen einer sich ständig verbessernden Hardware (bei 
meist voller Abwärtskompatibilität) den großen Vorteil, daß sie gut zu 
beschaffen und angekündigte Typen auch pünktlich lieferbar sind.

Im übrigen liegt mir die Dichtkunst sehr fern.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

utah wrote:

> Hier wurde an mehreren Stellen die Vermutung geäußert, daß eine
> Entwicklung durch die Verwendung des neuesten AVRs automatisch
> erfolgreicher ist.

Seltsam, was manche Leute hier so rauslesen.  Das war mir noch
nicht untergekommen.

> Dem ist leider aber nicht so. Der Erfolg (= Erfüllung aller
> Projektanforderungen zu genau 100%) hängt in ganz wesentlichem Maße von
> den genannten Bedingungen (z.B. bei Controllern: Preis, Beschaffbarkeit,
> Ausnutzung vorhandener Resourcen, Handling) ab.

Naja, man kann natürlich die Projektanforderungen auch schon so
formulieren, dass sie nur ein ganz bestimmter Controller (oder eine
Controllerfamilie) zu 100 % erfüllen kann.  Das fängt ja schon damit
an, dass eine (da es in den Anforderungen steht, vermutlich begrün-
dungslos dahin geschriebene) Forderung nach second source eine ganze
Reihe an Controllern von vornherein aus dem Rennen nimmt, selbst wenn
sie sonst die vernünftigere für das Projekt wäre.

> Auf jedenfall liegen aber bei diesen Spielchen (oder sollte ich besser
> im Wettbewerbsumfeld von Krieg reden) die PICs ganz weit vorne.

Quelle?  So pauschal sowieso eine recht nutzlose Aussage, da sie
sämtliche Anwendungsgebiete (automotive, consumer electronics,
industrial control) in einen Topf schmeisst.  Allein die regionalen
Unterschiede sind schon extrem.  Ich habe mal eine Marktanteilsanalyse
gesehen, das Verhältnis zwischen PIC und AVR beispielsweise ist für
Kunden in den USA und in (West-)Europa ziemlich entgegengesetzt.  In
Fernost wiederum spielen japanische Produzenten eine viel größere
Rolle als in EU oder USA.

von utah (Gast)


Lesenswert?

> Seltsam, was manche Leute hier so rauslesen.  Das war mir noch
> nicht untergekommen.

Und ich kann die Argumentation von Leuten oft nicht nachvollziehen, die 
in Foren Aussagen treffen ohne sich die Mühe gemacht zu haben, 
zugehörige Beiträge durchzulesen und verstanden zu haben. Wie konntest 
Du diese bisherigen Aussagen denn nur übersehen:

> Hier ein nettes Filmchen:

> ... werden in sämtlichen neuen Geräten AVRs verbaut

> Früher oder später werden das auch noch die stursten Ingenieure
> begreifen

> Das liegt an alten Sturköpfen, die ihre Meinung so weitergeben.

> ... deshalb werden diese nicht einen neuen uC ausprobieren ...

> ... das die kunden einfach zu blöd sind sich auf einen anderen prozessor
> umzuorientieren ...

Weiterhin argumentierst Du mit der vermeintlichen Anforderung "Second 
Source". Davon habe ich, da es bei den meisten Projekten nur eine 
untergeordnete Rolle spielt, garnicht gesprochen. Ich behaupte vielmehr, 
Projekte lassen sich nur zu 100% realisieren, wenn die dazu notwendigen 
Mikrocontroller auch rechtzeitig zu beschaffen sind. Meine persönlichen 
Erfahrungen lehrten mich, daß hier Microchip deutlich vor Atmel (und 
einigen anderen Herstellern) liegt. Da ich gezwungen bin (s.o.), 
Projekte im 100.000 ... 1.000.000 EURO-Bereich pünktlich zu realisieren, 
suche ich die verwendeten Komponenten natürlich sehr sorgfältig aus. 
Atmel-Mikrocontroller fallen dabei leider durch das Raster. Ich habe 
aber nichts dagegen, daß alle unsere Mitbewerber Atmel gerne einsetzen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

utah wrote:

> Wie konntest
> Du diese bisherigen Aussagen denn nur übersehen:

[deletia]

Die habe ich einfach als Dummschwatz ignoriert.  Dagegen braucht man
nicht argumentieren, weil sich die Schreiber eigentlich selbst
diskreditiert haben und ohnehin deiner Argumentation kaum zugänglich
sein werden.

Es war mir auch nicht wirklich klar, dass sich deine allgemein gehaltene
Aussage auf derartigen Dummschwatz beziehen wollte.  Vielleicht solltest
du ja mit Zitaten arbeiten, dann wird das klarer.

> Weiterhin argumentierst Du mit der vermeintlichen Anforderung "Second
> Source".

Das war lediglich ein Beispiel, wie man bereits mit dem Formulieren
der Anforderungen ganz bestimmte Bauteile so aus einer möglichen
Lösungsmenge ausschließen kann, dass mit diesen eine 100%ige
Realisierung einfach nicht möglich ist.  Man könnte sich genauso gut
bestimmte technische Details rauspicken, die nur bei einem einzelnen
Controller realisiert sind.

> Meine persönlichen
> Erfahrungen lehrten mich, daß hier Microchip deutlich vor Atmel (und
> einigen anderen Herstellern) liegt.

Dazu kann ich nichts sagen, mir haben bislang andere Leute meine AVRs
für die dienstlichen Projekte beschaffen müssen. ;-)  Ich habe sie
aber nicht über Lieferschwierigkeiten klagen gehört, zumindest nicht
über ungewöhnliche.  (Lieferfristen von 6 Wochen für große Stückzahlen
dürften ja eher im normalen Bereich sein.)  Ich kenne hier nur Maxim
als verrufen, aber da hat uns ja deren Chef in der letzten Reklame-
zeitung versichert, dass sie daran arbeiten wollen...

Für Millionenstückzahlen wundert es mich aber schon, dass hier die
Hersteller nicht bemüht sind, die entsprechenden Schwierigkeiten
auszuräumen um den Auftrag doch noch zu bekommen.  Einen Verkauf
von einer Million Controller lässt man sich eigentlich nicht gern
durch die Lappen gehen.

von Bensch (Gast)


Lesenswert?

> Ich kenne hier nur Maxim
als verrufen, aber da hat uns ja deren Chef in der letzten Reklame-
zeitung versichert, dass sie daran arbeiten wollen...

Das was am 1.April, ja?

Das geht nun schon seit Jahrzehnten so, drum wird hier im Haus kein 
einziges MAXIM-Bauteil eingesetzt. Man ist ja nicht blöd.....

von Punktrichter (Gast)


Lesenswert?

ja MAXIM trägt die rote Laterne.
Da muss ich zustimmen!

von Jadeclaw D. (jadeclaw)


Lesenswert?

RE: Maxim
Das ist der einzige Hersteller, wo mir das auch zu Ohren gekommen ist. 
Und wohl der einzige, der, wenn ein Drittanbieter angeblich nicht mehr 
will, eine Reihe von ICs einfach aus dem Programm wirft. MAX038 kommt 
mir da in den Sinn. Bei Atmel ist mir eigentlich immer nur der große 
Zeitraum zwischen Ankündigung eines Controllers und Erhältlichkeit für 
Jedermann aufgefallen. Ob industrielle Anwender auch so lange warten 
müssen, ist mir allerdings nicht bekannt.

Gruß
Jadeclaw.

von Unbekannter (Gast)


Lesenswert?

Maxim arbeitet anders. Die bringen am laufenden Band neue Designs raus, 
und auch wirklich nette Teile. Davon wird dann eine Serie gesampelt und 
auf den Markt und in die Promo geworfen. Findet sich nun ein Abnehmer 
der eine signifikante Menge von einem Teil benötigt, geht das Teil in 
die Produktion. Wenn nicht, wird es einfach bis zum letzten Teil 
ausverkauft und nicht neu aufgelegt.

Maxim-Teile kauft man einmal in der Menge, wie man sie benötigt und legt 
sie sich ans Lager (bei Kleinserien). Maxim-Teile kann man nicht 
nachkaufen, wenn man nur ein paar hundert oder tausend benötigt. Das 
weis man aber schon vorher.

von Thilo M. (Gast)


Lesenswert?

Hat schon mal einer gezählt wieviele Varianten vom MAX232 es gibt? :-/

von Jadeclaw D. (jadeclaw)


Lesenswert?

Jau, et läppert sich...
Wobei, der MAX202 (die erste Version)ist noch nichteinmal bei Maxim 
entstanden, das war ein Intersil/Harris-Design. Und alles, was dann 
folgte, waren eh nur Ableitungen desselben Designs. Wohl auch deshalb 
gab und gibt es diese RS232-Treiber aus allen möglichen Quellen. Meine 
MAX232 hier sind von Texas.

Unbekannter schrieb:
> Maxim-Teile kauft man einmal in der Menge, wie man sie benötigt und legt
> sie sich ans Lager (bei Kleinserien). Maxim-Teile kann man nicht
> nachkaufen, wenn man nur ein paar hundert oder tausend benötigt.

Das kann ins Auge gehen. Stichwort Garantiefristen und in manchen 
Ländern gibt es auch Vorschriften, was das Vorhalten von Ersatzteilen 
anbelangt. Wenn dann so ein Maxim-IC in einem Gerät platzt und man 
bekommt es nicht mehr, dann hat man ein Problem. Und nicht alles, was 
jemals zu haben war, taucht bei Aftermarket-Herstellern wie Lansdale ( 
http://www.lansdale.com/ ) wieder auf.

> Das weis man aber schon vorher.
Mir war es noch nicht bekannt.
( Was vielleicht auch daran liegt, daß ich nicht professionell Bauteile 
beschaffen muß. )

Gruß
Jadeclaw.

von Bensch (Gast)


Lesenswert?

> Das weis man aber schon vorher.

Ja? Ich hab schon Designs für Kunden gemacht, da war die Rede von max. 
500 Baugruppen. Die Dinger laufen jetzt schon 10 Jahre und wir sind im 
Moment bei 8000 Stück.....

 wnn du Spielzeug baust, machst du EINE Serie, aber nicht bei 
professioneller Elektronik.

von Roman Mittermayr (Gast)


Lesenswert?

Ich sehe hier schon eher die Möglichkeit, dass ATMEL noch rasanter 
wachsen wird (hab mir hoffentlich nicht umsonst Aktien gekauft).

Ich glaube ein wesentlicher Entscheidungsursprung kommt immer noch vom 
"kleinen Mann". Alleine das Forum hier, oder avrfreaks, etc. - was dort 
nun an Quellcode erzeugt wird. Da wird sich jeder Industrieentwickler 
freuen - die schreiben ja auch nicht alles from scratch (dumm wären 
sie). Früher war halt der PIC das non plus ultra wenn es um existierende 
Codebeispiele, Projekte und IDE usw. ging. Aber ATMEL hat knallhart 
nachgelegt mit den Tools, mit der Community Betreuung usw.

Ich hab bei meinem Buch auch überlegt, ob ich mich dem PIC (oder anderen 
Controllern, 32 Bit, oder der kurz gehypte Renesas, etc.) widmen soll - 
aber der stark wachsende Anteil an Hobby-Entwicklern die sich dem AVR 
verschreiben ist halt unübersehbar.

Die erzeugen eine Menge Code (oder manche auch "Kot") und diese Codebase 
lieben Industrieentwickler wiederum (wenn sie den Code nicht gerade 
zukaufen, was meist der Fall ist). Außerdem sind viele 
Hobbyprogrammierer auch in SW/HW Firmen tätig und predigen dort ihre 
Religion vom AVR oder ATMEL.

ATMEL muss halt mit seiner "Sympathie" noch ein wenig nachziehen, nicht 
alle sind so nett wie Eric Weddington, oder Jörg Wunsch, der zwar nicht 
dort arbeitet, aber im Hobbybereich ein großes Zugpferd ist :)

Also ich hoff es zumindest, weil dann verkauft sich auch mein Buch :)

Mehr dazu übrigens auf http://www.avrbuch.de

von Gast (Gast)


Lesenswert?

>Ich glaube ein wesentlicher Entscheidungsursprung kommt immer noch vom
>"kleinen Mann".

Deinen Glauben teile ich nicht.

>Also ich hoff es zumindest, weil dann verkauft sich auch mein Buch :)

Das ist hier wohl mehr Dein Anliegen, als Fakten zu liefern, die in 
Deinem Buch sicherlich auch nicht zu finden sein werden.

von vorbeigeschlendert (Gast)


Lesenswert?

@ Roman Mittermayr

please stop SPAMMING !!

von Roman Mittermayr (Gast)


Lesenswert?

hehe :-)
Immerhin verpack ich es in gute Tipps. Oder nicht?

Sorry.

von Gast (Gast)


Lesenswert?

>Immerhin verpack ich es in gute Tipps. Oder nicht?

nein, nicht.

von Roman M. (Firma: www.avrbuch.de) (romanmittermayr)


Lesenswert?

Ok, das Kollektiv hat entschieden. Verzeiht mir. Will ja niemanden 
ärgern hier, weicht außerdem vom Thema ab (also letztes Kommentar dazu 
von mir). Kommt nicht mehr vor. Aber ich werd trotzdem versuchen Tipps 
zu geben, wenn ich glaube was zu wissen (ansonsten, roman@avrbuch.de, 
können wir ja auch off-thread ausreden).

von kommutator (Gast)


Lesenswert?

Um mal wieder zum Thema "AVR unbeliebt" zurückzukehren...

In meiner Firma (Automobil-Zulieferer) werden keine Atmels verwendet 
weil:

- sie für die uns interessierenden Steuergeräte-Klassen ganz einfach 
nicht auf der positiv-Liste der verschiedensten OEMs stehen und man 
damit die ganze SW-Infrastruktur (z.B. Betriebssystem, 
Netzwerkmanagement, Diagnose, ...) selber entwickeln (lassen) und vor 
allem verantworten muss.

- Die OEMS auf rd. 15 Jahren Lieferbarkeit für ein Produkt bestehen: 
Welcher Lieferant will da das Risiko eingehen, nach 8Jahren nochmal für 
den Ersatzteilebedarf eine Neuentwicklung, Test, Qualifikation etc. zu 
stemmen?

- Wiederverwertbarkeit, Betriebsbewährtheit: Die IEC61508 ist ja schon 
angesprochen worden, wenn man als Hersteller mit 2 bis 3 
Prozessorfamilien das knowhow hat, SIL3 zu erreichen, wird man das kaum 
wegwerfen wollen - man bleibt also bei dem, was man kennt. (Besser einen 
bekannten Fehler als einen unbekannten...)

- Infrastruktur: Umstieg auf neue Prozessoren ist teuer: neue Compiler, 
Einarbeitung, neue Emulatoren, Debugger,...

Die Gründe liegen also nicht so sehr am Prozessor, sondern eher beim 
Hersteller, dessen Zuverlässigkeit, Lieferfähigkeit etc.
Für Anwendungen, die kürzere Produkt-Lebenzyklen als Autos haben, kann 
die Prozessorwahl daher völlig anderen Kriterien folgen.

Gruß,
k.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

kommutator wrote:

> Für Anwendungen, die kürzere Produkt-Lebenzyklen als Autos haben, kann
> die Prozessorwahl daher völlig anderen Kriterien folgen.

Damit bleibt trotzdem die Frage offen, wofür Atmel denn so viele
AVRs mit automotive-Qualifizierung (teilweise bis 150 °C) produziert,
wenn sie angeblich keiner im Automobilbereich einsetzen würde.  Ich
kann mir nicht vorstellen, dass man die dafür notwendigen Zertifi-
zierungen als Hersteller angehen würde, wenn man nicht auch wirkliche
Kunden dafür hätte.

von "Profi" (Gast)


Lesenswert?

Weil die "Profis" kein´ Plan von der Materie haben ;-)

von 6646 (Gast)


Lesenswert?

Anbietet. Fabrizieren ist eine andere Sache. Wie hoch die Stuckzahlen 
wirklich sind weiss ich auch nicht. Zuerst muss man zertifizieren, dann 
anbieten, sonst ist eh nichts.

von sepp (Gast)


Lesenswert?

>Damit bleibt trotzdem die Frage offen, wofür Atmel denn so viele
>AVRs mit automotive-Qualifizierung (teilweise bis 150 °C) produziert,
>wenn sie angeblich keiner im Automobilbereich einsetzen würde.  Ich
>kann mir nicht vorstellen, dass man die dafür notwendigen Zertifi-
>zierungen als Hersteller angehen würde, wenn man nicht auch wirkliche
>Kunden dafür hätte.

Atmel wird schon genügend Kunden vor diese Produkte haben oder hoffen 
das Sie diese in Zukunft bekommt.  Da es hier um hohe Stückzahlen geht 
wird Atmel diesen Kunden sicherlich eine lange Verfügbarkeit und 
spezielle Lieferbedingungen zusichern.

Auch wenn Atmel nicht auf den Freigabe Listen der Automobilhersteller 
steht, kann es sein das wenn ein Controller deutliche Vorteile bietet, 
das der Zuliefer versucht die Erlaubniss zu bekommen diesen zu 
verwenden.
Dieser Vorteil kann z.B. der Preis oder auch eine spezielle 
Funktionalität ein.

Wenn es um Mikrocontroller im Automotivbereich geht fallen mir momentan 
aber andere Namen als Atmel bzw. AVR ein. Vielleicht ändert sich das ja 
in Zukunft. Allerdings werden die Platzhirsche ihren Marktanteil 
verteidigen.

Im generellen kann ich diesen Satz  "Atmel ist unter "Profis" nicht 
gerade beliebt" nicht nach vollziehen!
Es gibt sicherlich einige die sich mit Atmel Produkten nicht anfreunden 
können. Aber das gibt es bei anderen Herstellen genauso. Wie viele schon 
gesagt haben, von den Bastlern allein kann Atmel nicht überleben.
Atmel wird ganz klar auch von Profis eingesetzt. Allerdings haben diese 
deutlich mehr Produkte zur Auswahl und auch ganz andere Auswahl 
kritierien.
So das sehr oft die Wahl auf Produkte anderer Hersteller fällt. Als 
Bastler ist die Auswahl deutlich eingeschränkter!

Persönlich bin mal gespannt wie der AVR32 sich behaupten kann...

von Jadeclaw D. (jadeclaw)


Lesenswert?

Bleibt die Frage, bedeutet denn die 'Automotive'-Designation, daß 
PKW-Hersteller diese Teile denn in der Fahrzeugelektronik selbst 
verwenden? Schaut man sich an, was alles Räder und einen Motor hat, kann 
man wohl sicher davon ausgehen, daß ein großer Anteil an 
'Automotive'-Teilen nicht im PKW-Bereich verbaut wird. 'Automotive' 
heißt platt übersetzt 'Selbstfahrend'. Das könnte auch ein Gabelstapler 
sein, dessen Batterie von einem AVR überwacht wird. Auch glaube ich 
nicht, daß Zertifizierungen und ähnliches in allen Fahrzeugkategorien 
gleich behandelt werden.

Gruß
Jadeclaw.

von chorus (Gast)


Lesenswert?

Glaub ich nicht. Die großen Stückzahlen beziehen sich schon auf die 
Automobilindustrie.
Das Sicherheistargument von weiter oben ( IEC61508 usw ) trifft wohl 
auch nur auf Komponenten im Antriebstrang zu.
Es gibt im Automtivebereich sicherlich haufenweise Komfortfunktionen ( 
z.B. Regenssensor ) bei denen ein SIL Level keine Rolle spielt.
Ich denke, dass große Stückzahlen ins Automobil gehen.

von STK500-Besitzer (Gast)


Lesenswert?

Da stellt sich doch eigentlich die Frage, was "Profis" sind.
Sind das unbedingt diejennigen, die eine hohe Stückzahl verbauen?
Oder auch einfach die, die mit dem Einsatz der Controller Geld 
verdienen?
Ich kenne inzwischen 3 Firmen in der näheren Umgebung, die AVR 
verwenden. Teilweise sogar in sicherheitsrelevanten Bereichen.
Das sind nicht unbedingt viele im Vergleich zu der Menge an Controllern, 
die es so gibt. Aber die Anwendungen werden mehr.
Es hätte ja auch keiner gedacht, dass sich die 8051er-"Architektur" so 
lange hält. Tut sie aber. Und so kann es auch sein, dass AVR mehr 
werden.

Die 89Cxx51 von Atmel werden sogar noch öfter verwendet.

Die Zertifizierung im Automotiv-Bereich ist vermutlich vergleichbar mit 
den Zertifizierungen im militärischen oder medizinischen Bereich.
AVR hatten ein EMV-Problem, weswegen sie in gewissen Anwendungsbereichen 
"verschrieen" waren. Das hat sich wohl gebessert...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

STK500-Besitzer wrote:

> Da stellt sich doch eigentlich die Frage, was "Profis" sind.

Das ist einfach: "Profi" ist die Abkürzung von "professionell", und
das heißt (entgegen dem landläufigen Gebrauchsmuster) einfach nur,
dass man damit seine Brötchen verdient.  Das Gegenteil dürfte ein
Amateur sein, der irgendwas nur nebenbei, aus Spaß betreibt.  Auch
hier wird oft eine Wertung in den Begriff hineingelegt, die schlicht
unzutreffend ist: es gibt bspw. Funkamateure, die im zweistelligen
GHz-Bereich bauen und manchem HF-Profi in Technikkenntis deutlich
überlegen sind -- aber sie verdienen mit dieser Technik nicht ihr
Geld (und wollen das auch nicht), daher sind sie Amateure.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Vielleicht gehören ja auch Fahrräder zum "Automotive-Bereich". In den 
Leihfahrrädern der Bahn wurden jedenfalls Atmel-µCs verbaut ... und die 
wiederum erfolgreich "modifiziert":

http://www.ccc.de/hackabike/index_de.html

von sous (Gast)


Lesenswert?

>Da stellt sich doch eigentlich die Frage, was "Profis" sind.
>Sind das unbedingt diejennigen, die eine hohe Stückzahl verbauen?

Um das von Jörg gesagt noch zu ergänzen: Ein Profi ist der, der sein 
Geld damit verdient, unabhängig von der Stückzahl. Manche Profis 
entwickeln Geräte für Großserien, andere Einzelstücke oder Kleinserien 
(vielleicht nur 10 Stück), je nach Anwendung und Kundenwunsch.

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.