Hallo liebe Forengemeinde, ich möchte mich mit Mikrocontrollern beschäftigen. Anfangen will ich mit Assemblerprogrammierung um den Aufbau des Chips kennen zu lernen. Meine Frage, ist es einfacher zB mit einem PIC10F222 oder einem PIC18Fxxxx zu beginnen? Ich frage weil das Datenblatt des PIC10 gerade mal 88 Seiten lang ist, das des PIC18F45K22 schon über 300 Seiten. Hat das etwas mit der komplexität der Programmierung zu tun oder sind das nur die zusätzlichen Features die der PIC10 nicht hat? Was ratet ihr mir, PIC10F zum Einstieg (für wirklich ganz simple sachen wie LED, Taster, ADC) oder PIC18F?
Klaus schrieb: > Hat das etwas mit der komplexität der Programmierung zu tun oder sind > das nur die zusätzlichen Features die der PIC10 nicht hat? Die ASM Programmierung und der Aufbau der CPU ist sehr ähnlich, der Unterschied liegt vor allem in der Peripherie. > Was ratet ihr mir, PIC10F zum Einstieg (für wirklich ganz simple > sachen wie LED, Taster, ADC) oder PIC18F? Ich würde eine PIC18 nehmen, ich habe mit dem 18F45k22 angefangen.
Schau dich mal hier um. So habs ich gelernt ;-) www.sprut.de
Mit dem PIC10 wirst Du einfach ständig an Grenzen stoßen. Nur 4/3 IO-Pins ist verdammte wenig, gerade für Anfänger. Und ein nur 2-level Stack läßt modulares Programmieren zum Albtraum werden. Interrupts hats auch keine.
Hallo Klaus, Eine Alternative wäre auch die Baureihe 16F16xx, z.B. PIC16F1826/1827 (DIL18). Der grundsätzliche Aufbau ist relativ übersichtlich. Dazu hat diese "enhanced" Typenreihe interessante Zusatzmodule (Pheripherie) wie z.B. "Capacitve Sense Modul" (z.B. Berührungssensoren) "Timer 1 Gate Control (z.B. Pulsweiten-/Frequenzmessung) Capture, Compare, PWM (CCP) Module usw. Die "kleinen" PICF10../PICF12 würde ich nicht zum Einstieg verwenden. Du kommst zu rasch an die Grenze der verfügbaren Eingangs/Ausgangs-Pins. Ein LCD im 4Bit-Mode braucht ja schon 4 Datenleitungen + 3(2) Steuerleitungen, also mindestens 6 Pins. Natürlich ist das auch mit 2Pins machbar, aber dann gehörst Du schon nicht mehr zu den Einsteigern (:-). Du kannst Dich ja Schritt für Schritt nach Deinem Gutdünken einarbeiten. Zusätzlich möchte ich Dir die Anschaffung des Programmiergerätes PICkit3 von microchip empfehlen. Dann bist Du für alle Pics ab 10F - 45F und mehr gerüstet. P.S: Schau Dich auch mal beim PIC-Guru "sprut" um: [http://www.sprut.de/electronic/pic/allgemein/allgemei.htm] Viel Spass beim Einstieg! mfG Ottmar
Ich würde auch einen PIC18 oder einen von den neuen PIC16Fxxxx (4-stellige Endung) empfehlen. Die 18FxxK22 sind sehr vielseitig, benutzen wir für unsere Studenten im Labor auch (18F2xK22). Kannst ja mal [http://www.hs-ulm.de/wir/Personal/PersonalSaSchr/vschilli/Mikrocontroller/] schauen, vielleicht findest du es nützlich ...
:
Bearbeitet durch User
Peter D. schrieb: > Mit dem PIC10 wirst Du einfach ständig an Grenzen stoßen. > ... Interrupts hats auch keine. Der 10F32x schon. (Gibt best. noch andere)
Klaus schrieb: > Hallo liebe Forengemeinde, ich möchte mich mit Mikrocontrollern > beschäftigen. Anfangen will ich mit Assemblerprogrammierung um den > Aufbau des Chips kennen zu lernen. Meine Frage, ist es einfacher zB mit > einem PIC10F222 oder einem PIC18Fxxxx zu beginnen? Meine persönliche Meinung dazu ist: weder noch. Wenn es wirklich Assembler sein soll, dann ist jede andere Architektur besser für den Einstieg als ausgerechnet die 8-Bit PICs. Ich werfe mal so in die Runde: Z80, 6502, 8051, 68HC11, STM6, STM8 und natürlich die "Haus" Architektur dieses Forums: Atmel AVR. Wenn es PICs sein sollen, dann gleich PIC24 oder PIC32 (ist MIPS). Überhaupt wäre zu überlegen ob du nicht besser die 8-Bit Architekturen überspringst. Denn wenn du jetzt erst einsteigst, wirst du ja vielleicht deren Ableben erleben. Die im Moment zukunftsträchtigste Architektur wäre dann wohl Cortex M. Fang z.B. mit einem Cortex M0 an. Nachtrag: mein hartes Urteil über die 8-bittigen PICs ist explizit an die Programmierung in Assembler geknüpft. Ein C-Compiler hält die Schmerzen dann auch wieder in Grenzen.
:
Bearbeitet durch User
Axel S. schrieb: > Wenn es wirklich > Assembler sein soll, dann ist jede andere Architektur besser für den > Einstieg als ausgerechnet die 8-Bit PICs. Mir haben damals die 8051 sehr gut gefallen. Die haben sehr schöne Befehle für effizienten Tabellenzugriff, Zählschleifen, Vergleiche, Bitbefehle, MUL, DIV usw. Wir haben dann später nen C-Compiler gekauft (Keil C51) und da habe ich gestaunt, wie effizient der war und wie gut der 8051 für C optimiert war. Die PIC habe ich mir später mal angesehen. Da ich aber schon den 8051 kannte, waren mir die PIC viel zu kompliziert und umständlich (RETLW, PCLATH, Bankumschaltung usw.).
:
Bearbeitet durch User
Oh no, jetzt kommen wieder endlos irgendwelche Stories, wer wann weshalb und mit welchen tollen Controller alles schon gemacht hat :-(
Ich teile die Ansicht, dass das einfachste ein PIC24 ist. Schöne Architektur, leistungsfähige Peripherie und keine Altlasten. Keine Trennung von Programm- und Datenadressraum (gibts zwar, macht aber der Compiler für Dich). Und: die Familie beginnt bei 14 Pinnern und endet bei 144 Pinnern. fchk
Volker S. schrieb: > Oh no, jetzt kommen wieder endlos irgendwelche Stories, wer wann weshalb > und mit welchen tollen Controller alles schon gemacht hat :-( Fakt ist daß für einen Einsteiger und Assembler ein 8-Bit PIC eine absolut dämliche Wahl ist. Etwa so als würde man jemandem der Fahrrad fahren lernen will, ein Einrad empfehlen. Oder jemandem der das Jonglieren lernen will, eine Hand auf dem Rücken festbinden. Dazu kommt dann noch, daß das was er auf einem PIC16 oder PIC18 lernt, nirgendwo sonst mehr einsetzen kann. Denn keine andere Architektur, auch nicht von Microchip ist mehr derartig umständlich und verwickelt (um das Wort häßlich zu vermeiden) wie die 8-Bit PICs. Die einzige Erklärung die mir dazu einfällt wenn jemand die kleinen PICs verteidigt, ist daß er noch keine andere Architektur gesehen haben kann.
Axel S. schrieb: > Denn keine andere Architektur, auch > nicht von Microchip ist mehr derartig umständlich und verwickelt Ach, wenn man sich erst mal dran gewöhnt hat ;-) Ne, nenne doch einfach mal ein konkretes Beispiel und warum das unbedingt und auch auf jeden Fall anders besser ist ... <edit> NEIN bitte lass es! Dafür sollten wir besser einen eigenen Thread aufmachen als diesen hier auf die übliche Weise voll zu müllen. </edit>
:
Bearbeitet durch User
Wow vielen Dank für die vielen verschiedenen Meinungen, Ich habe kein Problem damit die Finger von den 8 Bittern zu lassen. Sollte ich dann auch lieber die Finger von den 8Bit AVRs lassen?
Für kleine Projekte reichen die 8-bit PICs leicht, für etwas größere vllt. auch und wenn nicht mehr kannst du mit dem PICkit3 auch noch 16- und 32-bit programmieren. Wenn man das µC Programmiren mal bei einer Architektur mal verstanden hat, ist es auch nicht schwierig auf eine Andere zu wechseln.
Klaus schrieb: > Wow vielen Dank für die vielen verschiedenen Meinungen, Ich habe > kein > Problem damit die Finger von den 8 Bittern zu lassen. Sollte ich dann > auch lieber die Finger von den 8Bit AVRs lassen? Eigentlich ist es egal, was du nimmst. Die 8bit uCs werden einige Zeit mehr als gut genug für dich sein. Andererseits kosten 16/32 Bit uCs auch icht wirklich mehr. Nur die wirklich kleine Teile mit ganz wenigen IOs würde ich für den Anfang nicht empfehlen. Die nimmst du dann, wenn es einen Grund dafür gibt ...
Hallo Klaus, ich hab' vor einigen Monaten wie du auch vor dem (Wieder-) Einstieg in die Programmierung mit einem PIC gestanden, und bin dann bei dem "PICkit low Pin Count Demo Board" von Microchip gelandet. Das enthält eine Fertigplatine (und 3 Leerplatinen) und zwei µCs, die dort eingesetzt werden können. Der eine ist ein PIC18F14K22, also ein 8-bitter. Der ist nicht nur für den Anfang sehr gut, der kann schon eine ganze Menge. Zudem brauchst du dann noch das schon oben empfohlene Prog.gerät PICkit3. Am allerwichtigsten für Anfänger ist aber was ganz Anderes, nämlich ein vernünftiges Tutorial, das einem einen Weg durch den Anfangs-Dschungel weist. Da gibts bei Microchip als kostenlose Beigabe für das o.g. Demo-Board eine Einführung mittels 13 Lektionen. Vom ganzen einfachen Einschalten einer LED bis zum Tableread hin. Jede der 13 Lektionen enthält eine recht ausführliche Darstellung und Erklärung des jeweiligen Lernstoffes, und dann - tusch - jedes der 13 Programme ist sowohl in Assembler als auch in C vorrätig und wird erklärt. Ein besseren Einstieg wirst du nicht finden. Das ist zwar - wie so häufig - "nur" in Englisch verfasst, aber das ist selbst für Schlecht-Englischkenner wie mich sehr gut zu lesen. Das Demo-Board mit den CPUs kostet so irgendwas um die 30 € rum. Wenn man das durch hat, weiß man, dass es auch mit dem vierfachen Preis korrekt bezahlt wäre. Das erspart eine irre Such- und Irrtumszeit in den Tiefen des Inet. Wenn du dir selbst einen großen Gefallen erweisen willst, wählst du diesen Weg und ersparst dir dabei unglaublich viele Irrungen, und kommst durch die leichten Beispiele schnell zu ersten Erfolgen. Grüße, wilhelmT
:
Bearbeitet durch User
Ja es spricht schon viel dafür ein gutes Tutorial durchzuarbeiten, vor allem wenn es vom hersteller selbst kommt. Gibt es denn auch eines für die PIC24? ARM Cortex Platinen sehen ziemlich kompliziert aus, ich möchte zumindest am Anfang nut den Chip und ganz wenig Bauelemente drumherum (wie es zb im avr tutorial der fall ist), ich möchte das "drumherum" verstehen.
Ein ganz gutes Buch ist http://www.amazon.de/Programming-16-Bit-PIC-Microcontrollers-Learning/dp/1856178706 fchk
Welchen PIC24F würdet ihr denn empfehlen? Ich möchte alles was im AVR-Assembler-Tutorial enthalten ist mit dem PIC machen.
Klaus schrieb: > Welchen PIC24F würdet ihr denn empfehlen? Ich möchte alles was im > AVR-Assembler-Tutorial enthalten ist mit dem PIC machen. Ich habe jetzt nur kurz das Inhaltsverzeichnis überfolgen, der PIC24F32KA302 scheint mit geeignet. Ist auch im THT verfügbar und es gibt, sollte 3.3V aus irgendeinem Grund unpassend sein, auch eine 5V Version.
Klaus schrieb: > Ich möchte alles was im > AVR-Assembler-Tutorial enthalten ist mit dem PIC machen. Tutorial und Controller sollten schon bestmöglich aufeinander abgestimmt sein. Also wenn du schon ein Tutorial ausgesucht hast, dass dir besonders gut gefällt, dann nimm das und den Controller der dazu passt! Natürlich kann man mit etwas Erfahrung alles leicht übertragen, aber für den Anfang bedeutet das nur unnötige zusätzliche Probleme.
:
Bearbeitet durch User
@ Marius Jetzt weiß ich nicht, ob du dich auch als Anfänger in der Programmierung sehen würdest. Wäre das der Fall, rate ich dir davon ab, sofort mit einem 16-Bitter und dann auch noch in C loslegen zu wollen. Genau diese Absichten hatte ich bei meinem Wiedereinstieg vor einigen Monaten auch. Aber die PIC-16-Bitter sind erheblich leistungsfähiger als die 8-Bitter. Das klingt zunächst erfreulich, ist für Anfänger aber ein erheblicher Nachteil, weil damit natürlich einhergeht, dass sie auch deutlich komplexer sind. Im 16-bit-Bereich ist z.B. der Assembler deutlich aufwendiger ausgelegt. Und C gleich am Anfang mal so eben "fix mit zu lernen", sollte wohlüberlegt sein. Wird sicher individuell unterschiedlich sein, ich bin da bescheidener geworden, und hatte mich sowohl von C als auch von dem erstrebten PIC24F verabschiedet. Dieser einfachere Weg war deshalb besser, weil ich da deutlich schneller zu ersten Erfolgen gekommen bin. Zudem bin ich sicher, dass ein späterer Umstieg in die 16-bit-Welt und auch das angestrebte Ziel, C zu lernen, sich nun deutlich einfacher erreichen läßt, als am Anfang gleich alles auf einmal zu wollen. Gruß, wilhelmT
:
Bearbeitet durch User
Be T. schrieb: > Jetzt weiß ich nicht, ob du dich auch als Anfänger in der Programmierung > sehen würdest. Wäre das der Fall, rate ich dir davon ab, sofort mit > einem 16-Bitter und dann auch noch in C loslegen zu wollen. Das Argument leuchtet mir überhaupt nicht ein. Gerade in C ist es weitgehend egal, ob man eine 8-, 16- oder gar 32-bittige Architektur hat, weil der Compiler einen von den Interna weitestgehend abschirmt. Gut, ein int mag einmal 16 und das andere mal 32 Bit lang sein. Aber das ist ja ein generelles Problem bei C. Wenn man einen Datentyp einer bestimmten Breite braucht, dann nimmt man halt einen Typ bei dem die Breite fest ist. Z.B. ist uint32_t überall 32 Bit breit. Auch auf einem 8-Bitter. Und der C-Code um mit uint32_t zu rechnen, zu vergleichen etc. sieht auch überall gleich aus. Auch in Assembler ergibt die Argumentation nur bedingt Sinn. Z.B. ist ein PIC24F in Assembler wesentlich einfacher zu programmieren als ein PIC16. Weil er eine hinreichende Anzahl Register hat und sinnvolle Adressierungsarten und einen relativ orthogonalen Befehlssatz. Daß der PIC24 ein 16-Bitter ist, bemerkt man nur daran, daß es Opcodes gibt die spezifisch nur auf 8 Bit operieren (z.B. MOV.B) statt defaultmäßig auf 16-Bit Worten. Das einzige Argument wäre die Komplexität der Peripherie. Aber auch da ist es kein Naturgesetz, daß ein 16-Bitter mehr und komplexere Peripherie als ein 8-Bitter haben müßte.
Gut ich denke dann wähle ich die AVRs aufgrund des vorhandenen Assembler-Tutorials und C-Tutorials, und der großen Community. Ich hoffe nur, dass das Tutorial von Spezialisten geschrieben wurde und ich somit nichts falsches lerne :-) (sorry, dass ich das so sage) Wenn ich die Architektur des AVRs verstanden habe, bin ich bestimmt in der Lage auch mit einem PIC zu experimentieren und dann meine Entscheidung entgültig zu treffen. Was meint ihr?
Klaus schrieb: > Was meint ihr? Ich mein, dass du da nicht viel falsch machen kannst. Persönlich kommt mir die Entwicklungsumgebung für PICs zwar einfacher vor aber das kommt bestimmt zu 90% nur daher, dass ich mich schon ewig damit beschäftige ;-)
Peter schrieb: > Ich würde beim PIC24 bleiben. Ich auch. Der PIC24 ist DEUTLICH leistungsfähiger als AVR.
Klaus schrieb: > Gut ich denke dann wähle ich die AVRs aufgrund des vorhandenen > Assembler-Tutorials und C-Tutorials, und der großen Community. Ich hoffe > nur, dass das Tutorial von Spezialisten geschrieben wurde und ich somit > nichts falsches lerne :-) (sorry, dass ich das so sage) > > Wenn ich die Architektur des AVRs verstanden habe, bin ich bestimmt in > der Lage auch mit einem PIC zu experimentieren und dann meine > Entscheidung entgültig zu treffen. > > Was meint ihr? Es ist letztendlich egal. Jede Architektur hat ihre Fallstricke. Beim AVR hast Du das Problem, dass Du bei den kleineren Chips nicht vernünftig debuggen kannst, heißt: Du kannst Dir Register, Flags und Speicher im Betrieb nicht anschauen und ändern. Die billigen Programmer können nur Programmcode hineinschießen, und das wars. Und DU wirst mit Sicherheit einige AVRs "verfusen", d.h. die Fuses so falsch einstellen, dass das Ding nicht mehr startet und Du mit Deinem Billigprogrammer da nicht mehr draufkommst und den Chip wegwerfen wirst. Bei PIC (egal ob 8, 16 oder 32 Bitter) wirst Du unweigerlich darüber stolpern, dass Du die IO-Pins mit Analogfunktionen zunächst auf digital stellen musst. Das ist hier einer der typischen Anfängerfehler. Den macht man einmal, zweimal, und dann weiß man es. Dafür kannst Du Dich bei PICs nicht aussperren, egal wie doof Du Dich anstellst. Und auch die kleinen Chips sind mit einem PicKIT3 debugbar. Und wenn Du das einmal kennst, willst Du diese Möglichkeit nicht mehr hergeben. Glaube es mir. Aber wenn Du eine Architektur kennst, brauchst Du für die nächste nicht mehr so lange. Ich habe Anfang der 80'er etwa ein 3/4 Jahr gebraucht, bis ich den Z80 verstanden hatte. Den 6502 habe ich dann zwei Jahre später in 6 Wochen gelernt, und zwar so weit, dass ich im Kopf assemblieren und nur noch Hex-Bytes in den Rechner tippen musste. fchk
Die 10Fxxx sind im Prinzip die Ultra-Reduktion des Mikrocontrollers. In Assembler realisiert man einfache Logik (Bitschubsen) tatsächlich einfacher als in C. 10Fxxx mit ASM-Programmen sind also ideal geeignet für: - "Tastendruck-Simulatoren" in vorhandenen Geräten - TTL-Logik-Ersatz wenn's nicht auf Geschwindigkeit ankommt - Zusätzliche Sicherheitsmechanismen (ein 10Fxxx in ASM kann bei korrektem Programm nicht "abstürzen" und es gibt keine Library-Bugs) - Einfache Aufgaben wie PWM-Generierung, Tonerzeugung, usw... .... Alles andere würde ich heute mit einem 32-Bit Mikrocontroller in C lösen und die Ultra-Low-Level Aufgaben eben an 10Fxxx/16Fxxx delegieren.
Frank K. schrieb: > Und auch die > kleinen Chips sind mit einem PicKIT3 debugbar. Und wenn Du das einmal > kennst, willst Du diese Möglichkeit nicht mehr hergeben. Glaube es mir. Ja, Debug-Mmöglichkeit wäre für mich ein MUSS. Vor kurzem habe ich mich mal nach Atmel Tools umgeschaut. Der ATMEL-ICE scheint mir ähnliche Features in vergleichbarer Preisklasse zu bieten wie ein PICKIT3. Kann das einer bestätigen ?
> Wenn ich die Architektur des AVRs verstanden habe, bin ich bestimmt in der Lage auch mit einem PIC zu experimentieren Nachdem du den AVR verstanden hast, wirst du die 8bit PICs nicht mehr mögen. Ich hatte vor Urzeiten mit 6800 und 68HC11 angefangen. Wenn man dann zu AVR wechselt fällt das einem leicht. Wenn man dann sich mal PIC8 vornimmt, dann kommt einem das Grausen. Die PIC8 haben eine dermaßen verkorkste Architektur, daß man die nur lieben kann, wenn man nichts anderes vorher gesehen hat. Nicht umsonst hat einer der Vorredner PIC24 vorgeschlagen. Die haben eine vernünftige Architektur.
Helmut S. schrieb: > Wenn man dann sich mal PIC8 > vornimmt, dann kommt einem das Grausen. Du bist jetzt schon der zweite. Was genau ist das Problem ?
Volker S. schrieb: > Ja, Debug-Mmöglichkeit wäre für mich ein MUSS. Ja, der ATMEL-ICE kann sie alle programmieren und debuggen, vom ATtiny4 (PIC10 pinkompatibel) über ATmega, xmega bis zu den Atmel Cortex.
Peter D. schrieb: > Ja, der ATMEL-ICE kann sie alle programmieren und debuggen, vom ATtiny4 > (PIC10 pinkompatibel) über ATmega, xmega bis zu den Atmel Cortex. OK, vielen Dank! Wenn ich das nächste mal was bei Mouser oder Digikey bestelle und nicht auf einen Versandkosten freien Betrag komme, werde ich mir wohl so ein Teil ohne Gehäuse mit bestellen. Bisher liegt hier nur so ein ELAB-ISP Teil rum, das ich aber schon ewig nicht mehr benutzt habe.
Volker S. schrieb: > Helmut S. schrieb: >> Wenn man dann sich mal PIC8 >> vornimmt, dann kommt einem das Grausen. > > Du bist jetzt schon der zweite. Was genau ist das Problem ? Das erste was mir aufstößt ist die fehlende Registerbank, fehlende 16bit Index-Register und der fehlende Stackpointer der ins RAM zeigt. So ein limitierter Hardwarestack im PIC8 ist schon eine ziemliche Einschränkung. Außerem diese unselige Bankaufteilung nur um im Befehlswort ein paar Bits zu sparen. Da schlepepn sie halt die ganzen Altlasten mit.
Axel S. schrieb: >....weil der Compiler einen von den Interna weitestgehend abschirmt. "Assembler ist für den Einstieg "von der Pike auf" am besten geeignet. Nur wenn man Assembler anwendet, lernt man den Aufbau eines Mikrocontrollers richtig kennen und kann ihn dadurch besser nutzen." Vorstehendes ist ein Zitat aus dem hier im Forum eingestellten AVR-Tutorial. > ein PIC24F in Assembler wesentlich einfacher zu programmieren als ein > PIC16. Das sehe ich komplett anders. Mit dem Assembler für den PIC18 komme ich nach dem Microchip-Tutorial bestens zurecht. Ein Blick in das Instruction Set für den 16-Bitter erzeugt ehrfürchtiges Staunen. Das ist um Etliches komplizierter. > Weil er eine hinreichende Anzahl Register hat und sinnvolle > Adressierungsarten und ...... Das wird wohl so sein. Aber ein Anfänger, und davon reden wir hier, kann überhaupt nichts mit Programmen anfangen, die länger sind als wenige Zeilen. Der Blick in das AVR-GCC-Tutorial führte auch zu diesem Zitat: "Dieses Tutorial soll den Einstieg in die Programmierung von Atmel AVR-Mikrocontrollern in der Programmiersprache C mit dem freien C-Compiler avr-gcc aus der GNU Compiler Collection (GCC) erleichtern. Vorausgesetzt werden Grundkenntnisse der Programmiersprache C." Verstehe! Bevor man dieses GCC-Tutorial benutzen kann, soll man also Grundkenntnisse in C vorweisen. Das klingt für mich alles andere als anfängerfreundlich. Das Microchip-Tutorial, mit dem man den PIC18F14K22 quasi gleichzeitig in Assembler und C programmieren lernen kann, ist um ein Vielfaches übersichtlicher und einfacher. Und ein Anfänger braucht nichts Leistungsfähiges, sondern etwas, dass einen klaren Weg aufweist, und vor allem zu schnell umsetzbaren Erfolgen führt. Diese Tutorial ist meine klare Empfehlung. Grüße, wilhelmT
Peter D. schrieb: > Volker S. schrieb: >> Ja, Debug-Mmöglichkeit wäre für mich ein MUSS. > > Ja, der ATMEL-ICE kann sie alle programmieren und debuggen, vom ATtiny4 > (PIC10 pinkompatibel) über ATmega, xmega bis zu den Atmel Cortex. Debuggen aber nur die, die auch debugfähig sind. Der bei Bastlern so beliebte Mega8 ist es zB nicht. Und Debugwire habe ich einmal gemacht. Was war das für ein Gewürge. fchk
Helmut S. schrieb: > Das erste was mir aufstößt ist die fehlende Registerbank, fehlende 16bit > Index-Register und der fehlende Stackpointer der ins RAM zeigt. So ein > limitierter Hardwarestack im PIC8 ist schon eine ziemliche > Einschränkung. Außerem diese unselige Bankaufteilung nur um im > Befehlswort ein paar Bits zu sparen. Da schlepepn sie halt die ganzen > Altlasten mit. Wofür braucht man eine Registerbank wenn direkter Zugriff auf ALLE Register möglich ist ? Ist die Indirekte Adressierung nicht 16-Bit ? Der "limitierte Hardwarestack" (16 Level) sollte für einen 8-Bit doch ausreichen. OK, die BANKS (und bei den kleinen die PAGES ;-) Na ja, als meine Programme so umfangreich wurden, dass ich darauf achten musste, bin ich sowieso gerade nach C umgeschwenkt. Jetzt soll sich der Compiler darum kümmern.
Frank K. schrieb: > Peter D. schrieb: >> Volker S. schrieb: >>> Ja, Debug-Mmöglichkeit wäre für mich ein MUSS. >> >> Ja, der ATMEL-ICE kann sie alle programmieren und debuggen,... > > Debuggen aber nur die, die auch debugfähig sind. Der bei Bastlern so > beliebte Mega8 ist es zB nicht. Es gibt doch auch genug PICs ohne integriertes ICD. Viele von denen mit kleiner Pinanzahl, weil es da wohl keinen großen Sinn macht, wenn nur noch die Hälfte übrig bleibt, wenn man die für's Debuggen abzieht.
Volker S. schrieb: > Frank K. schrieb: >> Peter D. schrieb: >>> Volker S. schrieb: >>>> Ja, Debug-Mmöglichkeit wäre für mich ein MUSS. >>> >>> Ja, der ATMEL-ICE kann sie alle programmieren und debuggen,... >> >> Debuggen aber nur die, die auch debugfähig sind. Der bei Bastlern so >> beliebte Mega8 ist es zB nicht. > > Es gibt doch auch genug PICs ohne integriertes ICD. Viele von denen mit > kleiner Pinanzahl, weil es da wohl keinen großen Sinn macht, wenn nur > noch die Hälfte übrig bleibt, wenn man die für's Debuggen abzieht. Für viele gibts dann Header, wo dann ein kompatibler debugfähiger Prozessor drauf ist.
Frank K. schrieb: > Für viele gibts dann Header, wo dann ein kompatibler debugfähiger > Prozessor drauf ist. Schon, ich habe auch welche hier (für 18F1xK50 und 16F688). Mit etwas Basteln bekommt man die dann auch irgendwie an ein SSOP Layout hingemurkst ...
Be T. schrieb: > Das Microchip-Tutorial, mit dem man den PIC18F14K22 quasi gleichzeitig > in Assembler und C ... > Diese Tutorial ist meine klare Empfehlung. > Grüße, wilhelmT Wie schön, dass du den ganzen Frust vom Anfang schon vergessen hast ;-)
Helmut S. schrieb: > Volker S. schrieb: >> Helmut S. schrieb: >>> Wenn man dann sich mal PIC8 >>> vornimmt, dann kommt einem das Grausen. >> >> Du bist jetzt schon der zweite. Was genau ist das Problem ? > > Das erste was mir aufstößt ist die fehlende Registerbank, fehlende 16bit > Index-Register und der fehlende Stackpointer der ins RAM zeigt. So ein > limitierter Hardwarestack im PIC8 ist schon eine ziemliche > Einschränkung. Außerem diese unselige Bankaufteilung nur um im > Befehlswort ein paar Bits zu sparen. Da schlepepn sie halt die ganzen > Altlasten mit. Ich wuerde allen Pic-Meckerfritzen hier empfehlen sich direkt mit Microchip in Verbindung zu setzen und dort mal ordentlich auf den Tisch hauen. Gleichzeitig eigene Wuensche und Ideen bei der Prozessorgestaltung zum Besten geben und allen dort anwesenden Technikern,Entwicklern,Ingenieuren,Mathematiker etc. - kurzum allen Diletanten - deutlich zu verstehen geben,dass sie von nichts ne Ahnung haben. Obendrein sollten sie sofort eine Rueckrufaktion aller schon abermillionen existierenden Pics in Aktion setzen und sich vom uC-Business verabschieden.
> Ich wuerde allen Pic-Meckerfritzen hier empfehlen sich direkt mit
Microchip in Verbindung zu setzen und dort mal ordentlich auf den Tisch
hauen.
Das macht bei PIC8 keinen Sinn, da Microchip die Kompatibilität zu den
Vorgänerchips erhalten muss da sonst die bisherigen PIC8 Anwender
abspringen.
Be T. schrieb: > Axel S. schrieb: >>....weil der Compiler einen von den Interna weitestgehend abschirmt. > > "Assembler ist für den Einstieg "von der Pike auf" am besten geeignet. > Nur wenn man Assembler anwendet, lernt man den Aufbau eines > Mikrocontrollers richtig kennen und kann ihn dadurch besser nutzen." Und wo ist da der Widerspruch zu dem was ich geschrieben habe? Ein PIC24 ist in C genauso leicht bzw. schwer wie ein PIC16 und in Assembler tendenziell leichter. Be T. schrieb: > ... rate ich dir davon ab, sofort mit > einem 16-Bitter und dann auch noch in C loslegen zu wollen. >> ein PIC24F in Assembler wesentlich einfacher zu programmieren als ein >> PIC16. > Das sehe ich komplett anders. Mit dem Assembler für den PIC18 komme ich > nach dem Microchip-Tutorial bestens zurecht. Ein Blick in das > Instruction Set für den 16-Bitter erzeugt ehrfürchtiges Staunen. Das ist > um Etliches komplizierter. Das scheint nur so. Zum Programmieren ist der Befehlssatz des PIC24 wesentlich einfacher. Klar sind es mehr Mnemonics. Aber dafür machen die auch mehr. Das meiste der scheinbaren Komplexität kommt durch die Addressierungsarten. Dabei ist genau dieser Teil auch wieder kinderleicht, denn weil der Befehlssatz so schön orthogonal ist, kann man jeden Basis-Menmonic (z.B. ADD) mit jeder Addressierungsart verwenden. Man braucht gar nicht jede Kombination auswendig zu lernen. Aber um die Schönheit eines solchen Ansatzes würdigen zu können, muß man ihn erstmal gesehen und am besten angefaßt haben. Ich hatte insofern wohl mehr Glück als du, daß ich mit dem Z80 sozialisiert worden bin und nicht mit einem PIC16. >> Weil er eine hinreichende Anzahl Register hat und sinnvolle >> Adressierungsarten und ...... > Das wird wohl so sein. Aber ein Anfänger, und davon reden wir hier, kann > überhaupt nichts mit Programmen anfangen, die länger sind als wenige > Zeilen. Aha. Und soll er für ewig Anfänger bleiben oder was? Mal ganz davon abgesehen daß funktionsgleiche PIC24 Programme eher kürzer sind als PIC16 Programme. Weil man sich den ganzen Mist mit Bankumschaltung etc. spart. Das Gehampel mit PCLATH oder mit FSR/INDF. usw. usf.
Toxic schrieb: > Ich wuerde allen Pic-Meckerfritzen hier empfehlen sich direkt mit > Microchip in Verbindung zu setzen Wozu? Ich verwende einfach keine 8-Bit PICs. Fertig. Ist ja nicht so daß es keine Alternativen gäbe.
Helmut S. schrieb: > Die PIC8 haben eine dermaßen verkorkste Architektur, daß man die nur > lieben kann, wenn man nichts anderes vorher gesehen hat. Es ist ungünstig, dass du alle 8-bitPIC's in einen Topf wirfst. Womöglich bist du über die neueren PICs auch nicht so ganz informiert. Klar, die ganz kleinen Typen mit ihrem Bankswitching wirken nicht gerade übersichtlich, und auch der berühmte PIC16F84 war davon nicht frei. Aber Microchip unterscheidet selbst im 8-bit-Bereich und der mehrfach erwähnte PIC18F14K22 hat nichts mehr gemein mit einer komplizierten Speicherstruktur. Wiederholt: Es sollte sich hier um die Bedürfnisse für Anfänger handeln! Und da programmiert man sehr fleißig Zeilen um Zeilen vor sich hin und braucht sich keinerlei Gedanken um Bankstrukturen zu machen. Der Compiler richtet es. @ Volker: Falls das keine ironische Bemerkung sein sollte.....nein, meinen Anfangsfrust habe ich ganz sicher nicht vergessen. Und gerade deswegen kenne ich aus eigenem Erleben die Probleme, die Anfängern das Leben schwer machen. Im Nachhinein beglückwünsche ich mich zu der Entscheidung, bei diesem modernen 8-Bitter PIC18F14K22 und bei Assembler geblieben zu sein. Mein damaliges Projekt steht kurz vor der Fertigstellung, und nach dem Studium des Microchip-Tutorials war ich in der Lage, das Prog ganz überwiegend alleine fertig zu stellen. Klar, die Datenblättern waren nötig, und zweimal habe ich mir auch noch Rat eingeholt, z.B. über Tablereads. Aber lass mal, alles richtig gemacht. Gruß, wilhelmT
:
Bearbeitet durch User
Be T. schrieb: > Aber ein Anfänger, und davon reden wir hier, kann > überhaupt nichts mit Programmen anfangen, die länger sind als wenige > Zeilen. Gerade als Anfänger hat man schnell 256 Worte Flash gefüllt und schon geht der Ärger los. Das Denken in Prozeduren und Schleifen muß man erst noch lernen.
Peter D. schrieb: > Gerade als Anfänger hat man schnell 256 Worte Flash gefüllt und schon > geht der Ärger los. Wovon redest du ?
Peter D. schrieb: > Gerade als Anfänger hat man schnell 256 Worte Flash gefüllt Und? > und schon geht der Ärger los. Welcher Ärger?
Peter schrieb: > Welcher Ärger? RETLW liefert Mumpitz, weil man die PCLATH-Berechnung vergessen hat.
Peter D. schrieb: > Peter schrieb: >> Welcher Ärger? > > RETLW liefert Mumpitz, weil man die PCLATH-Berechnung vergessen hat. Mann, Leute! Einige von euch liefern wunderschöne Belege dafür ab, dass sie auch im Ansatz nicht verstanden haben, was für Anfänger wichtig ist. Die müssen erstmal unter Windows eine Arbeitsumgebung einrichten, und sich darin zurechtfinden. Sie müssen sich in mehrere Hundert Seiten Datenblätter für ihren µC einwühlen, in mehrere Hundert Seiten für Assembler-Programmierung, die Mappe mit dem Instruktion-Set durchforsten, mit ihrem neu angeschafften Programmer und dessen vielseitiger Anleitung klarkommen. Dann wäre da noch die Einarbeitung in die Hardware, will sagen, eine Experimentierplatine. Nicht jeder ist gestandener Elektroniker, auch da gibts Stolpersteine, siehe die Hilfeanfragen in diesem und anderen Foren. Dann, ja dann gehts irgendwann mal an das berühmt, berüchtigte Prog "Hello LED". Und da ist man als Anfänger verflucht glücklich, wenn man es bis dahin geschafft hat. Wenn man dann noch mit dem Simulator gelernt hat, umzugehen, - und nein, das ist nicht mit ein paar Augenblicken geschehen, - dann kann man mit Single-Step dem ersten Micro-Prog bei der Arbeit zu sehen. Das isses, was Anfänger brauchen. Gruß, wilhelmT
:
Bearbeitet durch User
Genau, bis die zum ersten mal ein RETLW gesehen haben geschweige denn 250+ in Folge in ein Assembler Programm gehackt haben ... sind sie hoffentlich in der Lage den Debugger/Simulator soweit zu benutzen um den Fehler sehr schnell zu finden. Das muss man meiner Meinung nach am Anfang lernen. Yp, ich weiss: "echte Programmierer schreiben den Scheiss einfach hin und das läuft" ;-)
Toxic schrieb: > Obendrein sollten sie sofort eine Rueckrufaktion aller schon > abermillionen existierenden Pics in Aktion setzen ... Meine gebe ich nicht wieder her! ;-)) JRo
Herzlichen Dank für die vielen Meinungen (habe natürlich einiges nicht verstanden) :-) Aufgrund der vielen auseinandergehenden Erfahrungsberichte muss ich wohl einfach eine Wahl treffen und die ist auch gefallen. Ich habe mich doch für das PICKit 3 Starter Kit in ASM und C entschieden. Ich halte irgendwie viel darauf, dass ein Chiphersteller gleich ein Tutorial mitliefert, da ist alles aus einer Hand umd hat bestimmt Hand und Fuß, bei der AVR Community sicher auch, irgendwie ists halt doch Micrichip geworden. PIC8 auch deshalb weil die Architektur ja einfacher bei kleinen chips ist (wenn auch verwickelt) damit kann ich leben denke ich, mit Fuses die den Chip nicht mehr zugänglich machen eher nicht. Klaus dankt :-)
Klaus schrieb: > Herzlichen Dank für die vielen Meinungen (habe natürlich einiges nicht > verstanden) :-) Es hätte schlimmer kommen können! Klaus schrieb: > Ich habe mich > doch für das PICKit 3 Starter Kit in ASM und C entschieden. Ich halte > irgendwie viel darauf, dass ein Chiphersteller gleich ein Tutorial > mitliefert, Freu dich nicht zu früh. Die Doku hinkt leider den aktuellen Tools leider oft meilenweit hinterher. Das kann einen Anfänger echt zur Verzweiflung treiben. Lass dich einfach nicht entmutigen, wenn es nicht gleich funktioniert. Be Ti hat es auch geschafft ... Klaus schrieb: > mit Fuses die > den Chip nicht mehr zugänglich machen eher nicht. Als der erste Student mit diesem Problem zu mir kam, konnte ich nicht glauben, dass es so was gibt. Gibt es auch nicht. Man steckt das Ding einfach irgendwo rein wo es mit den Fuses passt und programmiert es neu. Oder in meinem Fall war der Rat: "Biege die Pins hoch und schließe einen Frequenzgenerator an" ;-)
vloki schrieb: >> mit Fuses die >> den Chip nicht mehr zugänglich machen eher nicht. > > Als der erste Student mit diesem Problem zu mir kam, konnte ich nicht > glauben, dass es so was gibt. Gibt es auch nicht. Man steckt das Ding > einfach irgendwo rein wo es mit den Fuses passt und programmiert es neu. Es sei denn, Du entwidmest den !RESET-Pin. Wenn Du dann keinen High Voltage Programmer hast oder das Teil irgendwo eingelötet ist, hast Du bei AVR ein Problem. Bei PIC nicht, die machen das geschickter. fchk
Ne, das Problem war damals was mit dem Clock, aber ich habe auch einen Programmer ;-)
vloki schrieb: > aber ich habe auch einen Programmer ... Irgend so ein BPM microsystems Teil, das ich auch schon Jaaaaahre nicht mehr benutzt habe. Damit konnte man (früher ;-) ALLES programmieren.
Also ich bin für den PIC16F84. Der hat nur 35 Assembler Befehle, Ganz wenig speicher, noch weniger Ram und Periferie, und total überschaubar. Damit hab ich damals das programmieren der µC gelernt. Da hab ich sogar einen Compiler für den C64 geschrieben, um dieses Teil einfacher zu programmieren. (ich hatte viel Zeit im Sommer) Es gibt sogar eine volle Beschreibung der einzelnen Befehlswörterbits. Was mich gestört hat damals war einzig diese komische Bank benutzung des RAMs. Total hirnrissig. Ich hab noch ca 800 von den Dingern bei mir im Keller. Jetzt nach dem Umzug immer noch vorhanden, und wer mag, kann mir ein Angebot machen.(PIC16F84-10P, Baujahr 2008 siehe http://www.gyurma.de/PIC16F84-10P )
Martin G. schrieb: > Also ich bin für den PIC16F84. Also, der ist ja nun wirklich schon arg veraltet! Er hat ja noch nicht einmal einen internen Oszillator, d.h. da muss man immer einen Quarz oder andere externe Taktquelle anschließen! Ich weiss wirklich nicht, warum der immer noch so beliebt zu sein scheint! Für's Bastlersortiment würde ich mir da lieber ein paar verschieden große PICs aus der modernen enhanced-Midrange Familie hinlegen, z.B. 12F1840 (8-Pin), 16F1826 (18-Pin, wenn's pinkompatibel zum alten 16F84 sein soll) 16F1824 (14-Pin) o.ä.... Die haben alle jede Menge Peripherie (AD-Wandler, UART, SPI, PWM...) und einen deutlich verbesserten Befehlssatz, ohne daß dieser merklich unübersichtlicher wird, und Interrupts (sichern von W und Status) waren bei den alten PICs wirklich ein Krampf!
vloki schrieb: > Es hätte schlimmer kommen können! Da kenne ich einen, der diese These mehrfach untermauern könnte!:) > Freu dich nicht zu früh. Widerspruch: Freue dich, denn du hast die für einen Beginner beste Entscheidung getroffen! > Die Doku hinkt......hinterher (Teilzitat) An der Doku - damit meine ich das begleitende Material zu den 13 Lessons - habe ich nichts auszusetzen. Die ist prima zu lesen, der Inhalt gut zu verstehen, und alle Versuche klappen auf Anhieb. @ Klaus: Führe die Lessons aus, und du bist gut gerüstet für den Start des Selbstprogrammierens. Und für den merke dir bitte ein Stichwort: "relative Adressierung". Das wirst du brauchen, aber auch erst dann. Die Übungsbeispiele sind alle in "absoluter Adressierung". Lass dich durch diesen Hinweis nicht irritieren, du wirst mit den Übungen kein Problem haben. Danach bei den ersten eigenständigen Progs bitte erinnern. >Be Ti hat es auch geschafft ... So isses. Der Start war im Nachhinein gesehen holprig. Aber aus dem Überwinden dieser Stolperstufen kann man guten Nutzen ziehen. Das Wichtigste aus meiner Sicht ist es, sich möglichst fix mit dem Simulator anzufreunden. Der Lerneffekt beim Beobachten, warum sich denn nun in einer Speicherzelle etwas ändert oder aber gerade nicht, ist enorm. Noch zwei Tipps: du kannst deine Bestellungen direkt bei Microchip ausführen. Die liefern aus England und zwar sehr schnell. Du wirst dabei rasch bemerken, dass du es mit absoluten Profis zu tun hast: Ein hoch seriöses Geschäftsverhalten. Und wenn man die Hardware, den Programmer und die Übungsplatinen, erst mal in der Hand hat, kommt man ebenso rasch zu der Erkenntnis, dass der Preis dafür ein sehr günstiger (für den Käufer) war. Tipp2: Bestelle gleich noch 2 Stück PIC18F14K22 dazu; du wirst die Dinger lieben und für deine ersten Eigenversuche gut brauchen können. Gruß, wilhelmT
:
Bearbeitet durch User
@ wilhelmt Besten Dank, werde mir das auf jeden Fall zu herzen nehmen.
vloki schrieb: > Klaus schrieb: >> Ich habe mich >> doch für das PICKit 3 Starter Kit in ASM und C entschieden. Ich halte >> irgendwie viel darauf, dass ein Chiphersteller gleich ein Tutorial >> mitliefert, > > Freu dich nicht zu früh. Die Doku hinkt leider den aktuellen Tools > leider oft meilenweit hinterher. Gerade hatte ich nochmals einen Blick in die Doku geworfen. Bei diesem Board ist sie wirklich recht brauchbar. Vermutlich hatte ich das Debug-Express im Kopf, welches BeTi zuerst hatte. Beim Starter-Kit sind IDE und Compiler aktuell und es gibt nur kleinere Unstimmigkeiten wie die, dass der "Super"-Header jetzt auch vom Namen her zum Compiler passt und xc.h heißt (anstelle von htc.h)
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.