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.
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
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.
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
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.
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.
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.
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.
>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
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.
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
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.
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 ??
>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€.
>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, ...)
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.
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
@ 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.....
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.
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.
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.
Rufus t. Firefly wrote:
> http://www.ccc.de/hackabike/index_de.html
Schade, dass sie bei eigentlich (immerhin durch den CCC bescheinigter)
guter Intelligenz so trottelig waren, die Lockbits nicht zu setzen.
Die Fragestellung hier im Thread ist durch das Wort "Profi" eigentlich
viel zu allgemein. Man hätte schon fast schreiben können "Atmel ist
unter Menschen nicht gerade beliebt".
Die Fragestellung, die mich viel mehr interessiert ist: Wo sind die
typischen Einsatzbereiche für AVR's und wo werdern sie eher gemieden?
Da scheint sich herauszukristallisieren, dass im Automobilbereich die
Teile eher gemieden werden. Ebenso in Bereichen, wo langfristige
Verträge gemacht werden und große Stückzahlen der Controller immer am
Markt verfügbar sein müssen.
In einer Firma, wo z.B. 1000 Geräte im Jahr mit AVR gebaut werden, ist
es überhaupt kein Problem, Engpässe von 6-12 Monaten durch Lagerhaltung
zu überbrücken. Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein
Chip nicht mehr verfügbar ist, oft kein Problem darstellen. Zumal die
Nachfolgetypen bisher recht kompatibel waren.
Das große Horrorszenario wäre, wenn AVR mal pleite geht und man auf
völlig andere Chips umsteigen müsste. Aber das wird wohl nicht
passieren: Die Firma würde übernommen werden und der Markt, der ja da
ist, weiterbedient.
Ob es tatsächlich Vorsprung war, oder nur gutes Marketing?
Vor vielen Jahren wurden mir persönlich die MCS51er zu langsam und zu
aufwendig. Für jeden Hersteller eines Derivats dieser Klasse musste man
einen eigenen Programmer bauen oder kaufen. Motorola wuselte parallel
mit seinen HC Typen herum und hatte, wie zuvor die MCS auch das Problem
mit einem externen Latch und ROM. Dazu kam, dass man vom Z80 zum MCS
Bustechnisch nicht so weit umdenken musste und PullUps waren mir schon
immer lieber als PullDowns. (Motorola hatte doch ein Active-High
Chip-Select, oder?)
Aufgrund diverser inkompatibilitäten zog also auch das Argument
Second-Source innerhalb der MCS51er nicht mehr wirklich, wenn man auch
nur kleine Verbesserungen mitnehmen wollte. Da kochte jeder Hersteller
sein eigenes Süppchen. Wollte man zudem mehr Geschwindigkeit, dann gab
es mit Dallas auch nur einen einzigen Hersteller und einen unannehmbaren
Preis für Einzelstücke.
PIC verlangte für jeden Chip eine eigene IDE, totaler Murks.
So bin ich, weil preiswert und All-Inclusive auf den AT90S8515 gekommen.
Irgendwie sah die Idee dahinter sehr einfach und einladend aus. RISC,
Single-Cycle Instructions... Ein Programmer erschlug eine ganze Serie
Chips unterschiedlicher Größe, eine IDE für alle Chips. Damals habe ich
alles noch in Assembler gemacht, 150 Befehle hatte man an zwei
Nachmittagen drauf. Eine große Erleichtung war auch das Errechnen von
Timings bei der Hardwareemulation in Software. Serielle, IR, SCSI,
diverse perallel und serielle Bussysteme, was hab ich nicht alles
emuliert...
Es war sicherlich eine Gefühlsentscheidung, weil das Konzept einfach
simpel, offen und durchgängig erschien.
Ob es das Marketing war, oder eben der klitzekleine Konzeptvorsprung
gegenüber anderen Systemen, ich kann es heute nicht mehr sagen.
Letztendlich zählt aber, dass mich ATMEL bis heute nicht ein einziges
mal im Stich gelassen hat, es gab immer einen Chip der passte und jede
Support-Anfrage, egal ob privat oder Beruflich, wurde kurzfristig und
zufriedenstellend beantwortet.
Natürlich sind die ehemaligen Konkurrenten auch gewachsen. PIC verfügt
inzwischen über eine IDE für alle, und viele andere Hersteller sind mit
neuen Designs und Ideen auf dem Markt gekommen.
Bislang konnte mich keine Aufgabe dazu bringen etwas anderes als einen
AVR einzusetzen obwohl ich fast jede Neuentwicklung in diesem Bereich
aufmerksam verfolge.
Vielleicht ist es auch anders herum gewesen? Zufor schrieb schon jemand,
dass die alten Systeme in den Köpfen der Entwickler zu stark verankert
sind. Ich kenne Sprüche wie "Wir entwickeln seid 30 Jahren für den Z80
und werden das auch in 20 Jahren noch machen". Vielleicht hatte ATMEL
bei mir Glück, weil ich damals gerade erst auf dem Sprung vom
Hobby-Bastler zum Entwickler war und sowohl Zeit als auch Neugier genug
hatte um einen großen Schnitt zwischen MCS51 und 'Etwas Neuem' zu
machen.
Gruß, Astralix
Ulrich P. wrote:
> PIC verlangte für jeden Chip eine eigene IDE, totaler Murks.
Nur so aus Neugier, kannst Du das etwas erläutern?
War das in der Zeit von MPLAB? Unter DOS?
Danke
Ich möchte Ulrich P. weitgehend zustimmen, obwohl bei Motorola alle CS
immer low-aktiv waren :-)
Der erste Typ AT90S1200 hob sich nur wenig von den damaligen PICs ab:
kein RAM, kein Stack. Aber mit den zum 8051 DIL40 und 2051 DIL20
kompatiblen Typen 8515 und 2313 konnte man dann auf einfache Weise seine
vorhandene 8051-Schaltung damit testen, zunächst in Assembler, der nicht
viel konnte, aber den es kostenlos gab. Der Geschwindigkeitsunterschied
war wie Tag zu Nacht.
Und da man wiederholt umprogrammieren konnte, wollte ich den 8051 auch
garnicht mehr haben. Alles in einem Gehäuse war einfach zu praktisch.
Profi hin - Profi her, mit den Atmels kann man gut seine Brötchen
verdienen.
"Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein
Chip nicht mehr verfügbar ist, oft kein Problem darstellen."
Das halte ich für eine seeeehr optimistische Sichtweise.
In der Realität ist nach 10 Jahren der Entwickler an einem ganz anderen
Projekt, anderen Abteilung oder einer anderen Firma. Die Tools
produzieren plötzlich ganz anderen Code und können mit der Source nichts
mehr anfangen. Wenn sie überhaupt noch verfügbar sind.
In der Regel bedeutet so etwas ein Neudesign. Und das dann evtl. für ein
Produkt, für das nur noch Ersatzstückzahlen benötigt werden.
Da setzt man dann eben lieber Hersteller ein, die noch Bausteine von vor
10 Jahren im Programm haben. Die haben dann schon mal bewiesen, dass sie
langfristig liefern.
Und letzlich sind die Vorteile der verschiedenen Architekturen nicht so
gravierend, alle kochen mit Wasser und kein Controller ist wirklich
herausragend besser.
Gruss
Axel
Gast wrote:
>Aber mit den zum 8051 DIL40 und 2051 DIL20 kompatiblen Typen 8515 und >2313
konnte man dann auf einfache Weise seine vorhandene 8051-Schaltung >damit testen,
zunächst in Assembler, der nicht viel konnte, aber den es >kostenlos gab.
Bitte erwähne aber auch, dass der Reset-Pegel unterschiedlich ist. Also
nicht ohne Umbauten auf der gleichen leiterplatte einsetzbar.
Desweiteren hat Atmel bisher für jeden abgekündigten Baustein einen
funktionskompatiblen und besser ausgestatteten Ersatz geschaffen, sodass
nach dem (leider neu anzupassenden) Bearbeiten des Quellcodes durchaus
die Produktion weiter gehen konnte.
Ich bin selber einige Male in die Falle des Kompatibilitätsbits des M103
gelaufen wie viele hier im Forum. Wenn das konsequent durchgezogen wäre
á la Bit gesetzt, IC arbeitet mit der alten ID (HEX-Dump unbearbeitet),
Bit gelöscht, alle neuen Features stehen einem zur Verfügung (mit neuem
Kompilat), das wäre sinnig gewesen.
MW
>Bitte erwähne aber auch, dass der Reset-Pegel unterschiedlich ist. Also>nicht ohne Umbauten auf der gleichen leiterplatte einsetzbar.
Gut, eine Änderung war aber sowieso notwendig, da man ISP nutzen wollte.
Aber alle Portpins konnten bleiben und die ser. Schnittstelle
unterstützte auch den Multiprozessormodus vom 8051. Der Aufwand zum
Probieren war somit minimal.
Axel wrote:
> "Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein> Chip nicht mehr verfügbar ist, oft kein Problem darstellen.">> Das halte ich für eine seeeehr optimistische Sichtweise.>
Nein, bis auf wenige Ausnahmen läuft es doch so ab:
Kunde braucht einen Ersatz für etwas, dass er vor vielen Jahren bei
irgendwem gekauft hat, der schon längst was anderes macht oder pleite
ist. Die Bauteile sind kängst nicht mehr verfügbar. Im Grunde war der
Kunde eh nie so ganz zufrieden und will im Zuge der Aufrüstung gleich
das ein oder andere Feature mehr haben.
Meine letzten Projekte fingen alle damit an, dass nur eine SPS ersetzt
werden sollte durch eine andere und dann das ganze System bitte weiter
5x aufbauen. Es endete damit, dass das nach Einsammeln aller Wünsche
feststand, dass diese unter Einsatz einer SPS icht erfüllt werden
könnten. Also wurde ein Prototyp auf Basis einer vollen Eigenentwicklung
mit AVR und SAM7 erstellt, der wiederum so gut gefiel, dass gleich 7
weitere Systeme beauftragt wurden.
Bei einem anderen vor 15 Jahren erstmalig ausgelieferten Gerät steht nun
ein Ersatz an, da auch hier die Bauteile nicht mehr lieferbar oder
unbezahlbar sind. Da inzwischen ein grafikfähiges Display, SD-Card und
USB unverzichtbar sind, wurde aus einem 98S8151 ein SAM7.
Letztendlich muss man dem Kunden klar machen, dass er, wenn er mehr
Leistung und Features haben will auch etwas Gedult und Kleingeld
investieren muss um dann weitere 10..15 Jahre zu überleben.
Natürlich legt man sich auch als kleine Bude ein wenig Reserven auf
Lager. Dadurch, dass man aber seine Entwicklungen auf einige Typen
einschränkt, relativiert sich diese Lagerhaltung aber. Es ist bei
Kleinserien schon mal billiger einen ATmega64 einzusetzen, wenn man
diesen schon in drei anderen Projekten verwendet, als einen ATmega16,
den man speziell nur für ein Board einsetzt und den man dann auch auf
Halde legen muss um irgendwelche 10-Jahres Verträge einzuhalten.
> In der Realität ist nach 10 Jahren der Entwickler an einem ganz anderen> Projekt, anderen Abteilung oder einer anderen Firma. Die Tools> produzieren plötzlich ganz anderen Code und können mit der Source nichts> mehr anfangen. Wenn sie überhaupt noch verfügbar sind.>
Das ist sicherlich in besonderen Projekten ein Problem. Andererseits ist
es aber auch eine Frage der Disziplin. Wenn man jedem Projekt eine
Datensicherung mit ihrem Letzten Stand gewährt und auch Datenblätter und
Compiler dort hinzufügt, kann ein Stand schnell wieder hergestellt
werden.
Andererseits muss man Prioritäten setzen. Wenn ich Zulieferer für die
Deutsche Bahn oder Automobilindustrie bin oder nach Avionic Normen
Arbeiten muss, dann ist das sicherlich eine aufwendige Sache.
Aber in fast allen anderen Bereichen ist es eine Frage des
verkäuferischen Geschicks den Kunden von einem Benefit bei einer
Plattformumstellung zu überzeugen. Und ich verstehe dabei nicht, ihn
anzulügen um seine eigenen Versagenskosten wegen fehlender
Datensicherungen zu decken.
> Da setzt man dann eben lieber Hersteller ein, die noch Bausteine von vor> 10 Jahren im Programm haben. Die haben dann schon mal bewiesen, dass sie> langfristig liefern.>
Wie gesagt, dass ist eine Fall zu Fall Entscheidung. So pauschal, wie Du
das darstellst, sehe ich das bei weitem nicht. Technischer Stillstand
tut weder dem Lieferanten noch dem Kunden gut.
> Und letzlich sind die Vorteile der verschiedenen Architekturen nicht so> gravierend, alle kochen mit Wasser und kein Controller ist wirklich> herausragend besser.>
Da kann ich allerdings nur zustimmen. Im Grunde muss man entscheiden, ob
eine neue Plattform durch ihre speziellen Features mehr Zeit einspart
als für ihre Einarbeitung erforderlich ist. Im Gegenzug muss man auch
betrachten, ob diese Ersparnis immer noch gilt, wenn man dieses
spezielle Feature mit erhöhtem Aufwand auf einer bekannten Plattform
emuliert.
@GAST
> Ich möchte Ulrich P. weitgehend zustimmen, obwohl bei Motorola alle CS> immer low-aktiv waren :-)
War es nicht so, dass Motorola dieses High-Aktive E(nable) Signal hatte?
Zugegeben, ist zu lange her.
@Severino
> Nur so aus Neugier, kannst Du das etwas erläutern?> War das in der Zeit von MPLAB? Unter DOS?
Das kann gut sein, ich habe mit den MCS51ern und später dann mit den
AVRs schon gearbeitet, als Windows noch in den Versionen 3.x und kleiner
existierte. Auch der AVR Assembler war eine reine DOS-Applikation. Hei,
wie die Zeit vergeht...
Gruß, Astralix
Ulrich P. wrote:
> @Severino>> Nur so aus Neugier, kannst Du das etwas erläutern?>> War das in der Zeit von MPLAB? Unter DOS?> Das kann gut sein, ich habe mit den MCS51ern und später dann mit den> AVRs schon gearbeitet, als Windows noch in den Versionen 3.x und kleiner> existierte. Auch der AVR Assembler war eine reine DOS-Applikation. Hei,> wie die Zeit vergeht...>
Meinte natürlich " in der Zeit voR MPLAB...".
Und ich habe unter DOS Z80-Programme entwickelt, und Windows 3.x
startete man nur für bestimmte Anwendungen, und die Zeit vergeht auch
für mich...
Aber trotzdem: Welche PIC-Typen brauchten eine gesonderte IDE?
Jörg Wunsch wrote:
> Das ist einfach: "Profi" ist die Abkürzung von "professionell"
Ich ging bisher immer davon aus, dass "Profi" von "provisorisch" kommt
;-)
Kann ich nur bestätigen. Bei mir zu Hause laufen fast nur provisorische
"fliegende" Aufbauten. Beim Portieren dieser zu entgültigen
Gerätschaften schleicht sich immer irgendwo ein Fehler ein. Inzwischen
versuch ich's gar nicht mehr, meine fliegenden Aufbauten verschwinden zu
lassen.
war lange nicht hier, deshalb habe ich in dem 'alten' zeug rumgekramt.
zu meiner person : ich verdiene seit 83 mit µp / µc mein geld.
bin über z8 (bockiges mißtvieh) über z80 und pic bei avr gelandet.
meine meinung zu avr:
was mir grfällt:
- simpler befehlssatz (glaube, so um die 130, wovon ich max. 40% nutze)
- schnell wie der blitz
- sehr, sehr, sehr , ... guter adc
- verfügbarkeit rel. großer µc'c im dil gehäuse (für prototypen)
was mir nicht gefällt:
- die doppelt- oder dreifachbelegung der pin's
- die teilweise kryptische bezeichnung der 'fuse bit's'
- und das schlimmste, die assembler syntax (die namen der
bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es
gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich
verständlicher, weil sie sich direkt auf ein flag bezieht.
warum ldi , lade register mit konstante und nicht mov, der compiller
sollte doch alleine zwichen einem register und einer konstanten
unterscheiden können? .......
wenn das mir einer erklären könnte wäre ich dankbar.
gruß
pico
@pico:
Nunja, wer von der z80-Seite kommt, muß sich natürlich umgewöhnen, die
Bezeichnungen sind verständlich, wenn man sich ein paar Millimeter von
der Hardware löst, z.B.:
breq = Branch if equal --> Verzweige wenn gleich. Jump Relative Zero
trifft es zwar auch, breq paßt aber perfekt, wenn man einfach nur am
Ergebnis interessiert ist.
LDI = LoaD Immediate --> Lade Wert direkt ins Register. Ist eigentlich
auch verständlicher, denn durch das LDI weiß ich, der dabeigefügte Wert
geht direkt ins Register. Natürlich könnte man alle
Speicher-/Registerladeanweisungen mit 'MOV' bezeichnen, aber mit
STI/STS/LDI/LDS/MOV separat sehe ich im Assemblertext direkt, woher die
Daten kommen und wohin sie geladen werden. Natürlich wäre ein Assembler
in der Lage, anhand kryptischer Zeichen und unterschiedlicher Klammern
bei der Wertangabe selbst zu entscheiden, wo was hingeschoben wird, so
wie es aber beim AVR-ASM gemacht wird, ist es aber merklich besser
lesbar. Und mir persönlich auch lieber.
Ich habe übrigens auch schon verschiedenste Architekturen hinter mir,
unter anderem Z80/8085, R6502, 6800/1/2, 8048, 8086. Und ehrlich gesagt,
die AVR-Controller sagen mir, was Assemblersprache und Architektur
anbelangt, noch am ehesten zu. Hätte ich bei der Entwicklung was zu
sagen gehabt, wären ein paar zusätzliche Befehle mit hineingekommen:
z.B. ein Add Immediate und ein Decimal Adjust, der BCD-Operationen
merklich vereinfacht. Und der Stack beim AT90S1200 und den anderen
RAM-losen Teilen hätte auch ein paar Ebenen mehr gehabt.
Gegen die Doppelt-, Drei-, Vierfachbelegung ist leider kein Kraut
gewachsen, die Anzahl der Anschlüsse ist nunmal begrenzt. Und die
Benutzer der Chips wollen nunmal alle möglichen Funktionen mit
drinhaben, da muß man sich entscheiden, was man hinterher braucht und
ggfs. langsame Peripherie seriell anbinden, will man nicht in jedes
kleine Gerät ein 100pin-Monster einsetzen. Nur das ist ein generelles
Problem aller modernen Controller-Architekturen und eben kein originäres
AVR-Problem.
Gruß
Jadeclaw.
@Jadeclaw
.... ,dann sollte avr das z-flag im sreg in in e-flag umtaufen und
verbieten das logische opp's das e-flag beeinflussen! für mich
wäre dann mämlich ein konstukt von ....
ldi r16, 0b00000001
or i r16, 0b00000001
breq xyz
... nicht mehr lesbar.
gruß pico
pico wrote:
> was mir nicht gefällt:>> - die doppelt- oder dreifachbelegung der pin's
Das läßt sich kaum umgehen.
Dagegen ist die Pinzuordnung bei den Silabs 8051 ne totale Katastophe.
Sobald man einen Pin zuweist, verschieben sich die Funktionen aller
nachfolgenden Pins nach hinten.
Man muß also schon vor dem Layout ganz genau wissen, welche
Spezialfunktionen man benötigt. Danach ist ein Wechsel unmöglich.
> warum ldi , lade register mit konstante und nicht mov, der compiller> sollte doch alleine zwichen einem register und einer konstanten> unterscheiden können? .......
Naja, beim 8051 wird gerne mal das "#" vergessen bei Konstanten und der
Code nimmt es als Adresse. Und man sucht ewig den Fehler.
Etwas gewöhnungsbedürftig ist es allerdings, statt 3 Ladebefehlen (MOV,
MOVC, MOVX) nun 15 Befehle zu benötigen (MOV, MOVW, LPM, SPM, IN, OUT,
LD, ST, BST, BLD, LDI, LDD, LDS, STD, STS).
Peter
pico wrote:
> was mir nicht gefällt:>> - die doppelt- oder dreifachbelegung der pin's
Jupp, is bissi gefährlich, insbesondere mit dem SPI-Zeuchs. Ist ja auch
eine oft genug angesprochene Stolperfalle, aber wenn mans weiß, ists
kein Thema mehr.
> - und das schlimmste, die assembler syntax (die namen der> bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es> gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich> verständlicher, weil sie sich direkt auf ein flag bezieht.
Naja, breq hat vermutlich seinen Namen von der Vergleicherei. Die
wiederum ist aber auch nur eine Subtraktion und das Steuerwerk setzt im
Statusregister das Nullbit automatisch immer dann, wenn irgendwo Null
bei rauskommt. Deshalb kann man auch z.B. nach einem LSR/LSL mit breq
weiterprüfen.
> warum ldi , lade register mit konstante und nicht mov, der compiller> sollte doch alleine zwichen einem register und einer konstanten> unterscheiden können? .......> wenn das mir einer erklären könnte wäre ich dankbar.
Jupp, das kann dir einer erklären^^
Ganz verallgemeinert und banal: Ein ASSEMBLER ist kein COMPILER. Der
Compiler erzeugt aus Hochsprachenquelltext (C, Basic etc.) einen
Assemblerquelltext. Und der Assembler übersetzt den Assemblerquelltext
in Maschinensprache. Irgendwo ist es ja der Sinn des Assemblers, eben
gerade keine automatische Rumersetzerei zu machen, ich will ja genau
das als Maschinencode erhalten, was ich als Assemblerquelltext
reinschreibe.
@Jadeclaw
>Add Immediate und ein Decimal Adjust ....
die befehle vermisse ich nicht so, da subi mit dem zweiercompliment
den addi befehl ersetzt.
aber einen der wirklich geschwindigkeit bringen würde.
nämlich ret 6 -> vergiß die letzten 6 byte auf dem stack und kehre
zurück.
folgender hintergrund:
manchmal ergibt sich in der sub, dass eine rekonstruktion der register
keinen sinn mehr macht. aber ich muß mich mit pop's zurückhangeln, das
kostet ordentlich zeit! ich würde nicht in assembler programmieren, wenn
es bei mir nicht selten um einen einstelligen µs-bereich gehen würde.
da hat man unter umständen nur 20-50 takte (befehle) zeit zum reagieren.
gruß pico
pico wrote:
> folgender hintergrund:>> manchmal ergibt sich in der sub, dass eine rekonstruktion der register> keinen sinn mehr macht. aber ich muß mich mit pop's zurückhangeln, das> kostet ordentlich zeit! ich würde nicht in assembler programmieren, wenn> es bei mir nicht selten um einen einstelligen µs-bereich gehen würde.> da hat man unter umständen nur 20-50 takte (befehle) zeit zum reagieren.
Beim IAR-Compiler werden 2 Stacks konfiguriert, einen RSTACK und ein
CSTACK.
Der RSTACK ist nur für die Rücksprungadressen und der CSTACK für die
Registerspeicherung.
Der CSTACK wird mittels Y Register realisiert:
ST -Y,Rr <-- wie PUSH
LD Rd,Y+ <-- wie POP
Werden Register nicht benötigt nach Funktionsaufrufen so kann das Y
Register einfach manipuliert werden mittels ADIW oder SBIW
@Gottfried S.
das ist ja genial, auf die idee bin ich nach über 20
jähriger berufserfahrung noch nicht gekommen. einfach mit 2 stack's
arbeiten. daten und rücksprungadressen sauber trennen.
danke pico (das kommt von herzen)
Ich vermisse Shifts mit Angabe der Anzahl der Bits, also sowas: LSR r0,3
um 3 Bits rauszuschieben. Das würde so manchen Code ziemlich
beschleunigen.
Und dann verstehe ich nicht warum nicht alle AVRs, egal ob Tiny oder
Mega, die exakt gleiche ALU und somit auch alle die gleichen Befehle
haben. Es wäre schon vorteilhaft die MUL Opcodes auch auf den Tinys zu
haben. Das kann nur mit dem Marketing zu tun haben.
Gruß Hagen
> Es wäre schon vorteilhaft die MUL Opcodes auch auf den Tinys zu haben.
Der Tiny hat aber nunmal keinen Hardware-Multiplier, dadurch wird er ja
so billig. Was würde dir der Opcode ohne Hardware-Multiplier bringen?
Oder redest du von einer Software-Emulation des Befehls?
pico wrote:
> - und das schlimmste, die assembler syntax (die namen der> bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es> gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich> verständlicher, weil sie sich direkt auf ein flag bezieht.
In den meisten Architekturen gibt es keine direkte 1:1 Beziehung
zwischen den bedingten Sprungbefehlen und den Flags. Viele Vergleiche
mit Vorzeichen fallen darunter, weil darin teilweise bis zu 3
verschiedene Flags zueinander in Beziehung gesetzt werden (sowas wie
S^V|Z).
Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu
implementieren.
> warum ldi , lade register mit konstante und nicht mov, der compiller> sollte doch alleine zwichen einem register und einer konstanten> unterscheiden können? .......
Könnte man so machen. Allerdings neigt Atmel offenbar dazu,
verschiedenen Maschinenbefehlen verschiedene Mnemonics angedeien zu
lassen. Das hat auch ein bischen was mit CISC vs RISC zu tun. Bei CISCs
ist es oft so, dass etliche unterschiedlich codierte Befehle den
gleichen Namen haben, bei RISCs findet man öfter getrennte Namen für
verschiedene Maschinenbefehle.
Das Extrem davon wäre dann beispielsweise MAXQ2000. Da gibt's eigentlich
nur noch einen einzigen Befehl, MOV. Der Rest ergibt sich aus diversen
Seitenffekten der verwendeten Adressen.
pico wrote:
> das geht wohl mehr in richtung cisc architektur!
Als interne Microcode-Schleife realisiert passen sie nicht ins Konzept
der AVRs. Und würde die Interrupt-Latenzzeit kräftig erhöhen.
Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei
CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern
generell eher selten anzutreffen. Zumal der einzige wirklich sinnvolle
Shifter bei AVR ein 16=>8 Shifter wäre, denn nur dann liesse sich der in
C-Compilern wirklich nützlich anwenden.
@Andreas Kaiser
>Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu>implementieren.
meinst du eine *.inc datei mit sowas?
.equ jrnz = brne ;jump relativ not zero
.equ jrz = breq ;jump relativ zero
.
.
.
.
.
.
gruß pico
4-Bit Shifter:
SWAP Rd
ANDI Rd,0xf0 ; Entspricht LSR Rd,4
Insgesamt 2 Taktzyklen
SWAP Rd
ANDI Rd, 0x0f ; Entspricht LSL Rd,4
Da diese Befehle sehr selten benötigt werden, wäre es bestimmt eine
Verschwendung für solche Shifter eine Menge Transistoren zu
verschwenden.
@Andreas Kaiser
he cool
damit kann man sich ein assambly für avm schreiben, was wie z code
aussieht.
.macro jrz
breq @1
.endmacro
ldi r16, 0 ;einziger hinweiß auf einen avr
mov r17, r16
or r16, r17
jrz springe_immer
sieht doch gut aus ...
freude pico
ps die macro's sollten natürlich in einer include datei gekapselt
werden!
pico wrote:
> ich verdiene seit 83 mit µp / µc mein geld.
Willst du mir damit erzählen, dass du seit 1983 professionell in
Assembler programmierst, ohne jemals Macros begegnet zu sein? Respekt!
back to the roots
meime meinung zu avr (als einer der damit seine brötchen verdient)
ich mag ihn! also keinesfalls unbeliebt. er hat wie alle µc's ecken
und kanten aber wenn es um schnelle app's geht ist er spitze!
pico
Hmmm, nichts gegen Dich, liebe(r) pico, aber nach 25 Jahren sollte man
doch wenigstens wissen, wie man "Assembler" schreibt (v.a., dass es in
dem Wort nur ein a gibt)... Oder läuft das nach dem Motto "Gestern
wuste ich noch nich, wie mann Inschenör schraipt unt hoite bin ich
einen...";-?
SCNR...
Thilo M. wrote:
> Bier & PC != gut;
Man kann sich beschwipst an den PC setzen und 10min an dem aktuellen
Projekt "arbeiten" (natürlich ohne vorher den aktuellen Stand zu
sichern).
Man kann dann den ganzen nächsten Tag benötigen, um alle gemachten
Fehler zu finden und wieder auszubauen.
Peter
Thilo M. wrote:
> Bier & PC != gut;>> Am nächsten Tag kommt dann der Standardgedanke: ".. was hab' ich mir> bloß dabei gedacht ..">> :-)
Naja, ich hab schon mal ne Flasche Bier über mein Notebook entleert
(unabsichtlich, versteht sich...) und dabei Glück gehabt, dass nach
einer gründlichen Reinigung der Tastatur alles wieder funktionierte.
Seitdem bin ich auch ein wenig vorsichtiger mit der Kombination
"Computer + Bier"...
Wir haben letztes Jahr über 30.000 verbaut, unsere Kunden noch viel
mehr. Sind schon steile Teile. Was echt nervt sind Lieferzeiten, das
wird immer anstrengender.
Die Architektur ist topp (gibt es etwas vergleichbar schnelles im 8bit
Bereich?). Was ich mir wünschen würde, wäre eine "Sync"-Möglichkeit im
Sinne von "stehenbleiben, bis der Port sich ändert". Mit dem "Skip over
Jump" hat man leider immer ein paar Taktzyklen Toleranz.
Der Erfolg von Atmel lag damals darin begründet, daß sie mit kleinen
Bausteinen (z.B. 1200) angefangen und von da aus nach oben gebaut haben.
Heute starten sie mit full-featured Riesenchips, die Module teilweise
halbfertig (man sehe sich nur mal die AVR32 Erratas an) und lassen die
potentiellen Kunden jahrlang auf die kleinen Derivate warten...
so ganz nebenbei da ihr 30.000 Stück pro Jahr verbaut. Kann man solche
Stückzahlen bei Atmel direkt beziehen oder verdient da immer ein
Distributor mit?
In den Lego Mindstorms ist auch ein ATMega48 als Co-Prozessor verbaut:
http://mindstorms.lego.com/Overview/NXTreme.aspx
dann das Hardware Development Kit herunterladen, dot befinden sich die
Schaltpläne.
> - die doppelt- oder dreifachbelegung der pin's
Multiplexing kann man bei Controllern mit wenigen Pins und großem
Funktionsumfang leider nicht verhindern.
> - die teilweise kryptische bezeichnung der 'fuse bit's'
Bei AVR muß ich mich auch ständig durch die Beschreibungen wühlen, um
herauszufinden, was ich eigentlich setzen muß. Die Tatsache, daß es bei
PonyProg dann auch noch invertiert ist, vereinfach die Sache nicht
wirklich.
Kann natürlich auch damit zu tun haben, daß ich mit PICs mehr Erfahrung
habe als mit AVR.
["breq" vs "jrz"]
Das eine Orientiert sich eher an den Mnemonics von Motorola und das
andere an Intel.
Ich denke mal, daß es hier wie bei little- und big-endian ist, wo einem
das "natürlicher" vorkommt, was man als erstes kennengelernt hat. Ich
persönlich bin beispielsweise mit den Motorola-Mnemonics vertrauter und
muß bei den Intel-Gegenstücken meist erst überlegen, was gemeint ist.
["ldi" vs "mov"]
Finde ich eigentlich gar nicht schlecht, da es klar macht, daß hier
wirklich eine andere Instruktion mit anderer Codierung dahinter steckt.
"mov" wäre natürlich möglich und wird von einigen RISC-Architekturen
auch gemacht, kann aber auch fehleranfällig sein, wie hier jemand schon
angemerkt hat.
> Ich vermisse Shifts mit Angabe der Anzahl der Bits
Ich glaube das habe ich hier im Thread auch schon mal bemängelt.
Irgendwie kommen da Erinnerungen an den 8086 auf, der auch nur um eine
Position shiften konnte.
> das geht wohl mehr in richtung cisc architektur!
Nicht unbedingt, da es über einen Barrel-Shifter durchaus in einem
Taktzyklus machbar ist.
> Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei> CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern> generell eher selten anzutreffen.
Ich kenne mich jetzt zugegebenermaßen nicht mit der Implementierung
eines Barrel-Shifters aus, aber der ARM2 hatte meines Wissens auch schon
einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren.
Michael König wrote:
> Irgendwie kommen da Erinnerungen an den 8086 auf, der auch nur um eine> Position shiften konnte.
Über Shiftcount in CL ging auch mehr. Die interne Hardware konnte aber
nur um eine Position, der Rest lief in Microcode ab. Womit man die
Maschine schon man ein nettes Weilchen beschäftigen konnte. Und das geht
zu Lasten der worst case interrupt latency, eine Zahl die sich die
Hersteller von Controllern gerne gegenseitig um die Ohren hauen.
> einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren.
Ein 8x8 Multiplier ist auch kein Hexenwerk, trotzdem besitzt nur ein
Teil der AVRs diese Unit.
Ich glaube nicht, dass Shift über mehrere Bits beim Achtbitter Sinn
macht, da das Carry nur ein rausgeshiftetes Bit (als Übertrag für
Rotation ins nächste Byte) auffangen kann.
Ich hätte zwar gerne noch CPSNE (Gegenteil von CPSE) gehabt, und/oder
T-Bit-Transfer mit dem I/O-Bereich, aber man kann nicht alles haben, der
Befehlssatz ist endlich (es sind nunmal nur 16 Bit für Befehl incl.
Parameter da).
Zum ursprünglichen Thema kann ich (wie viele Andere auch) nicht
beitragen, da ich kein "Profi" bin.
...
Michael König wrote:
>> das geht wohl mehr in richtung cisc architektur!>> Nicht unbedingt, da es über einen Barrel-Shifter durchaus in einem> Taktzyklus machbar ist.>>> Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei>> CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern>> generell eher selten anzutreffen.>> Ich kenne mich jetzt zugegebenermaßen nicht mit der Implementierung> eines Barrel-Shifters aus, aber der ARM2 hatte meines Wissens auch schon> einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren.
Man bräuchte doch 'nur' 8 Multiplexer (einen pro Ausgabebit) mit jeweils
7 Eingängen die jeweils mit jedem Bit außer dem 'eigenem' verbunden sind
(Shift um die Position 0 mach keinen Sinn). Und je nach angelegter
Auswahl am Multiplexer hätte man einen geeigneten Shift.
Ich denke der meiste Teil der Chipfläche geht bei den größeren Modellen
eh für Flash und SRAM drauf oder?
Malte __ wrote:
> Man bräuchte doch 'nur' 8 Multiplexer (einen pro Ausgabebit) mit jeweils> 7 Eingängen die jeweils mit jedem Bit außer dem 'eigenem' verbunden sind
Ein 8:8 Barrelshifter ist für Multibyte-Shifts ziemlich sinnfrei. Da es
dank vorherrschender Programmierung in C recht oft um 16bit-Shifts geht,
wäre nur ein 16:8 Barrelshifter wirklich sinnvoll.
Ausserdem dürfte, so implementiert, die Fläche der Muxer selbst nicht
der Punkt sein. Ich schätze dass dann der grösste Aufwand in der
Verdrahtung draufgeht, zumal wenn dafür nur wenig Layer zur Verfügung
stehen. Wird besser, wenn man das in mehreren Stufen macht.
Leute leute ... es is ein RISC und kein CISC...
solchen "komplexen" funktionen wie ein Barrel werden anderwertig
zusammengenudelt.
und 8000 Transistoren glaub ich dir ned, weil selbst wenn es 8000 Gates
wären das auf 0.35um ca. ~1.0mm² kommen
Laut Wikipedia hatte der ARM2 30000 Transistoren. Das sind ungefähr so
viele wie bei 8086 und halb so viele wie 68000. Allerdings hatten 8086
und 68000 teils mehrere Microcode-ROMs, die wesentlich einfacher und
kompakter strukturiert sind als synthetisierte random logic.
Zum Vergleich: 8080 hatte 6000, Z80 bereits 13000 Transistoren.
Ein Barrel-Shifter passt meiner Meinung nach nicht gut in das
AVR-Konzept:
Wie Andreas Kaiser weiter oben gechrieben hat, ist ein Shift um
mehrere Bits nur dann sinnvoll, wenn die aus dem Register
herausgeshifteten Bits nicht verloren gehen, sondern in ein zweites
Register hineingeshiftet werden. Nur damit können auch Shifts von 16-
und 32-Bit-Variablen realisiert werden.
Ein Barrel-Shifter ist im Vergleich zu Addition, logischen
Bitmanipulationen deutlich komplexer, siehe
http://en.wikipedia.org/wiki/Barrel_shifter
Die Tinies können keine komplexen Operationen. Ich schätze, sie sind
konsequent auf minimale Chipfläche getrimmt.
In die Megas würde ein Barrel-Shifter eher passen, da hier bspw. auch
ein Multiplizierer Platz findet. Allerdings würde ein Shift mit
16-Bit-Ergebnis architekturbedingt wahrscheinlich 2 Zyklen dauern, da
zwei Ergebnisregister beschrieben werden müssen. Eine Multiplikation
mit 2**n tut ähnliches in 3 Zyklen, wenn man den zusätzlichen Befehl
zum Laden des zweiten Operanden berücksichtigt.
Man würde also relativ viel Chipfläche investieren, um eine der
seltener benötigten Operationen gerade mal einen Zyklus schneller zu
machen.
Der AVR-Befehlssatz ist in meinen Augen schon sehr durchdacht.
yalu wrote:
> Allerdings würde ein Shift mit> 16-Bit-Ergebnis architekturbedingt wahrscheinlich 2 Zyklen dauern, da> zwei Ergebnisregister beschrieben werden müssen.
Das läuft anders. 2 Register rein, eines raus. Ein kompletter 16bit
Shift sähe dann ungefähr so aus:
r16 = r17:r16 >> n
r17 = r17 >> n (bzw. r1:r16 >> n, wenn r1=0)
Den manchmal vermissten Rotate ohne Carry gibt's dann gratis, mit
r18 = r18:r18 >> 1
> Das läuft anders. 2 Register rein, eines raus.
Stimmt, so herum ist es natürlich gechickter.
Trotzdem bleibt die Frage: Wie oft braucht man einen Shift um mehrere
Stellen? In meinen AVR-Programmen kommt so etwas äußerst selten vor.
Bei Controllern mit größerer Wortbreite schon häufiger, bspw. wenn
sich bei 16- oder 32-Bit-IO-Registern eine Gruppe von Bits, die
zusammen eine Zahl darstellen, in der Mitte des Registers befindet.
Aber bei 8-Bit-IO-Registern geht dies auch mit ein paar LSL und SWAP
ausreichend schnell.
yalu wrote:
> Trotzdem bleibt die Frage: Wie oft braucht man einen Shift um mehrere> Stellen?
Beispielsweise wenn man CAN IDs als 29-Bit Werte an Funktionen übergibt,
und sie dort wild zerpflücken und auf die diversen Register eines
MCP2515 verteilen darf. Und umgekehrt.
> Beispielsweise wenn man CAN IDs als 29-Bit Werte an Funktionen übergibt,> und sie dort wild zerpflücken und auf die diversen Register eines> MCP2515 verteilen darf. Und umgekehrt.
Anstelle von N-bit-Shifts würde da auch z.B. ein Befehl Sinn machen, der
die oberen 4 Bits des Source-Registers in den unteren 4 Bits des
Zielregisters speichert. Dann erledigt man 8-Bit und Vielfache durch
uminterpretieren der Register (kostenlos), 4 Bits mit einem Befehl, und
die restlichen max. 2 Bits durch 1-Bit Shifts. Ohne 4-Bit-Shift kommst
du so auf max. 4 einbit-Shifts (jeweils max. 2 Befehle um Bit durch das
Carry "rüberzuschieben").
Bleibt die Frage, wieviele CAN IDs du so pro Sekunde verarbeiten willst,
dass diese (im schimmsten Fall) 8 Befehle pro ID so ins Gewicht fallen.
Da war der Hintergedanke dann sicher, dass man für diesen (eher
seltenen) Fall halt einen anderen Controller nimmt.
Leider hat da Microchip nicht nach dem Bosch gearbeitet und einige
Eigenerfindungen gemacht.
Die ID-Register vom Atmel sind 1:1 vom Bosch übernommen.
Und da die Geschwindigkeit vom CAN um etliches langsamer ist als die
Geschwindigkeit vom AVR bleibt genügend Zeit die ID umzurechnen und
weiter zu verarbeiten.
Das Andere ist, das man solche Dinge dem C-Compiler überlässt, denn wer
schreibt 32k Maschinencode in Assembler?
Assembler benutzt man doch nur noch bei ganz kleinen Aufgaben oder wo es
nicht anders möglich ist wird nur ein kleiner Teil (<5%) in Assembler
geschrieben.
Nur die Ruhe, ich beklage mich doch garnicht. Da war bloss die Frage im
Raum, wozu man grössere Shifts brauchen kann. Ich habe kein Problem
damit, wenn auf AVRs dann eine Schleife draus wird. Und ich bin nicht
verrückt genug, sowas in Assembler zu programmieren.
> Laut Wikipedia hatte der ARM2 30000 Transistoren.
Ich werde doch nicht etwa die Anzahl der Transistoren und die Taktrate
(8MHz) durcheinandergeworfen haben? Muß ich mal zu Hause bei Furber
nachschlagen...
@Andreas Kaiser
>Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu>implementieren.>meinst du eine *.inc datei mit sowas?>.equ jrnz = brne ;jump relativ not zero>.equ jrz = breq ;jump relativ zero>.>.>gruß pico
.equ add = 2 ; 'add' is a keyword (instruction)
.def r1 = r16 ; 'r1' is a keyword (register)
.def r0 = r31 ; 'r0' is a keyword (register)
.def r16 = r24 ; 'r16' is a keyword (register)
.def add = r2 ; 'add' is a keyword - again
(instruction)
.def mov = r29 ; 'mov' is a keyword (instruction)
hey gefunden in der help für
avr studio assembler2
ps: ret 6 fehlt mir immer noch, auch wenn ich daten und rückkehradressen
auf dem stack (2 getrennte) trenne bedeutes einen einen nicht
unerheblichen tacktaufwand ; bitte, bitte, sowas in si
pico