Ich habe schon viele Schaltpläne von veräten gesehen und mir ist aufgefallen ,das der Anteil an Atmel-Controllern nur so bei etwa < 1% liegt. Wo haben denn die Atmels ihren Nachteil ,das sie in der Industrie so wenig Verwendung finden? In punkto Leistung sind sie vielen Controllern sicherlich überlegen. Zum einsatz kommen z.B. Winbond 4 Bit controller, listenpreis 3 Euro stck. bei 100.000 stck. abnahme. Habe die beiden mal verglichen und AVR währe sogar günstiger mit mehr Leistung. Naja warscheinlich werden die ATMELS von den Japanern boykottiert habe ich den Eindruck g . Besonders im Bereich Funkgeräte kenne ich überhaupt kein einziges ,was einen AVR benutzt, eigendlich schade :-(.
Hallo, kann jetzt deine Beobachtung nicht teilen. Ich habe in Werkzeugüberwachungen auch schon AVRs gesehen. Auch bei der Funkübertragung gab es Module mit Atmels (ADDLINK). Ich persönlich stehe noch mit den AVRs auf Kriegsfuss, die 8051er sind mir lieber (AT89...). Es gibt ja auf dem Markt eine riesiege Auswahl von MCs, dass dei Entwickler vielleicht den MC auswählen, mitdem sie schon Erfahrungen haben oder worauf sie gelernt haben. Gruß Elektrikser
Hallo, 4-bit Controller haben meistens eine geringere Stromaufnahme. Allerdings ist da Atmel auch vertreten mit den Marc4-Controllern. Damit sind sie in fast jedem Auto verteten. Und AVR`s werden in der Industrie auch sehr oft eingesetzt. Das geht imho von elektrischen Zahnbürsten über Kaffeemaschinen bis hin zu Termitendetektion. Gruß Markus
Und in Maschinensteuerungen mit viel Störungen usw. laufen 8051 einfach stabiler, da diese noch in einer anderen Technologie hergestellt werden. AVRs sind zu empfindlich gegen Störungen. AVRs sind einfach noch zu neu und deshalb für viele Entwickler ungewohnt. Deshalb werden für kleine Aufgaben PICs, 8051 usw. eingesetzt und bei größeren dann M16C, H8 und ähnliche CPUs.
In der Industrie hängen ja viele Jobs an einer Entwicklungsentscheidung und da geht man eben immer sehr vorsichtig an den Einsatz neuer Bauteile. Und der AVR ist ja noch relativ jung und die ersten AVRs hatten auch noch ne ganze Menge Macken gehabt. Da nimmt man eben lieber Bauteile, die sich schon bewährt haben bzw. zu deren Macken ein funktionierender Workaround bekannt ist. Und auch der Softwareschutz spielt eine große Rolle, d.h. solche Nachrichten lassen erstmal wieder viele Entwickler den AVR aus der Hand fallen: http://www.avrfreaks.net/phpBB2/viewtopic.php?t=19790 Peter
Naja, siehe den referenzierten Beitrag dort: mit beliebig kriminellen Methoden kannst Du die `code security' beliebiger Controller knacken, das ist eigentlich ein alter Hut. Wer Wert auf Security legt, muß wohl auch den ROM verschlüsseln.
Hi... Nicht zu vergessen: Second source... Es gibt nur einen Anbieter (Hersteller), von dem man sich abhängig machen würde. Das dürfte für viele Unternehmen zu unsicher sein. ...HanneS...
>Und auch der Softwareschutz spielt eine große Rolle, d.h. solche >Nachrichten lassen erstmal wieder viele Entwickler den AVR aus der Hand >fallen: > >http://www.avrfreaks.net/phpBB2/viewtopic.php?t=19790 mein Eindruck von der Diskussion auf avrfreaks ist, dass die AVRmega in Punkto Ausleseschutz sehr gut wegkommen. Jedenfalls besser als die meisten 8051-Derivate, von den PICs ganz zu schweigen. Was das Vorkommen von Microcontrollern in Geräten betrifft: viele Hersteller neigen dazu, ihre Chips mit einem eigenen Label beim Hersteller bedrucken zu lassen (ab einem bestimmten Volumen). Nur aufschrauben und angucken muss also nicht unbedingt aussagekräftig sein. Stefan
Das betrifft Dich aber bei fast allen MCUs, außer sehr altmodischen. Selbst wenn Du bei MCS51 bleiben willst, aber vernünftige Rechenleistung brauchst, bist Du am Ende wieder bei einem einzigen Hersteller -- bei Varianten mit verbesserter onboard-Hardware sieht's wohl sehr ähnlich aus.
Hi, haupabschreckpunkt sind wohl die Lieferproblem die Atmel immer mal wieder hat siehe diese frühjahr mit dem mega8 es gab monate lang keine mega8's mehr am markt wenn nur in kleinen stückzahlen zu horrenten preisen wenn jetzt deine Produktion davon abhängt ob die teiel lieferbar sind oder nicht greif ich als entwickler lieber zu nem zuverlässigeren Hersteller. Sehe auch die ankündigunge von wegen neuen avr's (tiny2313 etc ... ) Moritz
>lieferbar sind oder nicht greif ich als entwickler lieber zu nem >zuverlässigeren Hersteller. Sehe auch die ankündigunge von wegen neuen Und zu welchem? Das gleiche Spiel ist uns auch schon bei anderen Herstellern passiert (z.B. Motorola). Wenn der Bedarf plötzlich steigt, dann hilft Dir wahrscheinlich nicht mal eine Second-Source. Stefan
Stimmt. Ich sehe aber auch, dass in den meisten Schulen (Techniker, FH) der AVR% kein Thema ist. Da wird immer noch in der Microkontrollertechnik der 8051er gelehrt. O.K. irgendwann sucht man nach etwas neuerem, wo man größere Projekte effektiv programmieren kann. Dann verwenden aber schon einige 16-bit-Kontroller. Ich habe auf den '51er (Assembler) gelernt und versuche jetzt meine C-Kenntnisse nicht verkümmern zu lassen. Deswegen probiere ich es jetzt mit den ATmegas. Ansonsten würde ich noch bei den '51ern bleiben, da ich sie noch nicht ausgereizt habe. Gruß Elektrikser
Hi das an Lehrinstituten noch mit MCS51 und ähnlichen (6502 hab ich auch schon erlebt) dürfte drei Gründe haben: 1. Bequemlichkeit der Lehrenden. Der Lehrende will sich ja nicht alle 5 Jahre in einen neuen Controller einarbeiten. 2. Geldmangel. Neue Famielie heist neue Board und evtl. sogar neue Tools. 3. Kennt man einen, kennt man innerhalb kürzester Zeit auch andere. Matthias
4. Keine Probleme mit dem Programmieren. Wenn schon viele Hobbybastler ihre AVRs mit ISP Programmiergeräten ruinieren (Fuse Bits usw.), möchte ich nicht wissen wie es in Lehrinstituten aussieht... Außerdem lässt sich der 8051 mit externem Programmspeicher betreiben, was auch sehr vorteilhaft ist. Ich verwende einen EPROM Simulator, da ist die Fehlersuche extrem einfach (solange den Code ändern und immer wiede ausprobieren bis der Fehler gefunden ist.) Außerdem ist der 8051 für Anfänger einfacher, da man alle IO Ports direkt beschreiben kann, es nur einen Akkumulator, Bitfunktionen und weniger Befehle gibt.
> 4. Keine Probleme mit dem Programmieren. Wenn schon viele > Hobbybastler ihre AVRs mit ISP Programmiergeräten ruinieren (Fuse > Bits usw.), möchte ich nicht wissen wie es in Lehrinstituten > aussieht... :-) Immer einen STK500 mit Parallelprogrammiermöglichkeit in der Ecke liegen haben... Man muß den Leuten ja nicht gerade einen ATmega8 geben, bei dem sie sich /RESET wegdefinieren können. ;-) > Außerdem lässt sich der 8051 mit externem Programmspeicher > betreiben, was auch sehr vorteilhaft ist. Ich verwende einen EPROM > Simulator, da ist die Fehlersuche extrem einfach (solange den Code > ändern und immer wiede ausprobieren bis der Fehler gefunden ist.) Was ist dabei der Unterschied zum neu Flashen eines modernen Controllers (außer daß die EPROM-Variante mehr Hardware braucht)? Ach ja, die Flash-Variante kann man sogar im Zielsystem neu programmieren. ;-) > Außerdem ist der 8051 für Anfänger einfacher, da man alle IO Ports > direkt beschreiben kann, es nur einen Akkumulator, Bitfunktionen und > weniger Befehle gibt. Seltsame Logik. Weil der Prozessorkern so schrottig ist, daß man alle Arithmetikoperationen auf einem bestimmten Register ausführen muß, um dieses danach wieder freizuräumen, ist er einfacher zu programmieren? Ich würde da eher das Gegenteil behaupten. ;-) Nee Du, es mag sicher Gründe geben, warum sich jemand für MCS51 entscheidet (sind ja schon einige genannt worden), aber das würde ich wirklich eher für Negativreklame halten... Wenn Du unbedingt willst, kannst Du Dir ja auf einem AVR auch Register 16 als Akkumulator definieren und alle Arithmetik nur darüber machen. ;-)
Also ich würde AVRs als schon recht einfach zu programmieren befinden! Bei uns an der Uni werden seit diesem Jahr auch ATmega16-µC im Praktikum verwendet (Technische Grundlagen der Informatik).
@Jörg: Ich habe auch spontan gedacht: alles Gründe, warum ich lieber einen AVRmega als einen 8051 einsetze. Einen Eprom-Simulator habe ich auch noch in der Ecke rumliegen - als Notnagel, wenn was an den alten Kisten gemacht werden muss. Das kommt glücklicherweise nur noch ganz selten vor. Wer schonmal in-circuit-debugging oder auch nur -programming gemacht hat, der will sicher nicht freiwillig zurück zu einem Eprom-Emulator. Stefan
OK, wenn die AVRs so einfach sind, dann sagt mir mal wie ich ein Bit aus einem Register an einen bestimmten Pin legen kann und das in möglichst wenigen CPU Takten.
`Register' kennt mein C-Compiler nicht als Datentyp. ;-)
Ansonsten ist die Aufgabe ziemlich allgemein formuliert. Aus
folgendem Stückchen C-Code:
#include <avr/io.h>
void
setcleario(unsigned char r24)
{
if (r24 & 4)
PORTB |= (1 << 2);
else
PORTB &= ~(1 << 2);
}
compiliert mir ein GCC zum Bleistift:
setcleario:
sbrs r24,2
rjmp .L2
sbi 56-0x20,2
ret
.L2:
cbi 56-0x20,2
ret
braucht 4 bzw. 5 Takte (ohne RET, in der Praxis würde man dafür allein
keine Funktion schreiben, dafür das erste RET gedanklich durch ein
RJMP ersetzt).
Aber das wird für den Thread langsam ziemlich off-topic.
So wie ich mirs gedacht habe: Es gibt keinen direkten Befehl. Das ist ein Vorteil beim 8051: Er ist bitadressierbar, d.h. man kann problemlos boolean verwenden, was beim AVR etwas schwer ist. Ok, sagen wir mal beide haben vor und Nachteile. Schaut man sich die Befehle an, ist der 8051 einfacher, hier ein Bsp: Beim AVR gibt es LDI, OUT, IN, MOV, LD, ST, BST, BLD usw. Beim 8051 ganz einfach: mov Bei vielen weiteren Befehlen ist es ebenso. Dafür gibt es mehr Möglichkeiten, um ein Programm einfacher gestalten zu können, aber für Anfänger und Assembler empfehle ich: 8051 Für C Compiler: AVR (dafür sind die ja auch optimiert)
" Und wie lange braucht der 8051 dann dafür? " Seit paar Jahren gibt es 8051-Nachfolger . Unglaublich schnelle auch . Und es kommen ( fast ) täglich neue Varianten dazu . Die AVR's finde ich trotzdem interessant ;-)
Ich weiß, daß es neuere 8051er gibt, aber die viele der ursprünglichen Argumente (Hardwarekompatibilität, second source) treffen auf diese nicht mehr zu -- warum sollte man sich dann unbedingt sowas antun und nicht gleich einen ,,richtigen'' Controller (ARM oder sowas)?
Also wir betreiben unsere aktuelle Entwicklung (Gaszähler) mit einem ATmega 128. Läuft auch gut, aber der Speicher ist jetzt voll, damit ist kein Platz mehr für diverse Änderungen (Profibus PA soll rein). Deshalb wird die Elektronik jetzt für einen Renesas M16C umgestrickt. Tschau
Den ,,richtigen'' Controller gibt es nicht, sonst würde ja nur dieser produziert und kein anderer. Es gibt immer nur den im konkreten Fall richtigen, d.h. mit dem ein bestimmter Entwickler eine bestimmte Aufgabe am optimalsten lösen kann. Optimal kann dabei auch wieder völlig Verschiedenes bedeuten, wie geringe Entwicklungzeit, hohe Störsicherheit, geringer Strombedarf, einfacher Schaltungsaufbau, Erweiterbarkeit usw.. Ich kenne beide, den AVR und den 8051 und kann sagen, daß keiner aufs falsche Pferd setzt, wenn er sich für den einen oder den anderen entscheidet oder beide einsetzt. Beide haben ihre Vorteile, die schon verschiedentlich genannt wurden. Beim 8051 gefällt mir z.B. die hohe Kodeeffizienz und beim AVR die Zero-Komponents Möglichkeit. Und wenn man in C programmiert, ist es auch kein Problem beide einzusetzen. Peter
In der Industrie nimmt man das was passt. Wenn in der Infrarotfernbedienung für 9,- EUR kein AVR drin ist, dann liegt das daran, dass ein 4bit controller genügt und für wenige cents erhältlich ist. Epson hat sich bei ihren Tintenpatronen aber z.B. trotzdem für den tiny12 entschieden - und so ein Millionseller sollte die Anfangsbehauptung hier doch z.B. wiederlegen. Es gibt noch zig andere Beispiele. Ein anderer Grund gegen den AVR (oder irgendwas modernes) ist das alte "Füchse" ihre Werkzeuge ungerne ändern, wenn sie sich mal daran gewöhnt haben. Aber bei jungen Unternehmen und modernen Produkten (u.a. MP3-Player) findest du immer öfter auch nen AVR. @peter: was ist an mov a, ... mov ...,a mov mov mov mov effekktiv??? cu joern
na ja, wenn man sich nur mov merken kann, ist das schon nicht schlecht..:-) Mit dem Argument, dass sich Leute ungern und freiwillig schon gar nicht umstellen, ist viel dran. Ist nun mal so, dass eine neue Entwicklungsumgebung prinzipiell als störend und VIEL schlechter als die ältere empfunden wird, einfach weil man sich nicht sofort richtig auskennt und dementsprechend nicht sofort effizient arbeiten kann. Ist mit Layout-Programmen auch nicht anders, da schwört jeder auf seine Software. Auch wenn man viel von einem MC auf den nächsten übertragen kann - wenn man einen im Schlaf beherrscht, fühlt man sich mit einem neuen erstmal auf etwas unsicherem Terrain.
@Joern, compilier doch einfach mal eine praktisch nutzbare Routine (kein Benchmark) mit dem Keil C51 oder mit dem AVRGCC. Die 8051-Binaries sind in 90% der Fälle kleiner. Der Trick beim 8051 ist, daß er vieles direkt im SRAM machen kann. Z.B. wird aus: if( --val == 0 ) foo(); beim 8051 nur ein DJNZ (3 Byte) und beim AVR ein LD + INC + ST + BRNE (12 Byte). Genauso bei: val ^= 0x12; 8051: XRL AVR: LD + LDI + EOR + ST Peter
Ich hab mal gelesen das einige sich aufgeregt haben das die Interrupts keine Priotität haben und sie das nicht abkönnen. Wo ich übrigens Unmengen AVRs gesehen habe waren soche Hausentkalkungsankagen die an Wasserleitungen angebaut werden :-) Ansonsten ist es wirklich einfach so: womit man man angefangen hat dabei bleibt man gerne, auch wenn es möglicherwise für den konkreten Fall nicht optimal ist. Insofern würden MC-Hersteller gut daran tun Schulen und Unis kostenlos zu versorgen. Nur ein hervorgegangener Entwickler der eine Großserie mit AVR auslegt und das Geld ist wieder drin :-)
Boah ey, ich glaube es ja nicht. Jetzt fangt ihr schon Glaubenskriege um Controller an! Win gegen Linux, Mac gegen PC, und jetzt 8051 gegen AVR? Wie war das noch: 8051=CISC, AVR=RISC? War es das, was ihr hier nochmal anhand von Codebeispielen zeigen wolltet? Gruß Matthias
Obwohl ich ihn (nicht nur wegen seinem Hesteller) nicht mag: der MSP430 vereint einige Vorteile des AVR und des 8051 und noch viel mehr.
Hi das findet hier mit schöner Regelmäßigkeit und denn immer wieder selben Argumenten alle paar Monate statt. Ist eine stark abgeschwächte Form von Windows vs. Linux in den Heise-Foren. Ist mit einer Tüte POPCORN z.T. sehr unterhaltsam. Matthias
solang wir hier jetzt nicht anfangen mit fischen um uns zu schmeissen oder uns gegenseitig *plonk*-en geht das doch noch. überigens, es ist noch kein freitag :)
Wie kann man denn hier "plonken"? Oder meinst Du nur, das man auf einen Beitrag mit plonk antwortet, was natürlich reichlich schwachsinnig ist. Aber stimmt, im Heise-Forum liest an das öfter mal... (und da kann man ja tatsächlich bis zu 36 User ausblenden) Gruß Ingo
Ich will jetzt auch nochmal was dazu sagen. So, das muste einfach mal gesagt werden. Peter
Systemdiskussionen sind unter Ingenieuren keine Seltenheit. Der Hobbybastler ist davon jedoch stark genervt!
ich würde eher sagen: je weniger wissen da ist, desto engagierter wird die diskussion geführt
Genau Tobi, der Laie staunt, der Fachmann wundert sich. Halbwissen verleitet allzu oft zur Extrapolation zu eingebildetem Vollwissen :-) MfG, Khani
Da es ja in erster Linie um Halbleiter geht, ist meiner Meinung nach Halbwissen vollkommen ausreichend. Und dann fällt mir da noch die Sache mit den Philosophen und den Experten ein, aber das ist wieder eine andere Geschichte :-)
Ich hab jedenfalls meine Konsequenzen daraus gezogen : Ich benutze einfach beide ! Und da ich es endlich geschafft habe mir C beizubringen, laeuft der Code prinzipiell auf beiden Architekturen. Gruss Eddi
Also ich fand die Diskussion bisher sehr interessant zu lesen und eigentlich ist sie bisher ja auch noch recht gepflegt. :) Gruesse, johannes
Man muss natürlich auch, wie schon gesagt, auf die Werkzeuge achten. Ich begann mit dem Keil-Compiler und stieß nach einiger Zeit auf die AVRs und den Codevision-Compiler. Ich finde den Codevision viel besser als den Keil. Innerhalb weniger Minuten hat man eine Serielle-Vollduplexverbindung, Interruptgesteuert, gebuffert .... Gängige I2C-Bausteine sind integriert, die man nur anklicken braucht. Warteroutinen sind integriert in delay.h, die sich entsprechend der Qurazgeschwindigkeit anpassen. Der Compiler kennt binäre Zahlen variable=0b10010010; Und überhaupt der gesamte Prozessor kann auf einfachste Art initialisiert werden. Er unterstützt zwar nur die AVRs, aber genau deshalb kann er so benutzerfreundlich sein, weil der Compiler eben nur auf eine kleine Gruppe spezialisiert ist. Die Beschreibung ist einfach und leicht zu durchschauen. Außerdem sind immer wieder Beispiele angeführt. Die Beschreibung des Keil-Compilers ist furchtbar. Der Keil ist mehr ein Universal-Compiler. Man kann ihn für alle möglichen 8051er 8-Bit für 16-Bit-Controller usw. einsetzen. Durch diese Universalität leidet die Bedienung etwas. Z.B. Wenn man mit Keil einen 8051er programmiert gibt es kleine Unterschiede im Compiler, als wenn man z.B. einen C167er programmiert. Außerdem stimmt die Zeit, die im Simulator angegeben wird (Jedenfalls beim C167) überhaupt nicht mit der Wirklichkeit überein. Ich habe mich wegen dieses Problemes schon an Spezialisten gewandt, die mir das bestätigten. Beim AVR-Studio stimmte das Timing immer mit der Wirklichkeit überein. Tschüss Martin
Man kann doch nicht Keil (jahrelang für einen Controller optimierten komerziellen Compiler) nicht mit dem freien nur für den avr umgestrickten winavr (dem man nicht mal die Harvard-Architektur beibringen konnte) vergleichen?! Dann solltest du schon den gcc für den 8051 hernehmen oder den IAR Compiler beim AVR. Ansosnten wirkt das unehrlich. Ich meinte überhaupt keinen C-Compiler, sondern Assembler und da ist es schon ein übel hinkender Vergleich den 8051 als effizient zu bezeichnen....?! cu joern
Hallo, also meine Erfahrung ist, dass bei Projekten mit hohen Stückzahlen auch schonmal häufig neu überlegt wird, welchen Controller man für eine Anwendung verwendet wird. Dabei wird dann der Mehraufwand, der durch die neue Einarbeitung entsteht durch die Stückzahlen wieder rein geholt. Häufig ist es dann auch so, dass auf alten Plattformen wieder aufgesetzt wird. Dabei meine ich z.B. so eine art kleines Betriebssystem. Dabei sollte man dann auch überlegen, ob man compilerspezifische Bibliotheken oder Codeerweiterungen wie z.B. 'bit' oder auch die oben erwähnten Binärwerte als Vorteil sieht und anwendet. Dadurch wird ein Code immer schlechter portierbar, da es halt nicht dem C-Standard entspricht. Allgemein kann man wohl nicht sagen, welcher Controller der beste ist. Stattdessen sollte man immer das Gesamtpaket sehen. Also die Anwendung, den Entwickler, die Umgebung und immer wichtig, der Preis oder die Kosten. Sollten die Stückzahlen nicht so hoch sein, so ist es denke ich oft besser, auf bewährte Systeme zu setzen, da hier wohl die Entwicklungskosten mehr reinschlagen als ein paar Cent die man am Controller spart. Bis denne, Ralf
@Joern, das hat nichts mit dem Compiler zu tun, der 8051 SDCC machts ähnlich und der AVRGCC ist ja auch kein schlechter Compiler. Es hat damit zu tun, daß der 8051 für Steuerungsaufgaben optimiert ist d.h. wo logische Operationen, Vergleichen, Zählen, Bitmanipulationen, bedingte Sprünge usw. die Hauptrolle spielen aber keine hochkomplexen Berechnungen nötig sind. Und deshalb ist es kein großer Nachteil, wenn ADD, SUBB, MUL und DIV nur mit dem ACCU gehen, sondern ein besonderer Vorteil, wenn viele logische und Bit-Operationen direkt auf den Registern, den SFRs und dem SRAM ausgeführt werden können. Speziell in Interrupts spart das einige PUSHs und POPs ein. Und deshalb spielt es auch keine Rolle, ob C oder Assembler, übliche Steuerungsaufgaben sind auf dem 8051 immer kleiner. Deshalb habe ich nicht gerne den AT90S2313 verwendet, weil ich da regelmäßig ans Flashende gestoßen bin. Ich mußte einmal sogar auf den AT89C2051 umstellen, weils absolut nicht mehr reingepaßt hatte. Aber inzwischen gibt es ja den kleinen ATMega8, da kann man endlich entspannt programmieren ohne gleich die großen Tausendfüßler nehmen zu müssen. Peter
Ich bin eurer Meinung. Ich hab jetzt den Codevision auch nur so angeprisen, weil ich glaube, dass er für Hobby-Elektroniker ideal ist. Er beinhaltet sehr viele praktische Funktionen und kostet um das 10-fache weniger. Mit anderen Compilern habe ich noch keine Erfahrungen gemacht, außer mit diesen Beiden. Tschüss
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.