www.mikrocontroller.net

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


Autor: Thomas A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Frank N. (arm-fan)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: hoerst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uns z.B.
Steuerungshersteller.

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

Autor: Jörg B. (manos)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Matrix (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ^^

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hauptschul-Ing (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Mario Hagen (djacme)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Punktrichter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Kai (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Robin Tönniges (rotoe) Benutzerseite
Datum:

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

Autor: Kai (Gast)
Datum:

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

Autor: Patrick S. (kof)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Rufus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: JÜrgen Grieshofer (Firma: 4CKnowLedge) (psicom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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 ^^

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: gast (Gast)
Datum:

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

Autor: Rufus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Marvin M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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....

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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)

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 
?

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Walther Z. (chilipower)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
-1 lesenswert
nicht 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?

Autor: crazy horse (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
ich kenn keinen.

Autor: NO8086 (Gast)
Datum:

Bewertung
1 lesenswert
nicht 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 :-)

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@OT
@serial.h
Schau dir die Libs von Fleury an...

http://homepage.hispeed.ch/peterfleury/avr-softwar...

Autor: Stefan May (smay4finger)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Schau dir die Libs von Fleury an...

Wozu ?

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: hellboy (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Mehmet Kendi (mkmk)
Datum:

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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehmet Kendi wrote:

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

Bitte genauer, das kann ich jetzt nicht nachvollziehen.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Mehmet Kendi (mkmk)
Datum:

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

Autor: Tomino (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Walther Z. (chilipower)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Paul (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Stefan May (smay4finger)
Datum:

Bewertung
1 lesenswert
nicht 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.

Autor: Thomas A. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht 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.

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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 :).

Autor: Jens Plappert (Firma: FTSK) (gravewarrior)
Datum:

Bewertung
0 lesenswert
nicht 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?
;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.)

Autor: Thomas A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 :-)

Autor: Punktrichter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefan May (smay4finger)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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&f...

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?"

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht 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?:
loop:
  ;macht irgenwas
  ...
  CPSE r0,r1
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:
BST r0,3
BRTS bit3_gesetzt
BST r0,5
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

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Herbert vom Kaventsmann (Gast)
Datum:

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

Bert

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: sous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Behauptung "Atmel bei Profis unbeliebt" ist einfach vollkommener 
Quatsch!

Autor: Patrick (Gast)
Datum:

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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Tobi. S (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ...

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael Leske (nemesisod)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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ß.

Autor: utah (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Walther Z. (chilipower)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: chorus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: utah (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.”

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Jens Plappert (Firma: FTSK) (gravewarrior)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Thomas A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ??

Autor: Punktrichter (Gast)
Datum:

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

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er meinte natürlich 0 FEHLERpunkte...

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

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: micro1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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^^

Autor: Rüdiger Knörig (sleipnir)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht 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 :)

Autor: chorus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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€.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Gottfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 
...).

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht 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, ...)

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Steffen (Gast)
Datum:

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

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter :
>bin dann auf LPC 23xx umgestiegen.

mein BEILEID .

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: C. H. (_ch_)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: C. H. (_ch_)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Hugo Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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?!

Autor: 6645 (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: 6645 (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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....

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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:
// Testdatei
// CPU = ATTiny13
#include <avr/io.h>
#include <util/delay.h>

#define LEDBIT 4

main (void)
{
  DDRB = 0x10;
  PORTB = 0xFF;
  for (;;)
  { 
    _delay_ms(200);
    PORTB |= (1 << LEDBIT);    /* setzt Bit 4 an PortB auf 1 */
    _delay_ms(200);
    PORTB &= ~(1 << LEDBIT);   /* loescht Bit 4 an PortB */
  }
  return (0);
}

Und das wird daraus:
0000004a <main>:

#define LEDBIT 4

main (void)
{
  4a:  80 e1         ldi  r24, 0x10  ; 16
  4c:  87 bb         out  0x17, r24  ; 23

    DDRB = 0x10;
  PORTB = 0xFF;
  4e:  8f ef         ldi  r24, 0xFF  ; 255
  50:  88 bb         out  0x18, r24  ; 24
  52:  e0 e6         ldi  r30, 0x60  ; 96
  54:  fa ee         ldi  r31, 0xEA  ; 234
 */
void
_delay_loop_2(uint16_t __count)
{
  __asm__ volatile (
  56:  8e 2f         mov  r24, r30
  58:  9f 2f         mov  r25, r31
  5a:  01 97         sbiw  r24, 0x01  ; 1
  5c:  f1 f7         brne  .-4        ; 0x5a <main+0x10>
    for (;;)
    { 
    _delay_ms(200);
    PORTB |= (1 << LEDBIT);    /* setzt Bit 4 an PortB auf 1 */
  5e:  c4 9a         sbi  0x18, 4  ; 24
 */
void
_delay_loop_2(uint16_t __count)
{
  __asm__ volatile (
  60:  8e 2f         mov  r24, r30
  62:  9f 2f         mov  r25, r31
  64:  01 97         sbiw  r24, 0x01  ; 1
  66:  f1 f7         brne  .-4        ; 0x64 <main+0x1a>
    _delay_ms(200);
    PORTB &= ~(1 << LEDBIT);   /* loescht Bit 4 an PortB */
  68:  c4 98         cbi  0x18, 4  ; 24
  6a:  f5 cf         rjmp  .-22       ; 0x56 <main+0xc>

0000006c <_exit>:
  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.

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Hardfreak (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: chorus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ?

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht 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%20Au...
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.

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du hast nen externen Interrupt zum Tasten Abfragen

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gottfried S. wrote:

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

Welcher AVR?
BOD enabled oder externer Reset-IC?


Peter

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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. 
;)

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Funkamateur4 (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: utah (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: chorus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: chorus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: utah (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: utah (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.....

Autor: Punktrichter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja MAXIM trägt die rote Laterne.
Da muss ich zustimmen!

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Thilo M. (Gast)
Datum:

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

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Roman Mittermayr (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: vorbeigeschlendert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Roman Mittermayr

please stop SPAMMING !!

Autor: Roman Mittermayr (Gast)
Datum:

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

Sorry.

Autor: Gast (Gast)
Datum:

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

nein, nicht.

Autor: Roman Mittermayr (Firma: www.avrbuch.de) (romanmittermayr)
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: kommutator (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: "Profi" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil die "Profis" kein´ Plan von der Materie haben ;-)

Autor: 6646 (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: chorus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: sous (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly wrote:

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

Schade, dass sie bei eigentlich (immerhin durch den CCC bescheinigter)
guter Intelligenz so trottelig waren, die Lockbits nicht zu setzen.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Fragestellung hier im Thread ist durch das Wort "Profi" eigentlich 
viel zu allgemein. Man hätte schon fast schreiben können "Atmel ist 
unter Menschen nicht gerade beliebt".

Die Fragestellung, die mich viel mehr interessiert ist: Wo sind die 
typischen Einsatzbereiche für AVR's und wo werdern sie eher gemieden?

Da scheint sich herauszukristallisieren, dass im Automobilbereich die 
Teile eher gemieden werden. Ebenso in Bereichen, wo langfristige 
Verträge gemacht werden und große Stückzahlen der Controller immer am 
Markt verfügbar sein müssen.

In einer Firma, wo z.B. 1000 Geräte im Jahr mit AVR gebaut werden, ist 
es überhaupt kein Problem, Engpässe von 6-12 Monaten durch Lagerhaltung 
zu überbrücken. Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein 
Chip nicht mehr verfügbar ist, oft kein Problem darstellen. Zumal die 
Nachfolgetypen bisher recht kompatibel waren.

Das große Horrorszenario wäre, wenn AVR mal pleite geht und man auf 
völlig andere Chips umsteigen müsste. Aber das wird wohl nicht 
passieren: Die Firma würde übernommen werden und der Markt, der ja da 
ist, weiterbedient.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob es tatsächlich Vorsprung war, oder nur gutes Marketing?

Vor vielen Jahren wurden mir persönlich die MCS51er zu langsam und zu 
aufwendig. Für jeden Hersteller eines Derivats dieser Klasse musste man 
einen eigenen Programmer bauen oder kaufen. Motorola wuselte parallel 
mit seinen HC Typen herum und hatte, wie zuvor die MCS auch das Problem 
mit einem externen Latch und ROM. Dazu kam, dass man vom Z80 zum MCS 
Bustechnisch nicht so weit umdenken musste und PullUps waren mir schon 
immer lieber als PullDowns. (Motorola hatte doch ein Active-High 
Chip-Select, oder?)
Aufgrund diverser inkompatibilitäten zog also auch das Argument 
Second-Source innerhalb der MCS51er nicht mehr wirklich, wenn man auch 
nur kleine Verbesserungen mitnehmen wollte. Da kochte jeder Hersteller 
sein eigenes Süppchen. Wollte man zudem mehr Geschwindigkeit, dann gab 
es mit Dallas auch nur einen einzigen Hersteller und einen unannehmbaren 
Preis für Einzelstücke.
PIC verlangte für jeden Chip eine eigene IDE, totaler Murks.
So bin ich, weil preiswert und All-Inclusive auf den AT90S8515 gekommen. 
Irgendwie sah die Idee dahinter sehr einfach und einladend aus. RISC, 
Single-Cycle Instructions... Ein Programmer erschlug eine ganze Serie 
Chips unterschiedlicher Größe, eine IDE für alle Chips. Damals habe ich 
alles noch in Assembler gemacht, 150 Befehle hatte man an zwei 
Nachmittagen drauf. Eine große Erleichtung war auch das Errechnen von 
Timings bei der Hardwareemulation in Software. Serielle, IR, SCSI, 
diverse perallel und serielle Bussysteme, was hab ich nicht alles 
emuliert...
Es war sicherlich eine Gefühlsentscheidung, weil das Konzept einfach 
simpel, offen und durchgängig erschien.
Ob es das Marketing war, oder eben der klitzekleine Konzeptvorsprung 
gegenüber anderen Systemen, ich kann es heute nicht mehr sagen. 
Letztendlich zählt aber, dass mich ATMEL bis heute nicht ein einziges 
mal im Stich gelassen hat, es gab immer einen Chip der passte und jede 
Support-Anfrage, egal ob privat oder Beruflich, wurde kurzfristig und 
zufriedenstellend beantwortet.
Natürlich sind die ehemaligen Konkurrenten auch gewachsen. PIC verfügt 
inzwischen über eine IDE für alle, und viele andere Hersteller sind mit 
neuen Designs und Ideen auf dem Markt gekommen.
Bislang konnte mich keine Aufgabe dazu bringen etwas anderes als einen 
AVR einzusetzen obwohl ich fast jede Neuentwicklung in diesem Bereich 
aufmerksam verfolge.
Vielleicht ist es auch anders herum gewesen? Zufor schrieb schon jemand, 
dass die alten Systeme in den Köpfen der Entwickler zu stark verankert 
sind. Ich kenne Sprüche wie "Wir entwickeln seid 30 Jahren für den Z80 
und werden das auch in 20 Jahren noch machen". Vielleicht hatte ATMEL 
bei mir Glück, weil ich damals gerade erst auf dem Sprung vom 
Hobby-Bastler zum Entwickler war und sowohl Zeit als auch Neugier genug 
hatte um einen großen Schnitt zwischen MCS51 und 'Etwas Neuem' zu 
machen.

Gruß, Astralix

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:

> PIC verlangte für jeden Chip eine eigene IDE, totaler Murks.

Nur so aus Neugier, kannst Du das etwas erläutern?
War das in der Zeit von MPLAB? Unter DOS?

Danke

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte Ulrich P. weitgehend zustimmen, obwohl bei Motorola alle CS 
immer low-aktiv waren :-)
Der erste Typ AT90S1200 hob sich nur wenig von den damaligen PICs ab: 
kein RAM, kein Stack. Aber mit den zum 8051 DIL40 und 2051 DIL20 
kompatiblen Typen 8515 und 2313 konnte man dann auf einfache Weise seine 
vorhandene 8051-Schaltung damit testen, zunächst in Assembler, der nicht 
viel konnte, aber den es kostenlos gab. Der Geschwindigkeitsunterschied 
war wie Tag zu Nacht.
Und da man wiederholt umprogrammieren konnte, wollte ich den 8051 auch 
garnicht mehr haben. Alles in einem Gehäuse war einfach zu praktisch.

Profi hin - Profi her, mit den Atmels kann man gut seine Brötchen 
verdienen.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein
Chip nicht mehr verfügbar ist, oft kein Problem darstellen."

Das halte ich für eine seeeehr optimistische Sichtweise.

In der Realität ist nach 10 Jahren der Entwickler an einem ganz anderen 
Projekt, anderen Abteilung oder einer anderen Firma. Die Tools 
produzieren plötzlich ganz anderen Code und können mit der Source nichts 
mehr anfangen. Wenn sie überhaupt noch verfügbar sind.

In der Regel bedeutet so etwas ein Neudesign. Und das dann evtl. für ein 
Produkt, für das nur noch Ersatzstückzahlen benötigt werden.

Da setzt man dann eben lieber Hersteller ein, die noch Bausteine von vor 
10 Jahren im Programm haben. Die haben dann schon mal bewiesen, dass sie 
langfristig liefern.

Und letzlich sind die Vorteile der verschiedenen Architekturen nicht so 
gravierend, alle kochen mit Wasser und kein Controller ist wirklich 
herausragend besser.

Gruss
Axel

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:

>Aber mit den zum 8051 DIL40 und 2051 DIL20 kompatiblen Typen 8515 und >2313 
konnte man dann auf einfache Weise seine vorhandene 8051-Schaltung >damit testen, 
zunächst in Assembler, der nicht viel konnte, aber den es >kostenlos gab.

Bitte erwähne aber auch, dass der Reset-Pegel unterschiedlich ist. Also 
nicht ohne Umbauten auf der gleichen leiterplatte einsetzbar.

Desweiteren hat Atmel bisher für jeden abgekündigten Baustein einen 
funktionskompatiblen und besser ausgestatteten Ersatz geschaffen, sodass 
nach dem (leider neu anzupassenden) Bearbeiten des Quellcodes durchaus 
die Produktion weiter gehen konnte.

Ich bin selber einige Male in die Falle des Kompatibilitätsbits des M103 
gelaufen wie viele hier im Forum. Wenn das konsequent durchgezogen wäre 
á la Bit gesetzt, IC arbeitet mit der alten ID (HEX-Dump unbearbeitet), 
Bit gelöscht, alle neuen Features stehen einem zur Verfügung (mit neuem 
Kompilat), das wäre sinnig gewesen.

MW

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bitte erwähne aber auch, dass der Reset-Pegel unterschiedlich ist. Also
>nicht ohne Umbauten auf der gleichen leiterplatte einsetzbar.

Gut, eine Änderung war aber sowieso notwendig, da man ISP nutzen wollte. 
Aber alle Portpins konnten bleiben und die ser. Schnittstelle 
unterstützte auch den Multiprozessormodus vom 8051. Der Aufwand zum 
Probieren war somit minimal.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel wrote:
> "Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein
> Chip nicht mehr verfügbar ist, oft kein Problem darstellen."
>
> Das halte ich für eine seeeehr optimistische Sichtweise.
>
Nein, bis auf wenige Ausnahmen läuft es doch so ab:
Kunde braucht einen Ersatz für etwas, dass er vor vielen Jahren bei 
irgendwem gekauft hat, der schon längst was anderes macht oder pleite 
ist. Die Bauteile sind kängst nicht mehr verfügbar. Im Grunde war der 
Kunde eh nie so ganz zufrieden und will im Zuge der Aufrüstung gleich 
das ein oder andere Feature mehr haben.

Meine letzten Projekte fingen alle damit an, dass nur eine SPS ersetzt 
werden sollte durch eine andere und dann das ganze System bitte weiter 
5x aufbauen. Es endete damit, dass das nach Einsammeln aller Wünsche 
feststand, dass diese unter Einsatz einer SPS icht erfüllt werden 
könnten. Also wurde ein Prototyp auf Basis einer vollen Eigenentwicklung 
mit AVR und SAM7 erstellt, der wiederum so gut gefiel, dass gleich 7 
weitere Systeme beauftragt wurden.

Bei einem anderen vor 15 Jahren erstmalig ausgelieferten Gerät steht nun 
ein Ersatz an, da auch hier die Bauteile nicht mehr lieferbar oder 
unbezahlbar sind. Da inzwischen ein grafikfähiges Display, SD-Card und 
USB unverzichtbar sind, wurde aus einem 98S8151 ein SAM7.

Letztendlich muss man dem Kunden klar machen, dass er, wenn er mehr 
Leistung und Features haben will auch etwas Gedult und Kleingeld 
investieren muss um dann weitere 10..15 Jahre zu überleben.

Natürlich legt man sich auch als kleine Bude ein wenig Reserven auf 
Lager. Dadurch, dass man aber seine Entwicklungen auf einige Typen 
einschränkt, relativiert sich diese Lagerhaltung aber. Es ist bei 
Kleinserien schon mal billiger einen ATmega64 einzusetzen, wenn man 
diesen schon in drei anderen Projekten verwendet, als einen ATmega16, 
den man speziell nur für ein Board einsetzt und den man dann auch auf 
Halde legen muss um irgendwelche 10-Jahres Verträge einzuhalten.

> In der Realität ist nach 10 Jahren der Entwickler an einem ganz anderen
> Projekt, anderen Abteilung oder einer anderen Firma. Die Tools
> produzieren plötzlich ganz anderen Code und können mit der Source nichts
> mehr anfangen. Wenn sie überhaupt noch verfügbar sind.
>
Das ist sicherlich in besonderen Projekten ein Problem. Andererseits ist 
es aber auch eine Frage der Disziplin. Wenn man jedem Projekt eine 
Datensicherung mit ihrem Letzten Stand gewährt und auch Datenblätter und 
Compiler dort hinzufügt, kann ein Stand schnell wieder hergestellt 
werden.
Andererseits muss man Prioritäten setzen. Wenn ich Zulieferer für die 
Deutsche Bahn oder Automobilindustrie bin oder nach Avionic Normen 
Arbeiten muss, dann ist das sicherlich eine aufwendige Sache.
Aber in fast allen anderen Bereichen ist es eine Frage des 
verkäuferischen Geschicks den Kunden von einem Benefit bei einer 
Plattformumstellung zu überzeugen. Und ich verstehe dabei nicht, ihn 
anzulügen um seine eigenen Versagenskosten wegen fehlender 
Datensicherungen zu decken.

> Da setzt man dann eben lieber Hersteller ein, die noch Bausteine von vor
> 10 Jahren im Programm haben. Die haben dann schon mal bewiesen, dass sie
> langfristig liefern.
>
Wie gesagt, dass ist eine Fall zu Fall Entscheidung. So pauschal, wie Du 
das darstellst, sehe ich das bei weitem nicht. Technischer Stillstand 
tut weder dem Lieferanten noch dem Kunden gut.

> Und letzlich sind die Vorteile der verschiedenen Architekturen nicht so
> gravierend, alle kochen mit Wasser und kein Controller ist wirklich
> herausragend besser.
>
Da kann ich allerdings nur zustimmen. Im Grunde muss man entscheiden, ob 
eine neue Plattform durch ihre speziellen Features mehr Zeit einspart 
als für ihre Einarbeitung erforderlich ist. Im Gegenzug muss man auch 
betrachten, ob diese Ersparnis immer noch gilt, wenn man dieses 
spezielle Feature mit erhöhtem Aufwand auf einer bekannten Plattform 
emuliert.

@GAST
> Ich möchte Ulrich P. weitgehend zustimmen, obwohl bei Motorola alle CS
> immer low-aktiv waren :-)
War es nicht so, dass Motorola dieses High-Aktive E(nable) Signal hatte? 
Zugegeben, ist zu lange her.

@Severino
> Nur so aus Neugier, kannst Du das etwas erläutern?
> War das in der Zeit von MPLAB? Unter DOS?
Das kann gut sein, ich habe mit den MCS51ern und später dann mit den 
AVRs schon gearbeitet, als Windows noch in den Versionen 3.x und kleiner 
existierte. Auch der AVR Assembler war eine reine DOS-Applikation. Hei, 
wie die Zeit vergeht...

Gruß, Astralix

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:

> @Severino
>> Nur so aus Neugier, kannst Du das etwas erläutern?
>> War das in der Zeit von MPLAB? Unter DOS?
> Das kann gut sein, ich habe mit den MCS51ern und später dann mit den
> AVRs schon gearbeitet, als Windows noch in den Versionen 3.x und kleiner
> existierte. Auch der AVR Assembler war eine reine DOS-Applikation. Hei,
> wie die Zeit vergeht...
>
Meinte natürlich " in der Zeit voR MPLAB...".
Und ich habe unter DOS Z80-Programme entwickelt, und Windows 3.x 
startete man nur für bestimmte Anwendungen, und die Zeit vergeht auch 
für mich...
Aber trotzdem: Welche PIC-Typen brauchten eine gesonderte IDE?

Autor: Klaus B. (nuccleon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Das ist einfach: "Profi" ist die Abkürzung von "professionell"

Ich ging bisher immer davon aus, dass "Profi" von "provisorisch" kommt 
;-)

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich ging bisher immer davon aus, dass "Profi" von "provisorisch" kommt

Das ist gar nicht mal so falsch.
Das Provisorium hält am längsten ;)

Autor: MC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich nur bestätigen. Bei mir zu Hause laufen fast nur provisorische 
"fliegende" Aufbauten. Beim Portieren dieser zu entgültigen 
Gerätschaften schleicht sich immer irgendwo ein Fehler ein. Inzwischen 
versuch ich's gar nicht mehr, meine fliegenden Aufbauten verschwinden zu 
lassen.

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
war lange nicht hier, deshalb habe ich in dem 'alten' zeug rumgekramt.

zu meiner person : ich verdiene seit 83 mit µp / µc mein geld.
bin über z8 (bockiges mißtvieh) über z80 und pic bei avr gelandet.

meine meinung zu avr:

was mir grfällt:

- simpler befehlssatz (glaube, so um die 130, wovon ich max. 40% nutze)
- schnell wie der blitz
- sehr, sehr, sehr , ... guter adc
- verfügbarkeit rel. großer µc'c im dil gehäuse (für prototypen)

was mir nicht gefällt:

- die doppelt- oder dreifachbelegung der pin's
- die teilweise kryptische bezeichnung der 'fuse bit's'
- und das schlimmste, die assembler syntax (die namen der
  bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es
  gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich
  verständlicher, weil sie sich direkt auf ein flag bezieht.
  warum ldi , lade register mit konstante und nicht mov, der compiller
  sollte doch alleine zwichen einem register und einer konstanten
  unterscheiden können? .......
  wenn das mir einer erklären könnte wäre ich dankbar.

gruß
pico

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pico:
Nunja, wer von der z80-Seite kommt, muß sich natürlich umgewöhnen, die 
Bezeichnungen sind verständlich, wenn man sich ein paar Millimeter von 
der Hardware löst, z.B.:
breq = Branch if equal --> Verzweige wenn gleich. Jump Relative Zero 
trifft es zwar auch, breq paßt aber perfekt, wenn man einfach nur am 
Ergebnis interessiert ist.
LDI = LoaD Immediate --> Lade Wert direkt ins Register. Ist eigentlich 
auch verständlicher, denn durch das LDI weiß ich, der dabeigefügte Wert 
geht direkt ins Register. Natürlich könnte man alle 
Speicher-/Registerladeanweisungen mit 'MOV' bezeichnen, aber mit 
STI/STS/LDI/LDS/MOV separat sehe ich im Assemblertext direkt, woher die 
Daten kommen und wohin sie geladen werden. Natürlich wäre ein Assembler 
in der Lage, anhand kryptischer Zeichen und unterschiedlicher Klammern 
bei der Wertangabe selbst zu entscheiden, wo was hingeschoben wird, so 
wie es aber beim AVR-ASM gemacht wird, ist es aber merklich besser 
lesbar. Und mir persönlich auch lieber.

Ich habe übrigens auch schon verschiedenste Architekturen hinter mir, 
unter anderem Z80/8085, R6502, 6800/1/2, 8048, 8086. Und ehrlich gesagt, 
die AVR-Controller sagen mir, was Assemblersprache und Architektur 
anbelangt, noch am ehesten zu. Hätte ich bei der Entwicklung was zu 
sagen gehabt, wären ein paar zusätzliche Befehle mit hineingekommen: 
z.B. ein Add Immediate und ein Decimal Adjust, der BCD-Operationen 
merklich vereinfacht. Und der Stack beim AT90S1200 und den anderen 
RAM-losen Teilen hätte auch ein paar Ebenen mehr gehabt.

Gegen die Doppelt-, Drei-, Vierfachbelegung ist leider kein Kraut 
gewachsen, die Anzahl der Anschlüsse ist nunmal begrenzt. Und die 
Benutzer der Chips wollen nunmal alle möglichen Funktionen mit 
drinhaben, da muß man sich entscheiden, was man hinterher braucht und 
ggfs. langsame Peripherie seriell anbinden, will man nicht in jedes 
kleine Gerät ein 100pin-Monster einsetzen. Nur das ist ein generelles 
Problem aller modernen Controller-Architekturen und eben kein originäres 
AVR-Problem.

Gruß
Jadeclaw.

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jadeclaw

.... ,dann sollte avr das z-flag im sreg in in e-flag umtaufen und
      verbieten das logische opp's das e-flag beeinflussen! für mich
      wäre dann mämlich ein konstukt von ....

      ldi   r16, 0b00000001
      or i  r16, 0b00000001
      breq  xyz

      ... nicht mehr lesbar.

gruß pico

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pico wrote:

> was mir nicht gefällt:
>
> - die doppelt- oder dreifachbelegung der pin's

Das läßt sich kaum umgehen.

Dagegen ist die Pinzuordnung bei den Silabs 8051 ne totale Katastophe.
Sobald man einen Pin zuweist, verschieben sich die Funktionen aller 
nachfolgenden Pins nach hinten.
Man muß also schon vor dem Layout ganz genau wissen, welche 
Spezialfunktionen man benötigt. Danach ist ein Wechsel unmöglich.


>   warum ldi , lade register mit konstante und nicht mov, der compiller
>   sollte doch alleine zwichen einem register und einer konstanten
>   unterscheiden können? .......

Naja, beim 8051 wird gerne mal das "#" vergessen bei Konstanten und der 
Code nimmt es als Adresse. Und man sucht ewig den Fehler.

Etwas gewöhnungsbedürftig ist es allerdings, statt 3 Ladebefehlen (MOV, 
MOVC, MOVX) nun 15 Befehle zu benötigen (MOV, MOVW, LPM, SPM, IN, OUT, 
LD, ST, BST, BLD, LDI, LDD, LDS, STD, STS).


Peter

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pico wrote:
> was mir nicht gefällt:
>
> - die doppelt- oder dreifachbelegung der pin's
Jupp, is bissi gefährlich, insbesondere mit dem SPI-Zeuchs. Ist ja auch 
eine oft genug angesprochene Stolperfalle, aber wenn mans weiß, ists 
kein Thema mehr.

> - und das schlimmste, die assembler syntax (die namen der
>   bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es
>   gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich
>   verständlicher, weil sie sich direkt auf ein flag bezieht.
Naja, breq hat vermutlich seinen Namen von der Vergleicherei. Die 
wiederum ist aber auch nur eine Subtraktion und das Steuerwerk setzt im 
Statusregister das Nullbit automatisch immer dann, wenn irgendwo Null 
bei rauskommt. Deshalb kann man auch z.B. nach einem LSR/LSL mit breq 
weiterprüfen.


>   warum ldi , lade register mit konstante und nicht mov, der compiller
>   sollte doch alleine zwichen einem register und einer konstanten
>   unterscheiden können? .......
>   wenn das mir einer erklären könnte wäre ich dankbar.
Jupp, das kann dir einer erklären^^
Ganz verallgemeinert und banal: Ein ASSEMBLER ist kein COMPILER. Der 
Compiler erzeugt aus Hochsprachenquelltext (C, Basic etc.) einen 
Assemblerquelltext. Und der Assembler übersetzt den Assemblerquelltext 
in Maschinensprache. Irgendwo ist es ja der Sinn des Assemblers, eben 
gerade keine automatische Rumersetzerei zu machen, ich will ja genau 
das als Maschinencode erhalten, was ich als Assemblerquelltext 
reinschreibe.

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jadeclaw

>Add Immediate und ein Decimal Adjust ....

die befehle vermisse ich nicht so, da subi mit dem zweiercompliment
den addi befehl ersetzt.

aber einen der wirklich geschwindigkeit bringen würde.

nämlich ret 6 -> vergiß die letzten 6 byte auf dem stack und kehre 
zurück.

folgender hintergrund:

manchmal ergibt sich in der sub, dass eine rekonstruktion der register
keinen sinn mehr macht. aber ich muß mich mit pop's zurückhangeln, das
kostet ordentlich zeit! ich würde nicht in assembler programmieren, wenn
es bei mir nicht selten um einen einstelligen µs-bereich gehen würde.
da hat man unter umständen nur 20-50 takte (befehle) zeit zum reagieren.


gruß pico

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pico wrote:
> folgender hintergrund:
>
> manchmal ergibt sich in der sub, dass eine rekonstruktion der register
> keinen sinn mehr macht. aber ich muß mich mit pop's zurückhangeln, das
> kostet ordentlich zeit! ich würde nicht in assembler programmieren, wenn
> es bei mir nicht selten um einen einstelligen µs-bereich gehen würde.
> da hat man unter umständen nur 20-50 takte (befehle) zeit zum reagieren.

Beim IAR-Compiler werden 2 Stacks konfiguriert, einen RSTACK und ein 
CSTACK.
Der RSTACK ist nur für die Rücksprungadressen und der CSTACK für die 
Registerspeicherung.
Der CSTACK wird mittels Y Register realisiert:
ST -Y,Rr   <-- wie PUSH
LD Rd,Y+   <-- wie POP
Werden Register nicht benötigt nach Funktionsaufrufen so kann das Y 
Register einfach manipuliert werden mittels ADIW oder SBIW

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gottfried S.

das ist ja genial, auf die idee bin ich nach über 20
jähriger berufserfahrung noch nicht gekommen. einfach mit 2 stack's
arbeiten. daten und rücksprungadressen sauber trennen.

danke pico (das kommt von herzen)

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermisse Shifts mit Angabe der Anzahl der Bits, also sowas: LSR r0,3 
um 3 Bits rauszuschieben. Das würde so manchen Code ziemlich 
beschleunigen.
Und dann verstehe ich nicht warum nicht alle AVRs, egal ob Tiny oder 
Mega, die exakt gleiche ALU und somit auch alle die gleichen Befehle 
haben. Es wäre schon vorteilhaft die MUL Opcodes auch auf den Tinys zu 
haben. Das kann nur mit dem Marketing zu tun haben.

Gruß Hagen

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es wäre schon vorteilhaft die MUL Opcodes auch auf den Tinys zu haben.

Der Tiny hat aber nunmal keinen Hardware-Multiplier, dadurch wird er ja 
so billig. Was würde dir der Opcode ohne Hardware-Multiplier bringen? 
Oder redest du von einer Software-Emulation des Befehls?

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen Re

>Ich vermisse Shifts mit Angabe der Anzahl der Bits

das geht wohl mehr in richtung cisc architektur!

gruß pico

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pico wrote:

> - und das schlimmste, die assembler syntax (die namen der
>   bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es
>   gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich
>   verständlicher, weil sie sich direkt auf ein flag bezieht.

In den meisten Architekturen gibt es keine direkte 1:1 Beziehung 
zwischen den bedingten Sprungbefehlen und den Flags. Viele Vergleiche 
mit Vorzeichen fallen darunter, weil darin teilweise bis zu 3 
verschiedene Flags zueinander in Beziehung gesetzt werden (sowas wie 
S^V|Z).

Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu 
implementieren.

>   warum ldi , lade register mit konstante und nicht mov, der compiller
>   sollte doch alleine zwichen einem register und einer konstanten
>   unterscheiden können? .......

Könnte man so machen. Allerdings neigt Atmel offenbar dazu, 
verschiedenen Maschinenbefehlen verschiedene Mnemonics angedeien zu 
lassen. Das hat auch ein bischen was mit CISC vs RISC zu tun. Bei CISCs 
ist es oft so, dass etliche unterschiedlich codierte Befehle den 
gleichen Namen haben, bei RISCs findet man öfter getrennte Namen für 
verschiedene Maschinenbefehle.

Das Extrem davon wäre dann beispielsweise MAXQ2000. Da gibt's eigentlich 
nur noch einen einzigen Befehl, MOV. Der Rest ergibt sich aus diversen 
Seitenffekten der verwendeten Adressen.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pico wrote:

> das geht wohl mehr in richtung cisc architektur!

Als interne Microcode-Schleife realisiert passen sie nicht ins Konzept 
der AVRs. Und würde die Interrupt-Latenzzeit kräftig erhöhen.

Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei 
CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern 
generell eher selten anzutreffen. Zumal der einzige wirklich sinnvolle 
Shifter bei AVR ein 16=>8 Shifter wäre, denn nur dann liesse sich der in 
C-Compilern wirklich nützlich anwenden.

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Kaiser

>Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu
>implementieren.

meinst du eine *.inc datei mit sowas?

.equ jrnz = brne  ;jump relativ not zero
.equ jrz  = breq  ;jump relativ zero
.
.
.
.
.
.

gruß pico

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
4-Bit Shifter:

SWAP Rd
ANDI Rd,0xf0  ; Entspricht LSR Rd,4

Insgesamt 2 Taktzyklen

SWAP Rd
ANDI Rd, 0x0f ; Entspricht LSL Rd,4

Da diese Befehle sehr selten benötigt werden, wäre es bestimmt eine 
Verschwendung für solche Shifter eine Menge Transistoren zu 
verschwenden.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pico wrote:

> meinst du eine *.inc datei mit sowas?
> .equ jrnz = brne  ;jump relativ not zero

Wenn das so geht...

Ich dachte eher an
.macro jz
     breq @1
.endmacro
aber wahrscheinlich geht auch
#define jz breq

Ich hoffe doch, dass du mit dem Konzept von Macros in Assemblern 
vertraut bist.

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Kaiser

he cool

damit kann man sich ein assambly für avm schreiben, was wie z code
aussieht.

.macro jrz
     breq @1
.endmacro

   ldi   r16,  0           ;einziger hinweiß auf einen avr
   mov   r17,  r16
   or    r16,  r17
   jrz   springe_immer


sieht doch gut aus ...

freude pico

ps die macro's sollten natürlich in einer include datei gekapselt 
werden!

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pico wrote:

> ich verdiene seit 83 mit µp / µc mein geld.

Willst du mir damit erzählen, dass du seit 1983 professionell in 
Assembler programmierst, ohne jemals Macros begegnet zu sein? Respekt!

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein selbst mein erster assamber war ein macro-assambler

gruß pico

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man das war'n spass

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
back to the roots

meime meinung zu avr (als einer der damit seine brötchen verdient)
ich mag ihn! also keinesfalls unbeliebt. er hat wie alle µc's ecken
und kanten aber wenn es um schnelle app's geht ist er spitze!

pico

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm, nichts gegen Dich, liebe(r) pico, aber nach 25 Jahren sollte man 
doch wenigstens wissen, wie man "Assembler" schreibt (v.a., dass es in 
dem Wort nur ein a gibt)... Oder läuft das nach dem Motto "Gestern 
wuste ich noch nich, wie mann Inschenör schraipt unt hoite bin ich 
einen...";-?

SCNR...

Autor: pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich kann's schreiben aber meine tastatur nach 3 bier nicht mehr.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pico wrote:
> ich kann's schreiben aber meine tastatur nach 3 bier nicht mehr.
Oha, Deine Tastatur trinkt Bier?

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bier & PC != gut;

Am nächsten Tag kommt dann der Standardgedanke: ".. was hab' ich mir 
bloß dabei gedacht .."

:-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo M. wrote:
> Bier & PC != gut;

Man kann sich beschwipst an den PC setzen und 10min an dem aktuellen 
Projekt "arbeiten" (natürlich ohne vorher den aktuellen Stand zu 
sichern).

Man kann dann den ganzen nächsten Tag benötigen, um alle gemachten 
Fehler zu finden und wieder auszubauen.


Peter

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo M. wrote:
> Bier & PC != gut;
>
> Am nächsten Tag kommt dann der Standardgedanke: ".. was hab' ich mir
> bloß dabei gedacht .."
>
> :-)
Naja, ich hab schon mal ne Flasche Bier über mein Notebook entleert 
(unabsichtlich, versteht sich...) und dabei Glück gehabt, dass nach 
einer gründlichen Reinigung der Tastatur alles wieder funktionierte. 
Seitdem bin ich auch ein wenig vorsichtiger mit der Kombination 
"Computer + Bier"...

Autor: Hinrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir haben letztes Jahr über 30.000 verbaut, unsere Kunden noch viel 
mehr. Sind schon steile Teile. Was echt nervt sind Lieferzeiten, das 
wird immer anstrengender.

Die Architektur ist topp (gibt es etwas vergleichbar schnelles im 8bit 
Bereich?). Was ich mir wünschen würde, wäre eine "Sync"-Möglichkeit im 
Sinne von "stehenbleiben, bis der Port sich ändert". Mit dem "Skip over 
Jump" hat man leider immer ein paar Taktzyklen Toleranz.

Der Erfolg von Atmel lag damals darin begründet, daß sie mit kleinen 
Bausteinen (z.B. 1200) angefangen und von da aus nach oben gebaut haben.

Heute starten sie mit full-featured Riesenchips, die Module teilweise 
halbfertig (man sehe sich nur mal die AVR32 Erratas an) und lassen die 
potentiellen Kunden jahrlang auf die kleinen Derivate warten...

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so ganz nebenbei da ihr 30.000 Stück pro Jahr verbaut. Kann man solche 
Stückzahlen bei Atmel direkt beziehen oder verdient da immer ein 
Distributor mit?

Autor: Jankey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LG Baut Millionen von LCD Fernsehern mit ATMega48, kommt halt drauf an 
für welche Anwendung.

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In den Lego Mindstorms ist auch ein ATMega48 als Co-Prozessor verbaut:
http://mindstorms.lego.com/Overview/NXTreme.aspx
dann das Hardware Development Kit herunterladen, dot befinden sich die 
Schaltpläne.

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> - die doppelt- oder dreifachbelegung der pin's

Multiplexing kann man bei Controllern mit wenigen Pins und großem 
Funktionsumfang leider nicht verhindern.

> - die teilweise kryptische bezeichnung der 'fuse bit's'

Bei AVR muß ich mich auch ständig durch die Beschreibungen wühlen, um 
herauszufinden, was ich eigentlich setzen muß. Die Tatsache, daß es bei 
PonyProg dann auch noch invertiert ist, vereinfach die Sache nicht 
wirklich.
Kann natürlich auch damit zu tun haben, daß ich mit PICs mehr Erfahrung 
habe als mit AVR.

["breq" vs "jrz"]
Das eine Orientiert sich eher an den Mnemonics von Motorola und das 
andere an Intel.
Ich denke mal, daß es hier wie bei little- und big-endian ist, wo einem 
das "natürlicher" vorkommt, was man als erstes kennengelernt hat. Ich 
persönlich bin beispielsweise mit den Motorola-Mnemonics vertrauter und 
muß bei den Intel-Gegenstücken meist erst überlegen, was gemeint ist.

["ldi" vs "mov"]
Finde ich eigentlich gar nicht schlecht, da es klar macht, daß hier 
wirklich eine andere Instruktion mit anderer Codierung dahinter steckt. 
"mov" wäre natürlich möglich und wird von einigen RISC-Architekturen 
auch gemacht, kann aber auch fehleranfällig sein, wie hier jemand schon 
angemerkt hat.

> Ich vermisse Shifts mit Angabe der Anzahl der Bits

Ich glaube das habe ich hier im Thread auch schon mal bemängelt. 
Irgendwie kommen da Erinnerungen an den 8086 auf, der auch nur um eine 
Position shiften konnte.

> das geht wohl mehr in richtung cisc architektur!

Nicht unbedingt, da es über einen Barrel-Shifter durchaus in einem 
Taktzyklus machbar ist.

> Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei
> CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern
> generell eher selten anzutreffen.

Ich kenne mich jetzt zugegebenermaßen nicht mit der Implementierung 
eines Barrel-Shifters aus, aber der ARM2 hatte meines Wissens auch schon 
einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael König wrote:

> Irgendwie kommen da Erinnerungen an den 8086 auf, der auch nur um eine
> Position shiften konnte.

Über Shiftcount in CL ging auch mehr. Die interne Hardware konnte aber 
nur um eine Position, der Rest lief in Microcode ab. Womit man die 
Maschine schon man ein nettes Weilchen beschäftigen konnte. Und das geht 
zu Lasten der worst case interrupt latency, eine Zahl die sich die 
Hersteller von Controllern gerne gegenseitig um die Ohren hauen.

> einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren.

Ein 8x8 Multiplier ist auch kein Hexenwerk, trotzdem besitzt nur ein 
Teil der AVRs diese Unit.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube nicht, dass Shift über mehrere Bits beim Achtbitter Sinn 
macht, da das Carry nur ein rausgeshiftetes Bit (als Übertrag für 
Rotation ins nächste Byte) auffangen kann.

Ich hätte zwar gerne noch CPSNE (Gegenteil von CPSE) gehabt, und/oder 
T-Bit-Transfer mit dem I/O-Bereich, aber man kann nicht alles haben, der 
Befehlssatz ist endlich (es sind nunmal nur 16 Bit für Befehl incl. 
Parameter da).

Zum ursprünglichen Thema kann ich (wie viele Andere auch) nicht 
beitragen, da ich kein "Profi" bin.

...

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael König wrote:
>> das geht wohl mehr in richtung cisc architektur!
>
> Nicht unbedingt, da es über einen Barrel-Shifter durchaus in einem
> Taktzyklus machbar ist.
>
>> Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei
>> CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern
>> generell eher selten anzutreffen.
>
> Ich kenne mich jetzt zugegebenermaßen nicht mit der Implementierung
> eines Barrel-Shifters aus, aber der ARM2 hatte meines Wissens auch schon
> einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren.

Man bräuchte doch 'nur' 8 Multiplexer (einen pro Ausgabebit) mit jeweils 
7 Eingängen die jeweils mit jedem Bit außer dem 'eigenem' verbunden sind 
(Shift um die Position 0 mach keinen Sinn). Und je nach angelegter 
Auswahl am Multiplexer hätte man einen geeigneten Shift.

Ich denke der meiste Teil der Chipfläche geht bei den größeren Modellen 
eh für Flash und SRAM drauf oder?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Malte __ wrote:

> Man bräuchte doch 'nur' 8 Multiplexer (einen pro Ausgabebit) mit jeweils
> 7 Eingängen die jeweils mit jedem Bit außer dem 'eigenem' verbunden sind

Ein 8:8 Barrelshifter ist für Multibyte-Shifts ziemlich sinnfrei. Da es 
dank vorherrschender Programmierung in C recht oft um 16bit-Shifts geht, 
wäre nur ein 16:8 Barrelshifter wirklich sinnvoll.

Ausserdem dürfte, so implementiert, die Fläche der Muxer selbst nicht 
der Punkt sein. Ich schätze dass dann der grösste Aufwand in der 
Verdrahtung draufgeht, zumal wenn dafür nur wenig Layer zur Verfügung 
stehen. Wird besser, wenn man das in mehreren Stufen macht.

Autor: Jankey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute leute ... es is ein RISC und kein CISC...

solchen "komplexen" funktionen wie ein Barrel werden anderwertig 
zusammengenudelt.

und 8000 Transistoren glaub ich dir ned, weil selbst wenn es 8000 Gates 
wären das auf 0.35um ca. ~1.0mm² kommen

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Wikipedia hatte der ARM2 30000 Transistoren. Das sind ungefähr so 
viele wie bei 8086 und halb so viele wie 68000. Allerdings hatten 8086 
und 68000 teils mehrere Microcode-ROMs, die wesentlich einfacher und 
kompakter strukturiert sind als synthetisierte random logic.

Zum Vergleich: 8080 hatte 6000, Z80 bereits 13000 Transistoren.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Barrel-Shifter passt meiner Meinung nach nicht gut in das
AVR-Konzept:

Wie Andreas Kaiser weiter oben gechrieben hat, ist ein Shift um
mehrere Bits nur dann sinnvoll, wenn die aus dem Register
herausgeshifteten Bits nicht verloren gehen, sondern in ein zweites
Register hineingeshiftet werden. Nur damit können auch Shifts von 16-
und 32-Bit-Variablen realisiert werden.

Ein Barrel-Shifter ist im Vergleich zu Addition, logischen
Bitmanipulationen deutlich komplexer, siehe

  http://en.wikipedia.org/wiki/Barrel_shifter

Die Tinies können keine komplexen Operationen. Ich schätze, sie sind
konsequent auf minimale Chipfläche getrimmt.

In die Megas würde ein Barrel-Shifter eher passen, da hier bspw. auch
ein Multiplizierer Platz findet. Allerdings würde ein Shift mit
16-Bit-Ergebnis architekturbedingt wahrscheinlich 2 Zyklen dauern, da
zwei Ergebnisregister beschrieben werden müssen. Eine Multiplikation
mit 2**n tut ähnliches in 3 Zyklen, wenn man den zusätzlichen Befehl
zum Laden des zweiten Operanden berücksichtigt.

Man würde also relativ viel Chipfläche investieren, um eine der
seltener benötigten Operationen gerade mal einen Zyklus schneller zu
machen.

Der AVR-Befehlssatz ist in meinen Augen schon sehr durchdacht.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:

>  Allerdings würde ein Shift mit
> 16-Bit-Ergebnis architekturbedingt wahrscheinlich 2 Zyklen dauern, da
> zwei Ergebnisregister beschrieben werden müssen.

Das läuft anders. 2 Register rein, eines raus. Ein kompletter 16bit 
Shift sähe dann ungefähr so aus:
   r16 = r17:r16 >> n
   r17 = r17 >> n   (bzw. r1:r16 >> n, wenn r1=0)
Den manchmal vermissten Rotate ohne Carry gibt's dann gratis, mit
   r18 = r18:r18 >> 1

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das läuft anders. 2 Register rein, eines raus.

Stimmt, so herum ist es natürlich gechickter.

Trotzdem bleibt die Frage: Wie oft braucht man einen Shift um mehrere
Stellen? In meinen AVR-Programmen kommt so etwas äußerst selten vor.
Bei Controllern mit größerer Wortbreite schon häufiger, bspw. wenn
sich bei 16- oder 32-Bit-IO-Registern eine Gruppe von Bits, die
zusammen eine Zahl darstellen, in der Mitte des Registers befindet.
Aber bei 8-Bit-IO-Registern geht dies auch mit ein paar LSL und SWAP
ausreichend schnell.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:

> Trotzdem bleibt die Frage: Wie oft braucht man einen Shift um mehrere
> Stellen?

Beispielsweise wenn man CAN IDs als 29-Bit Werte an Funktionen übergibt, 
und sie dort wild zerpflücken und auf die diversen Register eines 
MCP2515 verteilen darf. Und umgekehrt.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Beispielsweise wenn man CAN IDs als 29-Bit Werte an Funktionen übergibt,
> und sie dort wild zerpflücken und auf die diversen Register eines
> MCP2515 verteilen darf. Und umgekehrt.

Anstelle von N-bit-Shifts würde da auch z.B. ein Befehl Sinn machen, der 
die oberen 4 Bits des Source-Registers in den unteren 4 Bits des 
Zielregisters speichert. Dann erledigt man 8-Bit und Vielfache durch 
uminterpretieren der Register (kostenlos), 4 Bits mit einem Befehl, und 
die restlichen max. 2 Bits durch 1-Bit Shifts. Ohne 4-Bit-Shift kommst 
du so auf max. 4 einbit-Shifts (jeweils max. 2 Befehle um Bit durch das 
Carry "rüberzuschieben").

Bleibt die Frage, wieviele CAN IDs du so pro Sekunde verarbeiten willst, 
dass diese (im schimmsten Fall) 8 Befehle pro ID so ins Gewicht fallen. 
Da war der Hintergedanke dann sicher, dass man für diesen (eher 
seltenen) Fall halt einen anderen Controller nimmt.

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider hat da Microchip nicht nach dem Bosch gearbeitet und einige 
Eigenerfindungen gemacht.
Die ID-Register vom Atmel sind 1:1 vom Bosch übernommen.

Und da die Geschwindigkeit vom CAN um etliches langsamer ist als die 
Geschwindigkeit vom AVR bleibt genügend Zeit die ID umzurechnen und 
weiter zu verarbeiten.
Das Andere ist, das man solche Dinge dem C-Compiler überlässt, denn wer 
schreibt 32k Maschinencode in Assembler?
Assembler benutzt man doch nur noch bei ganz kleinen Aufgaben oder wo es 
nicht anders möglich ist wird nur ein kleiner Teil (<5%) in Assembler 
geschrieben.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur die Ruhe, ich beklage mich doch garnicht. Da war bloss die Frage im 
Raum, wozu man grössere Shifts brauchen kann. Ich habe kein Problem 
damit, wenn auf AVRs dann eine Schleife draus wird. Und ich bin nicht 
verrückt genug, sowas in Assembler zu programmieren.

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So einen 4-bit Shifter wie oben mittels SWAP beschrieben funktioniert 
doch auch ganz gut
Beitrag "Re: Atmel ist unter "Profis" nicht gerade beliebt - Warum?"
und den Rest mit normalen 1-bit Shifts

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Laut Wikipedia hatte der ARM2 30000 Transistoren.

Ich werde doch nicht etwa die Anzahl der Transistoren und die Taktrate 
(8MHz) durcheinandergeworfen haben? Muß ich mal zu Hause bei Furber 
nachschlagen...

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Kaiser

>Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu
>implementieren.

>meinst du eine *.inc datei mit sowas?

>.equ jrnz = brne  ;jump relativ not zero
>.equ jrz  = breq  ;jump relativ zero
>.
>.

>gruß pico

.equ    add = 2                 ; 'add' is a keyword (instruction)
.def    r1 = r16                ; 'r1' is a keyword (register)
.def    r0 = r31                ; 'r0' is a keyword (register)
.def    r16 = r24               ; 'r16' is a keyword (register)
.def    add = r2                ; 'add' is a keyword - again 
(instruction)
.def    mov = r29               ; 'mov' is a keyword (instruction)

hey gefunden in der help für
avr studio assembler2

ps: ret 6 fehlt mir immer noch, auch wenn ich daten und rückkehradressen
    auf dem stack (2 getrennte) trenne bedeutes einen einen nicht
    unerheblichen tacktaufwand ; bitte, bitte, sowas in si

pico

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.