Hallo, ich möchte mich mehr mit Microkontrollern beschäftigen und würde gerne wissen ob es sich mehr lohnt AVR Microkontroller oder der 8015 Reihe zu arbeiten. Oder spielt es keine Rolle? Ich habe bisher nur ein paar kleine Projekte mit einem Arduino Bausatz gemacht um mich an das Gebiet ranzutasten und würde mich gerne weiter in die Microkontroller Programmierung einarbeiten. Ich hoffe auf ein paar hilfreiche Antworten mit guten Argumenten
Eine kurze Suche im Forum bringt Dir etliche Threads zum Thema. Das wurde bereits erschöpfend diskutiert. Oder ist das nur der übliche Freitags-Provokationsversuch?
Dr. MIPS schrieb: > Oder ist das nur der übliche Freitags-Provokationsversuch? Nein das ist eine ernsthaft gemeinte Frage, ich konnte in der Suche nichts finden und frage deshalb :) Ich hab gedacht das es hier bestimmt den ein oder anderen qualifizierten Rat gibt ;)
Basti schrieb: > Ich empfehle den 0815. Jou, sind dieselben Ziffern und auch dieselbe Quersumme. Kann also nicht falsch sein... ;-) ...
Nina schrieb: > ich möchte mich mehr mit Microkontrollern beschäftigen und würde gerne > wissen ob es sich mehr lohnt AVR Microkontroller oder der 8015 Reihe zu > arbeiten. Schau in die jeweiligen Datenblätter und Referenzmanuals und triff dann deine Entscheidung selbst. Manche mögen dies, andere das. W.S.
Du hast Arduino Erfahrungen. Also solltest du mit den AVR Typen weitermachen, denn du kannst die vorhandenen Werkzeuge nutzen. Auch, wenn hier ab und an Glaubenskriege geführt werden, der CPU Typ ist relativ unwichtig für die meisten Projekte.
Wenn man in Assembler reinschnuppern will, dann ist der 8051 die erste Wahl. Gegen so einen durchdachten, kompakten und einfachen Befehlssatz kommen PIC und AVR lange nicht an. Mächtige Befehle für Bitmanipulationen, schön kompakte Befehle für Schleifen, Verzweigungen und Tabellenzugriffe, sogar Mul und DIV gibt es und die meisten Befehle gehen direkt im RAM bzw. auf IO-Register. Auch die 4 Interruptprioritäten sind sehr nützlich. Z.B. kann man das zeitkritische 1-Wire in SW implementieren, ohne das andere Interrupts das Timing stören. Von den Compilern gibt es Demoversionen mit Codelimit. Für die Silabs 8051 kann man sogar den Keil als Vollversion bekommen, wenn man sich registriert. Da die 8051 sich nur im Includefile unterscheiden, kann man mit jedem C51-Compiler auch jeden anderen 8051 programmieren bzw. simulieren. Nur das Debuggen bzw. Codebanking (>64kB) ist für die Derivatfamilien speziell.
Peter D. schrieb: > Wenn man in Assembler reinschnuppern will, dann ist der 8051 die erste > Wahl. Gegen so einen durchdachten, kompakten und einfachen Befehlssatz > kommen PIC und AVR lange nicht an. Mir gefällt der Akku nicht. Da war der AVR mit seinem 32er-Registersatz eine helle Erleuchtung... > Mächtige Befehle für Bitmanipulationen, schön kompakte Befehle für > Schleifen, Verzweigungen und Tabellenzugriffe, sogar Mul und DIV gibt es > und die meisten Befehle gehen direkt im RAM bzw. auf IO-Register. Allerdings fällt man dann auf die Nase, wenn man diesen Befehlssatz auf eine andere, moderne Architektur ummünzen muß.
Lothar M. schrieb: > Mir gefällt der Akku nicht. Der Akku wird ja fast nur für die Grundrechenarten (+-*/) gebraucht und das ist in Steuerungen selten die Hauptsache. Daher habe ich das nicht als Flaschenhals bemerkt, sondern viele Variablenoperationen direkt in Registern bzw. SRAM durchgeführt. Lothar M. schrieb: > Allerdings fällt man dann auf die Nase, wenn man diesen Befehlssatz > auf eine andere, moderne Architektur ummünzen muß. Wer vorhat, mehrere Architekturen zu benutzen, der sollte C nehmen. Ich meinte mit "reinschnuppern" auch eher, um mal zu verstehen, wie so ein MC tickt. Ich rate heutzutage keinem mehr, größere Projekte in Assembler zu schreiben, das ist vergeudete Zeit.
Ein Admin eröffnet den GK? Na denn, AVR und 8051 sind alte Kamelen. Die alte Timerei vom 8051 und die veralteten Programmier- und Debugmethoden vom AVR sprechen Bände. Nimm was modernes, nimm was Vernünftiges: ARM Cortex, MS430.
Verwundert schrieb: > Ein Admin eröffnet den GK? Admin != Moderator Und nur wer unbedingt gegen irgendwas oder für irgendwen kämpfen will, eröffnet einen Krieg. Mir ist es nicht wert, um eine uC Architektur zu kämpfen. Dazu habe ich schon zu viele verschiedene verwendet und bin mit jeweils jedem uC zum jeweiligen Ziel gekommen... > Na denn, AVR und 8051 sind alte Kamelen Aber genau nach diesen beiden uC hat der TO gefragt. Nina schrieb: > Ich habe bisher nur ein paar kleine Projekte mit einem Arduino Bausatz > gemacht um mich an das Gebiet ranzutasten und würde mich gerne weiter in > die Microkontroller Programmierung einarbeiten. Man kann sogar damit und mit einem vernünftigen Programmierstil etwas sinnvolles machen. Allerdings sind gefühlte 95% der im Netz herumfliegenden "Arduino-Programme" die Bits nicht wert, die sie im Speicher belegen. Ich sage z.B. meinen daraufhin sichtlich schockierten Praktikanten: ein "delay()" ist ein Programmfehler! Peter D. schrieb: > Ich meinte mit "reinschnuppern" auch eher, um mal zu verstehen, wie so > ein MC tickt. Da stimmt es allerdings, wenn es ums Verstehen geht: der 51er mit seiner überschaubaren Peripherie ist leichter zu kapieren. Wenn es aber um den Nutzen geht: alle modernen Architekturen sind wie der AVR registerorientiert.
:
Bearbeitet durch Moderator
>> Na denn, AVR und 8051 sind alte Kamelen > Aber genau nach diesen beiden uC hat der TO gefragt. Na und, bestimmt kennt der TO die richtig guten uC gar nicht. Die meisten setzen hier Atmel mit AVR gleich, ein beschränkter Horizont halt. Den gilt es zu erweitern. Und daher muss man auf bessere moderne uC Hinweisen, die speziell für Anfänger weniger Fehler Potential, komfortablere Handhabung bieten
Verwundert schrieb: >>> Na denn, AVR und 8051 sind alte Kamelen >> Aber genau nach diesen beiden uC hat der TO gefragt. Dann schmeiße ich mal diesen hier in die Runde: STM32F030 Ein kleiner Cortex-M0. Günstig, schnell, kostenlose IDE in Massen (ja, auch Keil MDK-ARM gehört dazu), zahlreiche Debugger (der ST-Link ist für den Anfang sicherlich nicht schlecht), moderne Architektur, etc. Nina schrieb: > Oder spielt es keine Rolle? Jepp. Wenn man gewillt ist was zu lernen, so ist die Architektur relativ egal. Kennt man einen sehr gut, so fällt der Umstieg auf andere ziemlich leicht. Nina schrieb: > Ich habe bisher nur ein paar kleine Projekte mit einem Arduino Bausatz > gemacht um mich an das Gebiet ranzutasten und würde mich gerne weiter in > die Microkontroller Programmierung einarbeiten. Schon mal ein guter Anfang. Pass nur auf, dass der Arduino nicht deinen (noch nicht wirklich entwickelten) Programmierstil für immer versaut. Wärst nicht der Erste, dem das passiert.
Claus M. schrieb: > Dann schmeiße ich mal diesen hier in die Runde: STM32F030 Aber nicht, um die Grundlagen zu erlernen. Der Tip mit dem 8051 ist schon ganz gut. Ebenfalls ganz gut - wenn auch ein bissel "anders" sind die kleinen PIC's, also 16Fxyz. Bei beiden Architekturen kann man sehr gut die Grundlagen und Assembler lernen. Das ist wichtig. Ja wichtig. Man sehe sich in diesem Forum mal um: all diejenigen, die Probleme haben mit dem Grundverständnis und sogar mit simpelsten Konstrukten in C sind diejenigen, die noch nie ihre Nase mal in Assembler gesteckt haben. Geschweige denn in die Manuals zu ihren Bastelobjekten. Es fehlen halt die Grundlagen. Aber Maschinenbefehle und Assembler für ARM ist denn doch für den Einstieg nicht das geeignetste. Ist zwar alles durchaus logisch aufgebaut, aber dennoch für den Anfang zuviel.
W.S. schrieb: > Bei beiden Architekturen kann man sehr gut die Grundlagen und Assembler > lernen. Das ist wichtig. Watt ein Blödsinn, watt ein Gefasel der ewig gestrigen. Die Erde dreht sich weiter und heute programmiert man in Hochsprache.
Hallo, Verwundert schrieb: > W.S. schrieb: >> Bei beiden Architekturen kann man sehr gut die Grundlagen und Assembler >> lernen. Das ist wichtig. > > Watt ein Blödsinn, watt ein Gefasel der ewig gestrigen. Die Erde dreht > sich weiter und heute programmiert man in Hochsprache. eigetnlich warte ich auf den Tag, wo es keine neuen Prozessoren und Compiler mehr gibt, weil kein Programmierer den Kram, der da erzeugt wird, mehr lesen kann. Vermutlich gibt es dann aber Transistoren, die nicht nur 0 und 1 als Zustand können sondern auch geschweifte Klammern. Gruß aus Berlin Michael
Verwundert schrieb: > W.S. schrieb: >> Bei beiden Architekturen kann man sehr gut die Grundlagen und Assembler >> lernen. Das ist wichtig. > > Watt ein Blödsinn, watt ein Gefasel der ewig gestrigen. Die Erde dreht > sich weiter und heute programmiert man in Hochsprache. Es geht ja auch nicht darum, nachher alles in Assembler zu schreiben, sondern darum, zu verstehen, wie der Prozessor so arbeitet. Aber ich merke auch schon, dass tieferes Verständnis heutzutage total out ist. Merkt man auch öfters mal in Autowerkstätten, wo dann nur noch per Diagnose Fehler ausgelesen und darauf basierend dann irgendwelche Teile getauscht werden, ohne wirklich mal zu suchen, was die tatsächliche Ursache ist. Oder die Diagnose meldet keinen Fehler, also ist da per Definition auch keiner.
Michael U. schrieb: > Vermutlich gibt es dann aber Transistoren, die nicht nur 0 und 1 als > Zustand können sondern auch geschweifte Klammern. Hochsprachenelemente in Silizium zu giessen wurde schon gelegentlich versucht, war aber letztlich nie auf Dauer erfolgreich. Es erwies sich als sinnvollere Arbeitsteilung, den Prozessoren die Grundoperationen der eingesetzten Technik beizubringen, und den Compilern die Hochsprachen zu überlassen.
:
Bearbeitet durch User
Du wirst nicht wünschen, dass die Werkstatt mit Ahnung ein Pleul tauscht. Denn das möchtest du nicht bezahlen. Die breite Masse der Hobbybastler braucht kein asm. Wer Spaß hat, sich auf genau eine Archtektur zu versteifen, kann ja den Befehlssatz auswendig lernen. Für die jenigen, für die der uC nur Mittel zum Zweck ist, die interessante Projekte umsetzen, ist am überflüssig.
Verwundert schrieb: > kann ja den Befehlssatz > auswendig lernen. Schwachsinn, man muss ihn verstehen und auch anwenden können. ...
Verwundert schrieb: > Für die jenigen, für die der uC nur Mittel zum Zweck > ist, die interessante Projekte umsetzen, ist am überflüssig. Grundkenntnisse in Assembler sind beim Debugging durchaus hilfreich. Man muss dafür nicht in Assembler programmieren können, sollte aber in der Lage sein, vom Compiler erzeugten Code leidlich lesen zu können.
:
Bearbeitet durch User
Hannes L. schrieb: > Schwachsinn, man muss ihn verstehen und auch anwenden können. Das ist jetzt nicht dein Ernst, oder? Der Befehlssatz ist vom Hersteller vorgegeben. Du kombinierst ihn, um daraus deinen Ablauf, deine Berechnungen, ... Zu erzeugen. Dafür musst die Befehle kennen, auswendig. Was gibt es beim add oder sub zu verstehen? Musst du ein + oder- auch verstehen? Macht doch bitte Selbstverständlichkeiten nicht so wichtig.
Verwundert schrieb: > Was gibt es beim add oder sub zu verstehen? Musst du ein + > oder- auch verstehen? Das kann aber einfacher oder komplizierter sein. AVR ist dahingehend (meist) ziemlich einfach lesbar, Cortex M0 ebenso. Wer die kennt, der kann zur Not auch MIPS Code einigermassen lesen, ohne sich allzu lange damit befassen zu müssen 8-Bit PICs hingegen verwenden eine Mnemotechnik und Zusammenhänge, sich nur Eingeweihten erschliessen. Die liegen damit ziemlich quer zum Rest der Welt und die Kenntnis anderer Akkumulator-Architekturen wie 8051 hilft auch nur begrenzt weiter.
:
Bearbeitet durch User
Und deshalb schreibt man einfach + in Hochsprache. Danke für das schöne Beispiel. Es zeigt, wie unsinnig am für die meisten ist.
Verwundert schrieb: > Die breite Masse der Hobbybastler braucht kein asm. mmhhh nö gerade weil asm so einfach ist und nur das ausführt was man eingibt, finde ich es genial. Vor allem als Anfänger sind die Randbedingungen recht klein gehalten im Gegensatz zu Hochsprachen. > Wer Spaß hat, sich > auf genau eine Archtektur zu versteifen, kann ja den Befehlssatz > auswendig lernen. Naja so viel unterschiede gibs dort nun auch nicht ob nu AVR, Pic, 8051 - Asm ganz ehrlich recht leicht zu erlernen und man muss sich nicht nur auf eine Achitektur versteifen.
Verwundert schrieb: > Und deshalb schreibt man einfach + in Hochsprache. Und ohne Nachzudenken vor und hinter diesem "einfachen" + ein float oder noch besser (weil genauer) ein double. Und dann wundert man sich, warum der uC so langsam ist. Ich hätte schon solche Bacheleranden und Masteranden. Und erst nachdem Ich die struktuellen Fehler mal aufgezeigt hatte und die behoben waren, war auf einmal sogar noch Rechenzeit für Anderes...
Du hast die ganzen Programme auf asm umgestellt? Wenn nicht, triffst du genau den Kern: Immer schön auf die Aufgabe konzentrieren und nicht aufs Werkzeug. Die Masse hier dürfte einen Akkuschrauber nutzen. Aber ein paar Prediger raten ab und schwören auf den mehrfach angeschliffenen Schraubendreher mit Holzgriff.
> Die Masse hier dürfte einen Akkuschrauber nutzen. Aber ein paar > Prediger raten ab und schwören auf den mehrfach angeschliffenen > Schraubendreher mit Holzgriff. Nein, Lothar meint nur, daß es gut wäre die Bits (beim Akkuschrauber) unterscheiden zu können. Meine Frau benutzt auch einen Akkuschrauber, wird aber nie den Unterschied zwischen Phillips und Pozi verstehen, da sie Schrauben nicht interessieren. Und jemand anderer die vermurksten Dinger ausbohren darf.
:
Bearbeitet durch User
Nina schrieb: > Ich habe bisher nur ein paar kleine Projekte mit einem Arduino Bausatz > gemacht um mich an das Gebiet ranzutasten und würde mich gerne weiter in > die Microkontroller Programmierung einarbeiten Dann bleib beim Arduino also AVR, den du schon hast, so lange er dir reicht. Der 8051 steckt zwar in vielen Systemen als embedded Chip drin (z.B. FTDI232R den die Leute hier so gern benutzen und der auch auf dem Arduino sitzt) aber wenn es keinen Grund gibt sich mit 8051 zu beschäftigen, versäumst du nichts. Und ARM Cortex STM sind zwar leistungsfähiger, aber wenn es nur um Leistungsfähigkeit geht tut es auch dein PC. Der AVR ist gut zum übrr, als Arduino über USB zu programmieren, und reicht für Vieles aus.
Carl D. schrieb: > Nein, Lothar meint nur, daß es gut wäre die Bits (beim Akkuschrauber) > unterscheiden zu können. > > Meine Frau benutzt auch einen Akkuschrauber, wird aber nie den > Unterschied zwischen Phillips und Pozi verstehen, da sie Schrauben nicht > interessieren. Genau das schreib ich doch: Hochsprache nehmen und sich um die Aufganstellung kümmern. Natürlich muss ich die Hochsprache können, wissen wie man den Akku lädt und die Bits tauscht. Und wer die falschen Bits nimmt, nimmt auch den falschen Schraubendreher. Ist also kein guter Vergleich.
MaWin schrieb: > Und ARM Cortex STM sind zwar leistungsfähiger, aber wenn es nur um > Leistungsfähigkeit geht tut es auch dein PC. Äpfel, Birnen.... Hmmmm. Aber egal, jeder hat so seine Meinung.
Warum soll man heute noch des kleine 1x1 und Kopfrechnen lernen, wo es doch Computer und Smartphones gibt?
Falk B. schrieb: > Warum soll man heute noch des kleine 1x1 und Kopfrechnen lernen, > wo es doch Computer und Smartphones gibt? Macht man ja auch nicht mehr. Die Kids fangen früher mit den Taschenrechnern an und die Dinger können viel mehr als früher. Eine ganz normale Entwicklung, wie bei den uC auch.
Ach ja, rechnest du noch alles mit Logarithmustabelle und Messschieber? Weil dem PC und Smartphone misstraust? Die App werden nicht in ASM geschrieben. ;-)
Verrwundert schrieb: > Falk B. schrieb: >> Warum soll man heute noch des kleine 1x1 und Kopfrechnen lernen, >> wo es doch Computer und Smartphones gibt? > > Macht man ja auch nicht mehr. Die Kids fangen früher mit den > Taschenrechnern an und die Dinger können viel mehr als früher. Nur die Kinder nicht ... :-^
Die Welt dreht sich weiter, mit euch, ohne euch und ASM hat an Stelkenweert verloren, wurde durch Hochsprachen ersetzt. Und nein, ich kann heute nicht mehr mit einem Rechenschieber umgehen. Ich habe auch nie vermisst.
Hallo, Verrwundert schrieb: > Ach ja, rechnest du noch alles mit Logarithmustabelle und > Messschieber? > Weil dem PC und Smartphone misstraust? Die App werden nicht in ASM > geschrieben. ;-) Man muß dem PC und dem Smartphone genauso mißtrauen können wie Logarithmustabelle und Rechenschieber. Man muß sich daran erinnern können, weshalb es sinnvoll ist einen Überschlag zu machen, die Fehlergrenzen einschätzen zu können usw. Genauso wie man auf einen kleinen AVR wie auf einen PC losgehen und dann weder Geschwindigkeit noch Speicherplatz reichen, genauso kann man eine tolle Formel in den Taschrechner tippen und dem Ergebnis blind vertrauen. Auf einem AVR ein wenig Assembler zu prgrammieren zeigt schnell, daß man eben auf diese Grenzen achten muß. Dann denkt man auch auf einem größeren und in C über Registergrößen und Speicherplatz und Geschwindigkeit nach. Ein 64 Bit Shift auf einem AVR in ASM ist keine Problem, in C mit dem GCC funktioniert es nur noch irgendwie. Ist für einen 8-Bitter auch eher eine Zumutung wie auch ein paar andere Sachen. Genau das trifft aber auf alle µC oder SoC zu. Man kann einen anderen nehmen, aber nicht wie beim PC einen schnelleren Prozessor und ein paar GB Ram mehr und dann das Programm einfach darauf laufen lassen. Wird heute aber gern gemacht. Dann gibt es TVs mit Reaktionszeiten im "Ewigkeitsbereich" oder Smartphones, die nach einem Update praktisch unbenutzbar werden, weil kritiklos jeder Unfug unbedingt noch ins System mußte. Gruß aus Berlin Michael
Wenn der AVR so klein ist, dass ich auf jede Zeile Code achten muss, dass ich die Befehle abzählen muss, dass ... Dann habe ich das falsche Design gewählt! Die gleiche Diskussion gab es bei der PC Programmierung, bei OOP, bei ...
Nina schrieb: > Oder spielt es keine Rolle? Managment summary: Spielt keine Rolle. Detailed explanation: Da Du anscheinend gerade anfängst ist jeder uC erst mal brauchbar. Sollte es irgendwann nicht mehr reichen, dann hast du aber mehr Erfahrung um Dir einen Anderen zu suchen. Erfahrungsgemäss reichen aber die "ollen Kamellen" ziemlich lange, wenn man (mit zunehmendem Wissen) die implementierten Lösungen optimiert. ASM oder nicht? Meiner Meinung nach sind Kenntnisse in Assembler für seriöse SW Entwicklung, zumindest im Embedded Bereich, unverzichtbar. Und auch ziemlich spannend. Am Ende des Tages sollte es Dir (als Hobby-Programmierer) aber est mal Spass machen. Und "falsch" geht da eigentlich fast garnicht. Grüße Andreas
Andreas H. schrieb: > Erfahrungsgemäss reichen aber > die "ollen Kamellen" ziemlich lange, Sind aber schwerer handzuhaben als modernere! (Darauf bezieht sich der Ausdruck)
Zum 8051 sollte man sich auch gleich noch einen Strick hinzubestellen. Die 8051 Architektur ist veraltet, die von AVR oder PIC doch schon ein Stueck neuer. Das erkennt man daran, dass schon der ASM Code sehr viel kompakter ist. Falls AVR, vergiss die Tiny, die sind fuer sehr hohe stueckzahlen. Als Bastler gewinnt man nichts, wenn man 1 Euro an einem controller spart.
> PIC doch schon ein Stueck neuer PICs sind aelter als Braunkohle. Zum Lernen und Kennenlernen ist der 8051 gut geeignet. Und: in vielen Consumergeraeten werkelt auch heute im Hintergrund ein 8051-Core der z.B. den Hardware-MPEG2- Dekoder konfiguriert und bei Laune haelt... Da wird man kaum PIC- oder AVR-Cores finden. Man macht also mit 8051 nichts grundsaetzliches verkehrt.
Verrwundert schrieb: > Andreas H. schrieb: >> Erfahrungsgemäss reichen aber >> die "ollen Kamellen" ziemlich lange, > Sind aber schwerer handzuhaben als modernere! (Darauf bezieht sich der > Ausdruck) Für Dich ist ja auch ein "+" einfach nur ein "+". Solange man die uC nur soweit einsetzt bis sie das erste Mal "warm" werden, ist man mit modernen uC natürlich länger auf der sicheren Seite. Aber wo bleibt da denn der Spass? Anyway. Der TO fängt gerade an. Da ist das was er schon hat genau das Richtige. Alles andere wäre mMn. Overkill. Grüße Andreas
Uli, der Wilde schrieb: > Zum 8051 sollte man sich auch gleich noch einen Strick hinzubestellen. > Die 8051 Architektur ist veraltet, die von AVR oder PIC doch schon ein > Stueck neuer. Immer wieder derselbe Käse der hier behauptet wird. Der PIC ist älter als der 8051. Diesmal ohne Beleg, ich bin zu faul sie zum zehnten Mal rauszusuchen, such selber. Und der ARM älter als der AVR, aber ich weiss, dass das nicht gefragt wurde.
MaWin schrieb: > Uli, der Wilde schrieb: >> Zum 8051 sollte man sich auch gleich noch einen Strick hinzubestellen. >> Die 8051 Architektur ist veraltet, die von AVR oder PIC doch schon ein >> Stueck neuer. > > Immer wieder derselbe Käse der hier behauptet wird. > > Der PIC ist älter als der 8051. > > Diesmal ohne Beleg, ich bin zu faul sie zum zehnten Mal rauszusuchen, > such selber. Ist ursprünglich von General Instruments - einer Firma, die zwischenzeitlich vom allseits beliebten Donald Rumsfeld geleitet wurde. Die Mikroelektroniksparte wurde abgespalten und nannte sich: Microchip... Den ersten PIC gab es auf jeden Fall schon 1977, den 8051 erst 1980. > Und der ARM älter als der AVR, aber ich weiss, dass das nicht gefragt > wurde. Der erst ARM kam so um 1983 rum.
MaWin schrieb: > Uli, der Wilde schrieb: >> Die 8051 Architektur ist veraltet, die von AVR oder PIC doch schon ein >> Stueck neuer. > > Immer wieder derselbe Käse der hier behauptet wird. > > Der PIC ist älter als der 8051. 8051 geb. 1980 PIC geb. 1976
@ Verrwundert (Gast) >> Warum soll man heute noch des kleine 1x1 und Kopfrechnen lernen, >> wo es doch Computer und Smartphones gibt? >Macht man ja auch nicht mehr. Die Kids fangen früher mit den >Taschenrechnern an und die Dinger können viel mehr als früher. Eine ganz >normale Entwicklung, wie bei den uC auch. Eine ganz normale Fehlentwicklung, in der Tat. Tasten drücken und blind dem Taschenrechner vertrauen, ohne zu wissen das da im Prinzip im mHintergrund abgeht. Das war zu meiner Zeit schon ein Problem, heute ist es das noch viel mehr. Nein, ich propagiere keinen Rechenschieber und auch kein ASM. Aber Grundlagenwissen!!!
Jeder Compiler erzeugt als Zwischenschritt Assembler. Und bisher brauchte ich diese Stufe bei jeder Architektur, weil bisher noch kein Compiler fehlerfrei war. Man kann Assembler ignorieren so wie man eine Dichtung im Wasserhahn auch ignorieren kann. Aber trotzdem ist er ganz alltäglich. Und wenns drauf ankommt ist es gut, zu wissen, wie man die Dichtung ersetzt... Verwundert schrieb: > Die Masse hier dürfte einen Akkuschrauber nutzen. Aber ein paar Prediger > raten ab und schwören auf den mehrfach angeschliffenen Schraubendreher > mit Holzgriff. Ich rate dazu, zu erkennen, für welche Aufgabe welche Schraube die richtige ist. Die stolzen Akkuschrauberbesitzer schrauben dann mangels weitergehenden Interesse alles mit ihren Spax zusammen, nur wiel sie nicht wissen, wofür die M10 Maschinenschrauben sind... Oder andersrum: wer nur einen Hammer kennt, für den sieht die ganze Welt wie ein Nagel aus.
Verwundert schrieb: > Du wirst nicht wünschen, dass die Werkstatt mit Ahnung ein Pleul > tauscht. Denn das möchtest du nicht bezahlen. Naja, ob das so viel teurer ist, als von jemandem, der keine Ahnung hat, sukzessive den halben Motor tauschen zu lassen, bis der Fehler weg ist? > Die breite Masse der Hobbybastler braucht kein asm. Wer Spaß hat, sich > auf genau eine Archtektur zu versteifen, kann ja den Befehlssatz > auswendig lernen. Es ist zwar ein gängiges rhetorisches Mittel, die Argumente des Gegners völlig zu übertreiben, um sie als absurd hinzustellen, aber man muss aufpassen, dass man sich damit nicht lächerlich macht. Es wurde bereits erwähnt, dass das, was du da schreibst, nicht nötig ist- > Für die jenigen, für die der uC nur Mittel zum Zweck ist, die interessante > Projekte umsetzen, ist am überflüssig. Das mag sein. Für viele ist der µC aber der Zweck. Sie haben Spaß daran, ihn zu programmieren und zu verstehen, was da unter der Haube passiert.
Hier im Forum kannst du gut erkennen wohin das führt. Die Jungs kennen nur avr und verteidigen die Dinger gegen alles und jeden. Vor einem halben Jahr gab es hier die cortex vs avr Threads. 32bit wurden als völlig überflüssig angesehen, nur was für Androiden und Co. und jetzt? Die Dinger sind hier total normal und finden immer mehr Interesse. Der avr zubehörkrams wird verkauft und man widmet sich moderner Technik. Aber wenn der Weg das Ziel ist ... Du müsstest dann aber einen echten Prozessor empfehlen, alles extern anschließen, damit man jede Einzelheit versteht. ???
Verwundert schrieb: > Hier im Forum kannst du gut erkennen wohin das führt. Die Jungs kennen > nur avr und verteidigen die Dinger gegen alles und jeden. Ich glaube da unterschätzt Du das Forum. Viele dürften das Problem haben, einige Sachen hier einfach nicht ausdiskutieren zu können, weil da irgendwann auch Firmeninteressen/Know-How ins Spiel komt. Darum halten sich die Leute da zurück und begrenzen sich nur auf das, was sie auch im Hobbybereich benutzen. Grüße Andreas
Nö, hier sind auch Profis unterwegs. Aber auch ganz viel Halbgares. Und es zählt ja nur was hier steht, nicht was einer vielleicht unter Umständen eventuell beitragen könnte, ...
Verwundert schrieb: > Die Jungs kennen nur avr und verteidigen die Dinger gegen alles und > jeden. Es bringt dann aber auch nichts, die ARM Cortex uC als alleiniges Allheilmittel anzupreisen. Oder gar für den Anfänger. Die kapieren ja schon den NVIC nicht... > Die Jungs kennen nur avr und verteidigen die Dinger gegen alles und > jeden. Ich brauchte letzthin einen uC, den man parasitär über einen 10k Pullup eines Eingangssignals versorgen konnte: ATtiny9 Und ich brauchte einen, der einfach ein Display ansteuern kann: STM32F4 Fazit: man nimmt den uC, der die Aufgabe am besten packt.
Verwundert schrieb: > Aber wenn der Weg das Ziel ist ... > Du müsstest dann aber einen echten Prozessor empfehlen, alles extern > anschließen, damit man jede Einzelheit versteht. ??? Genau darum gehts!!!!!!!!!!!!!!!!!!!! Um Wissen zu schaffen und es zu verstehen. Verwundert schrieb: > Hier im Forum kannst du gut erkennen wohin das führt. Die Jungs kennen > nur avr und verteidigen die Dinger gegen alles und jeden. nope hier kennen viele ne Menge mehr und nutzen, das was man einfach hand haben kann. Habe z.B damals mit AVR angefangen und in der Ausbildung musst PIC programmiert werden. Habe beides gerne ausprobiert und stellte fest das ein 16f... nicht das wahre ist mit irgendwelchen Umschaltungen. Also blieb ich beim AVR da dieser auf allen AVR's zu 95% ähnlich war. Und jetzt erklär mal wenn man diesen Vorteil für sich, nur für sich, erkannt hat nicht nutzen soll?? MMhhhh vllt sollte man gleich mit nem Smartphone anfangen denn da brauch ich nur in den Appstore gehen und mir das was ich brauche ziehen denn insten kann jeder.... Dat Mädel möchte aber tiefer in die Programmierung einarbeiten als wäre es definitv falsch mit Smartphones anzufangen wenn jegliche Grundlagen fehlen. UND NUR DARUM GEHTS!!!!!!!!!!!! GRUNDLAGEN LERNEN DIESE WERDEN EINEN NIVHT IN DIE WIEGE GELEGT.
Lothar M. schrieb: > Es bringt dann aber auch nichts, die ARM Cortex uC als alleiniges > Allheilmittel anzupreisen. Tja, du hast den GK eröffnet. Aber es geht nicht um: welchen uC für welches Projekt? Es geht um: Ich bin Anfänger, wie kann ich (heutzutage) problemlos einsteigen? Und da sind AVR nun mal nicht in der ersten Reihe. Das kannst du wunderschön hier im Forum erlesen. Durch deinen das Thema verfehlenden GK hast du jetzt die AVR-Lemminge geweckt. chris schrieb: > Habe beides gerne ausprobiert > und stellte fest das ein 16f... nicht das wahre ist mit irgendwelchen > Umschaltungen. Also blieb ich beim AVR da dieser auf allen AVR's zu 95% > ähnlich war. Er kennt nix ausser AVR, er kennt nicht die einfache Handhabung anderer moderneren uC und gibt großspurige Tipps für Anfänger, nicht nur in diesem Thread. Tolle Beratung! ;-(((
verwundert schrieb: > Er kennt nix ausser AVR, er kennt nicht die einfache Handhabung anderer > moderneren uC und gibt großspurige Tipps für Anfänger, nicht nur in > diesem Thread. > Tolle Beratung! ;-((( Achtung das ist eine persönliche Erfahrung jeder hat das Recht sich... nein falsch muss es selbst entscheiden. Doch 8051er ,Microchip, STM, Cortex, usw usf aber sie fragte explizit nach 8051 VS AVR und AVR bietet definitiv eine leichten Einstieg. Es ist doch egal mit welchen man vom Prinzip her anfängt, viel wichtiger ist die Erkenntniss nach der Einarbeitung das die Dinger unterm Strich irgendwie ähnlich aufgebaut sind und mit diesem Wissen würde ich mir auch zutrauen nen Cortex oder wie dat heißt zu programmieren. Aber als Hobby einfach ne Nummer zu groß. BERUFLICH würde ich eher dann schon auf 32bitter gehen aber auch dort müssen die Grundlagen sitzen und 8bit bietet eine verdammt übersichtliche Möglichkeit. Hinweis PIC musste ich troztdem programmieren ;) verwundert schrieb: > Es geht um: Ich bin Anfänger, wie kann ich (heutzutage) problemlos > einsteigen? > > Und da sind AVR nun mal nicht in der ersten Reihe. Das kannst du > wunderschön hier im Forum erlesen. ... und nochmal es geht um GRINDLAGEN.... W.S. schrieb: >>Claus M. schrieb: >> Dann schmeiße ich mal diesen hier in die Runde: STM32F030 > Aber nicht, um die Grundlagen zu erlernen. > > Der Tip mit dem 8051 ist schon ganz gut. Ebenfalls ganz gut - wenn auch > ein bissel "anders" sind die kleinen PIC's, also 16Fxyz. > > Bei beiden Architekturen kann man sehr gut die Grundlagen und Assembler > lernen. Das ist wichtig. > > Ja wichtig. > Man sehe sich in diesem Forum mal um: all diejenigen, die Probleme haben > mit dem Grundverständnis und sogar mit simpelsten Konstrukten in C sind > diejenigen, die noch nie ihre Nase mal in Assembler gesteckt haben. > Geschweige denn in die Manuals zu ihren Bastelobjekten. Es fehlen halt > die Grundlagen. > > Aber Maschinenbefehle und Assembler für ARM ist denn doch für den > Einstieg nicht das geeignetste. Ist zwar alles durchaus logisch > aufgebaut, aber dennoch für den Anfang zuviel. PUNKT W.S. hat damit alles gesagt. @verwundert mich würde mal interessieren wie dein Einstieg war Plattform/Sprache denn auch dein Wissen musstest du erlernen.
chris schrieb: > das ist eine persönliche Erfahrung Deine einzige Erfahrung, dir fehlen Vergleichsmöglichkeiten. chris schrieb: > wie dein Einstieg war > Plattform/Sprache Ich kenne noch die Zeiten der Emulatoren mit Bond-Out-Chip oder auch nur für ROM. Als die ersten Flash-Controller für die breite Masse kamen, gab es mehr Skeptiker als Befürworter: neuer Stapel an Tools (meist Kommandozeile), lange Lösch- und Programmierzeiten, begrenzte Programmierzyklen, ... Ist genau wie heute: Was anders (neu) ist, ist erst einmal schlecht. ;-)))
verwundert schrieb: > chris schrieb: >> das ist eine persönliche Erfahrung > Deine einzige Erfahrung, dir fehlen Vergleichsmöglichkeiten. Hä ließt du mal was durch??? Trollstatus wird höher.... Von dir kam bisher ja uch nischt gescheites > chris schrieb: >> wie dein Einstieg war >> Plattform/Sprache > Ich kenne noch die Zeiten der Emulatoren mit Bond-Out-Chip oder auch nur > für ROM. Als die ersten Flash-Controller für die breite Masse kamen, gab > es mehr Skeptiker als Befürworter: neuer Stapel an Tools (meist > Kommandozeile), lange Lösch- und Programmierzeiten, begrenzte > Programmierzyklen, ... > > Ist genau wie heute: Was anders (neu) ist, ist erst einmal schlecht. > ;-))) Die Kunst ist es, alt und neu optimal zu nutzen. Ab jetzt verfehlts die Aufgabenstellung.
chris schrieb: > ja uch nischt gescheites Ist das auch die Wertung deiner eigenen Beiträge? Dann sind wir uns doch einig. ;-)
Lothar M. schrieb: > Ich sage z.B. meinen daraufhin sichtlich schockierten > Praktikanten: ein "delay()" ist ein Programmfehler! Angenommen ich möchte ein einfaches 1602-LCD im 4-Bit-Parallel-Modus betreiben: Abgesehen davon, dass die korrekte Initialisierung eines Timers selbst für Datenblatt-Virtuosen einen Mehraufwand bedeuten dürfte, sehe ich hierdrin eine ziemliche Verschwendung der gegebenen Hardwareressourcen. Alles wird unnötig verkompliziert und unübersichtlicher. Sicher setzen die meisten "Arduino-Coder" die Funktion an den falschen Stellen zu falschen Zwecken ein, aber von pauschalisierenden Rundumschlägen würde ich trotzdem lieber Abstand nehmen.
Timer0 schrieb: > pauschalisierenden > Rundumschlägen Ist wie beim goto. Das endet hier persönlich. :-(
@ Timer0 (Gast) >Lothar M. schrieb: >> Ich sage z.B. meinen daraufhin sichtlich schockierten >> Praktikanten: ein "delay()" ist ein Programmfehler! Jaja, die liebe Schwarz-Weiß Malerei . . . >Sicher setzen die meisten "Arduino-Coder" die Funktion an den falschen >Stellen zu falschen Zwecken ein, aber von pauschalisierenden >Rundumschlägen würde ich trotzdem lieber Abstand nehmen. Me too! Auch ich nutze regelmäßig die "bösen" delay-Funktionen, allerdings dort, wo es sinnvoll und unkritisch ist. Einfaches Beispiel. Wenn ein Startbildschirm für ein paar Sekunden angezeigt werden soll, macht man das sicher NICHT mit einem Timer, denn die CPU hat in dem Moment so oder so nichts zu tun. Anderes Beispiel. Wenn man einen DMX-Datenstrom sendet, muss man immer wieder ein BREAK erzeugen. Das kann man mit einem Timer oder dem UART selber machen, muss man aber nicht. Ich habe dafür mehrfach ein _delay_us(100) genutzt, und das sogar in einem Timer-Interrupt!!! Jehova, Jehova!
> Ich habe dafür mehrfach ein _delay_us(100) genutzt, und das sogar > in einem Timer-Interrupt!!! Jehova, Jehova! _delay_us aus der AVRlibc läuft auch nur im Kreis, wärend die Arduino-Variant wohl per TimerInterrupt eine Variable hoch(runter) zâhlt. Das ist zwar etwas genauer, da keine ISR die Wartezeit verlängert, geht aber bei gesperrten INT's z.B. innerhalb einer ISR nicht.
Falk B. schrieb: > Jaja, die liebe Schwarz-Weiß Malerei . . . Wenn schon jedes Wort auf die Goldwaage gelegt werden muss, hier eine leicht überarbeitete Variante:
1 | Ein _delay_ms() im Programmablauf ist fast immer ein Programmierfehler. |
Oder andersrum:
1 | Neun von zehn _delay_ms() sind unnötig. |
Das waren dann auch genau die delay(), die ich den Praktikanten angekreidet und wegoptimiert habe. Es ist ja nicht "schlimm", wenn in der Initialisierung mal 50ms gewartet wird. Aber wenn sowas in jedem Durchlauf der Hauptschleife passiert, dann ist das nur kostspielige Rechezeitvernichtung. Wie? Das Programm hat gar keine Hauptschleife? Das ist in 99% der Fälle auch ein Programmfehler. Oder eher ein Konzeptfehler... > Me too! Auch ich nutze regelmäßig die "bösen" delay-Funktionen, > allerdings dort, wo es sinnvoll und unkritisch ist. Mir scheint, dir ist die Problematik eines delay() bekannt. Einigen anderen aber offenbar nicht, denn sonst käme nicht wöchentlich 2 mal die Frage nach dem "abbrechbaren delay()".
:
Bearbeitet durch Moderator
@ Lothar Miller (lkmiller) (Moderator) Benutzerseite >> Jaja, die liebe Schwarz-Weiß Malerei . . . >Wenn schon jedes Wort auf die Goldwaage gelegt werden muss, hier eine >leicht überarbeitete Variante: Nun ja, du bist ja auch bei anderen Dingen für ABsolutismen bekannt, ich sag nur Entkoppelkondensator . . . 8-0 >Ein _delay_ms() im Programmablauf ist fast immer ein Programmierfehler. >Neun von zehn _delay_ms() sind unnötig. Damit kann man sich schon eher anfreunden. ;-) >> Me too! Auch ich nutze regelmäßig die "bösen" delay-Funktionen, >> allerdings dort, wo es sinnvoll und unkritisch ist. >Mir scheint, dir ist die Problematik eines delay() bekannt. Gerade so. >Einigen anderen aber offenbar nicht, denn sonst käme nicht wöchentlich 2 >mal die Frage nach dem "abbrechbaren delay()". Was zumindest ICH mit dem immer gleichen, weil immer gültigen Hinweis auf den schönen Artikel Multitasking beantworte.
Lothar M. schrieb: > Wie? Das Programm hat gar keine Hauptschleife? Das ist in 99% der Fälle > auch ein Programmfehler. Oder eher ein Konzeptfehler... Nö. Bei Systemen mit (RT)OS gibt es entweder nur eine irgendwo im Scheduler o.ä. versteckte oder sogar gar keine echte Hauptschleife. Bei vielen Anwendungen mit kooperativem Multitasking sollte man es auch tunlichst unterlassen, auf Anwendungsebene Hauptschleifen zu implementieren, z.B. in SPS-Programmen.
Andreas S. schrieb: > z.B. in SPS-Programmen. Und gerade ein SPS Programm ist das Beispiel für eine Hauptschleife schlechthin. Dort wird nämlich das Programm an sich als Teil so einer Schleife ausgeführt. Und zwar möglichst schnell, ohne auf irgendwas zu warten (das nennt sich dann Zykluszeit). Natürlich darf man da nicht zusätzlich eine "eigene" Hauptschleife einführen, weil man dann ja das implizite Prozessabbild (Lesen und Schreiben der EA) komplett umgeht. Am besten gefällt mir hier, dass SPS Programmierer (oft ohne es zu wissen) mit Zustandsautomaten arbeiten (die heißen dann Merkerketten). Falk B. schrieb: > Nun ja, du bist ja auch bei anderen Dingen für ABsolutismen bekannt, ich > sag nur Entkoppelkondensator . . . 8-0 Es gibt für auch für Absolutismen eine Ausnahme. Allerdings muss man die dann auch jeweils gut begründen können. Und das kann man erst dann, wenn man den zugrunde liegenden Mechanismus verstanden hat. Man könnte z.B. Fahranfängern sagen: fahre nur auf geteerten Wegen! Wenn dann die letzten 100m unbefestigt sind, dann darf er die mit gutem Grund mal "ausnahmsweise" fahren um sein Ziel zu erreichen. Aber wenn er sofort nach dem Losfahren über den nächten Feldweg in einen Wald fährt, dann darf er sich nicht wundern, wenn es recht schnell holprig wird... ;-) Und mit dem Verstehen sind wir wieder beim 8051 und dem AVR: diese wenig komplexen Controller kann man noch relativ leicht überblicken und begreifen. Und wenn man die dann kapiert hat, dann kann man sich nach Großem recken und sich mal den Registersatz eines I.MX6 oder auch nur die DMA oder den NVIC eines ARM zu Gemüte führen.
Lothar M. schrieb: > Andreas S. schrieb: >> z.B. in SPS-Programmen. > Und gerade ein SPS Programm ist das Beispiel für eine Hauptschleife > schlechthin. Dann solltest Du mich nicht sinnentstellend zitieren! > Natürlich darf man da nicht > zusätzlich eine "eigene" Hauptschleife einführen, weil man dann ja das > implizite Prozessabbild (Lesen und Schreiben der EA) komplett umgeht. Genau. Bei einer S7 muss auch der OB1 einfach durchlaufen. > Am besten gefällt mir hier, dass SPS Programmierer (oft ohne es zu > wissen) mit Zustandsautomaten arbeiten (die heißen dann Merkerketten). Für SPS-Programme in SCL/ST haben wir uns ein paar Vorlagen für Zustandsautomaten gebaut, die dann in den meisten FB verwendet (und dann durch OB aufgerufen) werden. > Und mit dem Verstehen sind wir wieder beim 8051 und dem AVR: diese wenig > komplexen Controller kann man noch relativ leicht überblicken und > begreifen. Und wenn man die dann kapiert hat, dann kann man sich nach > Großem recken und sich mal den Registersatz eines I.MX6 oder auch nur > die DMA oder den NVIC eines ARM zu Gemüte führen. Einer meiner Favoriten für das Erlernen akkumulatorbasierter Architekturen/Befehlssätze wäre der Z80. Anschließend vergleicht man solch einen Ansatz mit registerbasierten Prozessoren. Ebenfalls sehr hilfreich ist zu späteren Zeitpunkten die Beschäftigung mit Prozessoren, die eine sehr strenge Trennung der Adressräume für Daten und Programme haben, d.h. Harvard-Archikturen. Die krasseste Ausprägung dieser Trennung hatte ich bei einem Philips PCB5011 erlebt, der vier separate Adressräume mit völlig voneinander getrennten externen Bussen hatte: Programm, X-Daten, Y-Daten, ROM-Koeffizienten. Für Programm und ROM-Koeefizienten gab es nicht einmal Schreibbefehle. Die Daten-Datenbusbreite betrug 16 Bit, die Programm-Datenbusbreite 40 Bit. Mit solch einem Prozessor konnte man nicht wirklich gut arbeiten, weswegen er wohl auch keine nennenswerte Verbreitung erzielt hat. Das grundlegende Konzept findet man aber wiederum in VLIW-Architekturen wieder, d.h. in einem Programmwort befanden sich sechs Befehle, die blockierungsfrei gleichzeitig ausgeführt wurden. NEIN, ich empfehle NICHT den Aufbau und die Programmierung eines PCB5011-basierten Rechners für jedermann!
:
Bearbeitet durch User
verwundert schrieb: > Es geht um: Ich bin Anfänger, wie kann ich (heutzutage) problemlos > einsteigen? > > Und da sind AVR nun mal nicht in der ersten Reihe. Das kannst du > wunderschön hier im Forum erlesen. Man muss bei solchen Aussagen wirklich "verwundert" sein. Du empfiehlst also einen µC zum Einstieg, der so komplexe Peripherie beinhaltet, und einen komplexen Befehlssatz hat, dass die notwendigen Dokus dazu schnell mehr als 500 Seiten ausmachen, dass alleine Errate Sheeets größer als 40 Seiten sind. Und das empfiehlst du als "Einstieg"?! Ich nehme an wenn dich eine verzweifelte Mutter fragt wie sie ihrem Sprössling in Mathe 4. Klasse helfen kann so dass er die Gymnasialempfehlung erhält, dann empfiehlst du ihr/ihm auch den Papula Band 1-3? Kopfschüttel
@Lothar Es gibt noch andere für den Einstieg bessere uC, moderner und einfacher handzuhaben. Perfekt für Anfänger, ohne Fallstricke, ... Aber wir drehen uns im Kreis. Der Andere schrieb: > Und das empfiehlst du als "Einstieg"?! Ja, kennst du überhaupt den MSP? Ich denke nicht. Und für ARM gibt es gute Einführungen. Warum hältst du die Neebees für so dumm, das ist nicht fair.
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.