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
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.
Uns z.B. Steuerungshersteller. Finden Verwendung in Billigstmodulen wo der 8051er zu langsam ist bzw. schneller dann auch gleich mehr kosten.
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.
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 ^^
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).
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.
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.
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.
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.
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.
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
Hoffentlich gibts fürs STK500 ne Erweiterung für Xmegas's wenns soweit ist.
für die xmegas ist das STK600 vorgesehen, was mir privat aber zu teuer ist...
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.
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
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
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 ^^
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...
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
> sollte Atmel z.B. mal Konkurs gehen, (...)
hmmmm... war ja nur ein Beispiel ;-)
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
@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....
>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.
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)
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 ?
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.
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
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.
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?
@ 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 :-)
>> 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.
@OT @serial.h Schau dir die Libs von Fleury an... http://homepage.hispeed.ch/peterfleury/avr-software.html#libs
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.
>Schau dir die Libs von Fleury an...
Wozu ?
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
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
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.
@ Jörg Wunsch :D ich kenne viele "mit-Elektronik-seine-Brötchen-Verdienende" bei denen die Bezeichnung 'Profi' echt nicht angebracht waere.
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
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
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.
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.
Mehmet Kendi wrote:
> Port C kann beim Atmega8 nur als Input benutzt werden.
Bitte genauer, das kann ich jetzt nicht nachvollziehen.
>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.
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
In der Tat; womit habe ich das nur verwechselt? Tut mir leid für diese falsche Behauptung.
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.
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.
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
> 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
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.
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
> 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.
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.
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
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 :).
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? ;-)
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.)
> 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 :-)
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.
@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.
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!
Stefan May wrote: > Kannst Du mal vergleichen, wie gut/schlecht/überragend der gcc gegenüber > kommerziellen Compilern ist? Compiler zu vergleichen, ist einfach immer mal sehr schwierig. Siehe auch Johan Ekdahl: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=44588 GCC leidet zuweilen darunter, dass der AVR bei den GCC-Entwicklern eine relativ untergeordnete Rolle spielt. Insbesondere gibt es immer noch keinen so weit etablierten Simulator, dass es den GCC-Leuten möglich wäre, Verschlechterungen, die nur die AVR-Plattform betreffen, im Rahmen automatisierter Tests bereits während der laufenden Entwick- lung festzustellen. Daher braucht es immer erst einmal den `round trip' über die Endanwender (die das Ganze eben typischerweise auch erst mit jedem neuen Release von WinAVR testen, da kaum einer von ihnen den Compiler bereits zwischendurch mal selbst baut). Eric Weddingtons erklärtes Ziel ist es, einen Simulator so zu etablieren, dass das AVR-Target bei GCC aus der dritten (,,ferner liefen'') in die zweite Kategorie wandert. Damit würden kritische Bugs bei der Codegenerierung für AVR zum Blocker für ein GCC-Release, und schlechtere Optimierungen durch Compileränderungen zumindest rechtzeitig das Augenmerk der Entwickler finden. Ansonsten ist der GCC, gemessen an seiner Herkunft (Unix-Compiler, der für 32-Bit-CPUs mit von-Neumann-Architektur konzipiert worden ist) alles andere als schlecht für den AVR. Von der Kompaktheit des generierten Codes schneidet er zumindest bei größeren Projekten in der Regel kurz hinter dem IAR auf Platz 2 ab, geschwindigkeitsmäßig kann er (mit -O3) sogar einiges größeren aber deutlich schnelleren Code generieren als IAR. Das Handling des Sourcecodes für Zugriffe auf den Flash-ROM und EEPROM ist auf Grund der von-Neumann-Orientierung mit nur einem einzigen Adressraum umständlicher als bei anderen Compilern, aber das kann man sich normalerweise schnell in ein paar Makros kapseln. Die übrigen Compiler (Imagecraft, Codevision) kenne ich selbst gar nicht, ich sehe deren Stärken eher im Drumrum, also in Codegeneratoren etc., was sie so noch mitbringen. Dafür nehmen sie's zuweilen mit dem C-Standard nicht ganz so genau (siehe Dinge wie PORTB.0, die der Syntax von C zuwider sind und daher weder bei GCC noch bei IAR je zu finden sein werden), und C99 scheinen sie sich allesamt noch gar nicht auf die Fahnen geschrieben zu haben. Jungs, bitte macht für Diskussionen zu diesem Artikel aber einen separaten Thread auf! Bezieht euch auf den Artikel über folgenden Link: Beitrag "Re: Atmel ist unter "Profis" nicht gerade beliebt - Warum?"
@walther >Schau Dir erstmal mal an welche Features andere Assembler bieten und >dann reden wir weiter. Atmel hat ja noch nicht einmal ein automatische >Sprungweitenanpassung. Was meinst du jetzt damit? Benutzt du keine Label? Nimmst du nur absolute Sprungadressen? Mal was davon gehört?:
1 | loop: |
2 | ;macht irgenwas |
3 | ... |
4 | CPSE r0,r1 |
5 | JMP loop |
(Schleite wird so lange durchlaufen bis r0=r1 ist) >Ein Beipsiel sind z.B. die Shift-/Rotataionsbefehle oder ein >fehlender Bit-Test-Befehl Wie bitte? Wie wäre es mit:
1 | BST r0,3 |
2 | BRTS bit3_gesetzt |
3 | BST r0,5 |
4 | BRTC bit5_nicht_gesetzt |
Das einzige was ich mnchmal vermisse ist eine Rotation ohne Carry (welche es im DMG90 und Z80 gibt) bis dann Hauke
>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
Er meint vermutlich eine 8-Bit-Rotation, bei der das rausgeschobene Bit sofort am anderen Ende wieder reingeschoben wird. Bert
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
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.
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
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.
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
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).
yalu wrote: > Von dieser Sorte "überflüssiger", aber > kostenloser Befehle gibt es noch ein paar mehr, z.B. CLR, LSL, ROL, > TST und SBR. Sie schaffen einfach etwas mehr Klarheit im Programmcode, > mehr nicht. "Ein paar" ist aber ne ganz schöne Untertreibung. Schätzungsweise 40% des Befehlssatzes sind solche Pseudo-Befehle, deren Opcode identisch ist mit dem anderer Instruktionen. Dazu zählen (neben den bereits genannten) z.B. die ganzen speziellen Branch-Befehle, die alle auf brbs und brbc beruhen, clr als alternative Schreibweise zu eor des betreffenden Registers mit sich selbst, sbr und cbr , sämtliche Befehle zum Setzen und Löschen eines bestimmten Flags im SREG, die alle auf bset bzw. bclr zurückzuführen sind, wobei das betreffende Bit eben im Befehl bereits drinsteckt usw...
>Von 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.
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.
> -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
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
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.
>Die Behauptung "Atmel bei Profis unbeliebt" ist einfach vollkommener >Quatsch! Genau!! Wir setzen fast ausschliesslich AVRs ein. Hauptsächlich den AT90CAN128.
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).
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 ...
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.
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
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.
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
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.
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ß.
@ 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
> 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.
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.
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.
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.
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.
@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.
> 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
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
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.”
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...
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.
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.
> 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
>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.
>.... 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 ??
@Jürgen Tut mir leid, nur 0 Punkte für Dich.
Er meinte natürlich 0 FEHLERpunkte... Solche "Kunden" kenn ich auch, fliegen allerdings hier wegen Arroganz ziemlich schnell raus.
>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.
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
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.
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^^
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.
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 :)
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€.
AVRs lassen sich generell ohne externe Taktquelle programmieren: über ISP und internen Taktgenerator.
>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.
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 ...).
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, ...)
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.
he he, ich habe noch gar nicht gewusst, das der Benz ein Bastelauto ist. Da ist z.B. der ATmega169 drinnen.
@Peter :
>bin dann auf LPC 23xx umgestiegen.
mein BEILEID .
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?
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?
>@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.
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...
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.
>> 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.
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.
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.
> 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...
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.
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?!
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.
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.
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.
>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.
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
> 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...
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.
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
@ 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....
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.
Hugo Walter wrote: > Bei uns in der Firma (Lichttechnik) werden seit längerem AVRs verbaut, > und das in Stückzahlen > 100000. Wir verwenden beide > Programmiermethoden, ASM und C. Dabei ist meine Persönliche Meinung, > dass der C code von unserem IAR Compiler sehr effektiv umgesetzt wird, > und die ASM schreibweise keine nennenswerten Vorteile mehr bietet. Kann ich zustimmen, was der GCC abliefert, ist so schlecht nicht. Ich schrieb weiter oben: > Und in die kleinen Controller (<= 4kB) kommt auch nichts anderes > rein. Der Defaultcode, der bei C grundsätzlich mit eingebunden wird, > ist mir für die kleinen Controller zu groß. Eine Auffassung, die wohl dem Umstand zuzuschreiben ist, daß ich in meiner Unerfahrenheit und aus Bequemlichkeit bei ersten Versuchen wahllos Zeug aus den mitgelieferten Libs eingebunden habe. Das frißt natürlich Speicher. Also gerade nochmal was einfaches (LED-Blinker) mit einem ATTiny13 probiert und nur das absolut notwendigste eingebunden. Ergebnis: 80 Bytes will der GCC immer haben, das Blinkprogramm sind dann nochmal 30 Bytes. Da kann man sich nicht beklagen. Schaue ich mir das generierte Ergebnis an, von Hand kann man das auch kaum besser:
1 | // Testdatei
|
2 | // CPU = ATTiny13
|
3 | #include <avr/io.h> |
4 | #include <util/delay.h> |
5 | |
6 | #define LEDBIT 4
|
7 | |
8 | main (void) |
9 | {
|
10 | DDRB = 0x10; |
11 | PORTB = 0xFF; |
12 | for (;;) |
13 | {
|
14 | _delay_ms(200); |
15 | PORTB |= (1 << LEDBIT); /* setzt Bit 4 an PortB auf 1 */ |
16 | _delay_ms(200); |
17 | PORTB &= ~(1 << LEDBIT); /* loescht Bit 4 an PortB */ |
18 | }
|
19 | return (0); |
20 | }
|
Und das wird daraus:
1 | 0000004a <main>: |
2 | |
3 | #define LEDBIT 4 |
4 | |
5 | main (void) |
6 | { |
7 | 4a: 80 e1 ldi r24, 0x10 ; 16 |
8 | 4c: 87 bb out 0x17, r24 ; 23 |
9 | |
10 | DDRB = 0x10; |
11 | PORTB = 0xFF; |
12 | 4e: 8f ef ldi r24, 0xFF ; 255 |
13 | 50: 88 bb out 0x18, r24 ; 24 |
14 | 52: e0 e6 ldi r30, 0x60 ; 96 |
15 | 54: fa ee ldi r31, 0xEA ; 234 |
16 | */ |
17 | void |
18 | _delay_loop_2(uint16_t __count) |
19 | { |
20 | __asm__ volatile ( |
21 | 56: 8e 2f mov r24, r30 |
22 | 58: 9f 2f mov r25, r31 |
23 | 5a: 01 97 sbiw r24, 0x01 ; 1 |
24 | 5c: f1 f7 brne .-4 ; 0x5a <main+0x10> |
25 | for (;;) |
26 | { |
27 | _delay_ms(200); |
28 | PORTB |= (1 << LEDBIT); /* setzt Bit 4 an PortB auf 1 */ |
29 | 5e: c4 9a sbi 0x18, 4 ; 24 |
30 | */ |
31 | void |
32 | _delay_loop_2(uint16_t __count) |
33 | { |
34 | __asm__ volatile ( |
35 | 60: 8e 2f mov r24, r30 |
36 | 62: 9f 2f mov r25, r31 |
37 | 64: 01 97 sbiw r24, 0x01 ; 1 |
38 | 66: f1 f7 brne .-4 ; 0x64 <main+0x1a> |
39 | _delay_ms(200); |
40 | PORTB &= ~(1 << LEDBIT); /* loescht Bit 4 an PortB */ |
41 | 68: c4 98 cbi 0x18, 4 ; 24 |
42 | 6a: f5 cf rjmp .-22 ; 0x56 <main+0xc> |
43 | |
44 | 0000006c <_exit>: |
45 | 6c: ff cf rjmp .-2 ; 0x6c <_exit> |
Alles unter 004A ist das Minimum, was der GCC immer haben will, die Interrupt-Tabelle und eine Speicherkopier- und Löschroutine Wird wohl Zeit, daß ich mich doch mal intensiver mit dem GCC beschäftige. Gruß Jadeclaw. PS: Ein Blinker geht natürlich auch wesentlich kürzer mit Timer im CTC-Mode, aber ich wollte Compileroutput sehen.
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.
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.
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.
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...
> @ 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...
>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.
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.
>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 ?
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.
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
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
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.
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
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.
chorus wrote: > Ein Mikrocontroller ist aber auch ein physikalischer Gegenstand. Er kann > noch so schön zu programmieren sein, wenn er aus physikalischen Gründen > einen Ausfall hat, sei es Temperatur, EMV oder sonst irgend etwas, sind > die Vorteile einer solchen Architektur schnell hinüber. > > Und genau hier würde mich die Erfahrung der Leute interessieren: Wie > zuverlässig sind die AVR's ? Es sind 4 Regelgeräte in unserem Haus mit sehr guter Beschaltung die schon seit 1999 ständig am Stromnetz hängen und durchgehend bis heute laufen. Die Regelung wurde auch von einer Prüfstelle gegen EMV Geprüft. http://www.tuev.at/start/browse/Webseiten/TUV%20Austria%20Holding/Dienstleistungen/Nachrichten-%20Informationstechnik%20und%20EMV/EMV%20RL%2089_3_36_EWG%20 Die Regelungen sind seit dieser Zeit im Dauereinsatz und haben weder einen Absturz, Reset oder sonstige Fehlsteuerungen oder Ausfälle. Hinzu kommt, das nur einige ausgetauscht wurden, wo Flüssigkeiten oder mechanische Beschädigungen aufzuweisen waren. Ausfälle beim EEPROM haben wir nicht feststellen können. Einziges auf das zu Achten ist, ist das nicht ins EEPROM geschrieben wird wenn die Spannung unter einen bestimmten Pegel sinkt, wenn man zu oft beschreibt und die 100000 überschreitet, oder bei den älteren Modellen die EEPROM Stelle 0.
>Du hast nen externen Interrupt zum Tasten Abfragen
Nee, war'n normaler Portpin, per Polling abgefragt. ;)
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
Gottfried S. wrote: > Ausfälle beim EEPROM haben wir nicht feststellen können. Welcher AVR? BOD enabled oder externer Reset-IC? Peter
@ 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. ;)
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
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
> 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.....
ja MAXIM trägt die rote Laterne. Da muss ich zustimmen!
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.
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.
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.
> 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.
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
>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.
@ Roman Mittermayr please stop SPAMMING !!
hehe :-) Immerhin verpack ich es in gute Tipps. Oder nicht? Sorry.
>Immerhin verpack ich es in gute Tipps. Oder nicht?
nein, nicht.
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).
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.
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.
Weil die "Profis" kein´ Plan von der Materie haben ;-)
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.
>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...
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.
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.
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...
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.
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
>Da stellt sich doch eigentlich die Frage, was "Profis" sind. >Sind das unbedingt diejennigen, die eine hohe Stückzahl verbauen? Um das von Jörg gesagt noch zu ergänzen: Ein Profi ist der, der sein Geld damit verdient, unabhängig von der Stückzahl. Manche Profis entwickeln Geräte für Großserien, andere Einzelstücke oder Kleinserien (vielleicht nur 10 Stück), je nach Anwendung und Kundenwunsch.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.