Ich habe noch Probleme mit Codebeispielen aus der Dokumentation des PIC16F18877(zb.PWM-Initilisierung) Ich komme erst dann mit dem Code,wenn nicht etliche Leute fragen, warum ich nicht MCC verwende!? :) Wenn meine IDE-Software hier richtig laufen würde und ich in Ruhe die Beispiele eines PIC-Lehrbuches durchgehen könnte, wäre mir schon geholfen. Es sind eben noch viel Assemblerbeispiele,...auch im Netz gibt es davon mehr. Gruß André
:
Da bisher keiner die von Dir vermutete Frage gestellt hat, zeige doch mal eins deiner Problemkinder und beschreibe, was Du (nicht) verstehst. Was soll man sonst hier schreiben. Oder wie Dir helfen.
Rudi R. schrieb: > Beispiele eines PIC-Lehrbuches Es gibt aber nicht den einen PIC. Die sind alle unterschiedlich. Datenblatt + Family Reference schnappen und Register setzen. Wenn Du ein Pic Lehrbuch durcharbeiten willst, brauchst Du exakt den PIC den die verwenden. Ich empfehle die Seiten von sprut. https://www.sprut.de/ Beliebtes PIC Problem: Auch wenn Du den ADC nicht verwendest, must Du einen Pin der ADC Fähigkeit hat expliziet auf digital stellen, sonst bekommt die digitale HW keine volle Kontrolle darüber was zu komischen Effekten führt. Warum läuft Deine IDE nicht, was verwendest Du, was ist dein Programmer / Debugger, was sind Deine Probleme... Du willst Hilfe also mach es uns auch einfach und lass Dich nicht an die Hand nehmen dafür.
Rudi R. schrieb: > Ich komme erst dann mit dem Code,wenn nicht etliche Leute fragen, warum > ich nicht MCC verwende!? :) Warum verwendest du nicht MCC?
Frank schrieb: > Rudi R. schrieb: >> Ich komme erst dann mit dem Code,wenn nicht etliche Leute fragen, warum >> ich nicht MCC verwende!? :) > > Warum verwendest du nicht MCC? weil ich unter anderem auch diese Probleme hier habe!? Codegenerator hin oder her, der nutz mir gerade nicht viel, wenn der Compiler nur rummault. Hier zb. mein anderer Thread von heute :) Beitrag "Frage zu Instruktionsbefehlen C-Complier Mplab 5.45"
Hoschti schrieb: > Da bisher keiner die von Dir vermutete Frage gestellt hat, zeige doch > mal eins deiner Problemkinder und beschreibe, was Du (nicht) verstehst. > Was soll man sonst hier schreiben. Oder wie Dir helfen. OK ich probiers mal, also hier ist der Versuch einer Initialisierung. Oben stehen die Anleitungen wie sie im Dokument des PICs sind und unten ist dann mein Versuch den Code zu schreiben.Jetzt kann ich mir natürlich vorstellen das der Helfende die Dokumentation braucht oder? ich denke aber das es dort ein Grundsystem geben muss,welches auch für andere, ähnliche PICs gibt oder? Vielleicht blickt ja jemand von euch hier durch und sieht schon Fehler?
1 | ; 19.1.9 SETUP FOR PWM OPERATION |
2 | ; |
3 | ; The following steps should be taken when configuring the module for using the PWMx outputs: |
4 | ; |
5 | ; 1. Disable the PWMx pin output driver(s) by setting the associated TRIS bit(s). |
6 | ; |
7 | ; 2. Configure the PWM output polarity by configuring the PWMxPOL bit of the PWMxCON register. |
8 | ; |
9 | ; 3. Load the PR2 register with the PWM period value, as determined by Equation 19-1. |
10 | ; |
11 | ; |
12 | ; PWM Period = ( (PR2)+1 ) x 4 x TOSC x (TMR2 Prescalevalue) Note:TOSC = 1 /Fosc |
13 | ; |
14 | ; |
15 | ; 4. Load the PWMxDCH register and bits <7:6> of the PWMxDCL register with the PWM duty cycle value,as determined by Equation 19-2. |
16 | ; |
17 | ; |
18 | ; Puls Width = (PWMxDC) x TOSC x (TMR2 Prescale Value) |
19 | ; |
20 | ; |
21 | ; 5. Configure and start Timer2: |
22 | ; |
23 | ; 5.1 Clear the TMR2IF interrupt flag bit of the PIR4 register. |
24 | ; |
25 | ; 5.2 Select the Timer2 prescale value by configuring the T2CKPS<1:0> bits of the T2CON register. |
26 | ; |
27 | ; 5.3 Enable Timer2 by setting the TMR2ON bit of the T2CON register. |
28 | ; |
29 | ; 6. Wait until the TMR2IF is set. |
30 | ; |
31 | ; 7. When the TMR2IF flag bit is set: Clear the associated TRIS bit(s) to enable the output driver. |
32 | ; Route the signal to the desired pin by configuring the RxyPPS register. |
33 | ; |
34 | ; Enable the PWMx module by setting the PWMxEN bit of the PWMxCON register. |
35 | ; |
36 | ; In order to send a complete duty cycle and period on the first PWM output, the above steps must be followed in the order given. |
37 | ; If it is not critical to start with a complete PWM signal, then the PWM module can be enabled during Step 2 by setting the PWMxEN bit of the PWMxCON register. |
38 | *********************************************************************************************************************************************************************** |
39 | #include "p16f18877.inc" |
40 | |
41 | ; CONFIG1 |
42 | ; __config 0xFFEE |
43 | __CONFIG _CONFIG1, _FEXTOSC_ECM & _RSTOSC_HFINT1 & _CLKOUTEN_OFF & _CSWEN_ON & _FCMEN_ON |
44 | ; CONFIG2 |
45 | ; __config 0xFFFF |
46 | __CONFIG _CONFIG2, _MCLRE_ON & _PWRTE_OFF & _LPBOREN_OFF & _BOREN_ON & _BORV_LO & _ZCD_OFF & _PPS1WAY_ON & _STVREN_ON |
47 | ; CONFIG3 |
48 | ; __config 0xFF9F |
49 | __CONFIG _CONFIG3, _WDTCPS_WDTCPS_31 & _WDTE_OFF & _WDTCWS_WDTCWS_7 & _WDTCCS_SC |
50 | ; CONFIG4 |
51 | ; __config 0xFFFF |
52 | __CONFIG _CONFIG4, _WRT_OFF & _SCANE_available & _LVP_ON |
53 | ; CONFIG5 |
54 | ; __config 0xFFFF |
55 | __CONFIG _CONFIG5, _CP_OFF & _CPD_OFF |
56 | |
57 | LIST p=16f18877 |
58 | #include <p16f18877.inc> |
59 | |
60 | RES_VECT CODE 0x0000 ; processor reset vector |
61 | GOTO START ; go to beginning of program |
62 | |
63 | ; TODO ADD INTERRUPTS HERE IF USED |
64 | |
65 | MAIN_PROG CODE ; let linker place main program |
66 | |
67 | ******************************************************************************************************************************************************************* |
68 | |
69 | START |
70 | |
71 | ; 1.Disable the PWMx pin output driver(s) by setting the associated TRIS bit(s). |
72 | |
73 | BANKSEL TRISC |
74 | MOVLW B'11111111' |
75 | MOVWF TRISC |
76 | BANKSEL TRISA |
77 | MOVLW B'11111111' |
78 | MOVWF TRISA |
79 | |
80 | ; 2.Configure the PWM output polarity by configuring the PWMxPOL bit of the PWMxCON register. |
81 | |
82 | BANKSEL PWM6CON |
83 | CLRF PWM6CON |
84 | |
85 | ; 3.Load the PR2 register with the PWM period value, as determined by Equation 19-1. |
86 | |
87 | BANKSEL TPR2 ;Periodendauer für 61Hz (TOSC 1/1Mhz) |
88 | MOVLW D'255' |
89 | MOVWF TPR2 |
90 | |
91 | ; 4.Load the PWMxDCH register and bits <7:6> of the PWMxDCL register with the PWM duty cycle value,as determined by Equation 19-2. |
92 | |
93 | BANKSEL PWM6DCL ; 4 Dutycycle Highbits |
94 | MOVLW D'125' |
95 | MOVWF PWM6DCL |
96 | |
97 | ; 5.1 Clear the TMR2IF interrupt flag bit of the PIR4 register. |
98 | |
99 | BANKSEL PIR4 |
100 | BCF PIR4,TRM2IF ; 5.1 Clear the TMR2IF interrupt |
101 | |
102 | ; 5.2 Select the Timer2 prescale value by configuring the T2CKPS<1:0> bits of the T2CON register. |
103 | ; 5.3 Enable Timer2 by setting the TMR2ON bit of the T2CON register. |
104 | |
105 | BANKSEL T2CON |
106 | MOVLW B‘11000000‘ |
107 | MOVWF T2CON |
108 | |
109 | ; 6.Wait until the TMR2IF is set. |
110 | |
111 | PWM_Period_Match |
112 | |
113 | BTFSS PIR4,TMR2IF ; 6 warten auf Interupt |
114 | GOTO PWM_Period_Match |
115 | CLRF TRISA ; When the TMR2IF flag bit is set: Clear the associated TRIS bit(s) to enable the output driver. |
116 | BANKSEL RA0PPS ; Route the signal to the desired pin by configuring the RxyPPS register. |
117 | MOVLW B‘00000000‘ |
118 | MOVFW RA0PPS |
119 | BANKSEL PWM6CON ; Enable the PWMx module by setting the PWMxEN bit of the PWMxCON register. |
120 | BSF PWM6EN |
121 | Loop |
122 | Goto Loop |
123 | |
124 | END |
mkn schrieb: > Wenn Du ein Pic Lehrbuch durcharbeiten willst, brauchst Du exakt den PIC > den die verwenden. > Ich empfehle die Seiten von sprut. > https://www.sprut.de/ Hey ja die Seite hatte ich schon gefunden! Die gefällt mir übrigens auch, sehr gut gemacht! Da ist zum Beispiel auch in den Lernbeispielen eine PWM-Modulation,da wollte ich das Beispiel schon für meinen 16F18877 umschreiben, doch die Bänke dort sind natürlich anders angelegt und so. Beim 16F18877 kommen noch mehr Parameter hinzu, weil man da die PINs noch mehr beiflussen kann(Routing) Hast du schon mal einen Code für einen anderen PIC umgeschrieben? Also die Datenblätter(700Seiten insgesamt)sind schon heftig! Doch man findet nach und nach eine Strucktur, habe mir entsprechede Lesezeichen im PDF setzen müssen, sonst wird man da irre! Wie sind die Einsteiger damals bloß klargekommen? Ich habe nichts gegen Codegeneratoren, wenn ich auch verstehe was die da getan haben!(Dissablage geht leider aktuell nicht immer) Im Lehrbuch wurde gut bewiesen, das es sehr vorteilhaft wäre Assemblercode zu beherschen. Und alles hat bei mir mit nur einen kleinen Gedanken an Mikrocontroller angefangen:ich will keine riesige störungsanfällige Leiterplatte für ein Puls-Akkuladegerät haben.PWM-Module wären wie geschaffen für mein Vorhaben von einen Stepupwandler mit nachgeschaltetem Kondensator (der sich bis zu einer 3fach höheren Eingangsspannung laden ließe) Danach sollen von ca 30V auf 12V Entladezyklen folgen. Doch das ist ja erstmal nebensächlich...:)
> Warum läuft Deine IDE nicht, was verwendest Du, was ist dein Programmer > / Debugger, was sind Deine Probleme... > Du willst Hilfe also mach es uns auch einfach und lass Dich nicht an die > Hand nehmen dafür. Jou, ich habe MplabX IDE v5.45 installiert, mit PICkit4 an einem PIC16F18877. Gehe gerade Codebeispiele eines Lehrbuches für PIC-Programmierung durch, die sich nach der Codegenerierung nicht mit nachträglich geänderten, neu eingefügten Instruktionen aus dem Buch vertragen!? Autor des Buches hatte damals noch eine andere Softwareversion, bei der diese Fehler ofensichtlich nicht auftauchten. Nach der einen XC8-Fehlermeldung beim debuggen soll ich nach der im Anhang zu sehenden Methode eine Vorwärts-deklaration veranlassen? Wie macht man sowas genau?...siehe Fragezeichen im Anhang. Warum sind denn immer alle Einträge unbekannte Deklarationen? Der Buchautor hätte doch sowas erwähnt?
Rudi R. schrieb: > Hier zb. mein anderer Thread von heute :) Ich antworte mal hier, weil beide Threads ja irgendwie zusammengehören: Du bist zu ungeduldig und gibst schnell dem Tool die Schuld wenn was nicht läuft. Wenn der Compiler mault, dann weil er Dich darauf hinweist das DU einen (potentiellen) Fehler gemacht hast. Das ist doch nett von dem und kein Grund böse zu sein. Leider ist das nunmal so das in 99% der Fälle das Tool genau das tut was Du ihm sagst und wenn was nicht läuft sitzt das Problem meist vor dem Bildschirm. Das Tool versucht Dir zu sagen was das Problem ist, so gut es das eben kann. In 1% der Fälle macht das Tool gerade Schrott, aber das hilft nix, Du must Dein Tool lernen und workarounds für die Bugs finden. Nicht jede Arbeitsweise funktioniert für jedes Tool. Mit Codegeneratoren und fertigen LIBs die den Hardwarezugriff 'vereinfachen' sollen sind meine Erfahrungen eher gemischt. Es gibt so eine unendliche Vielzahl an Dingen die mit der Hardware möglich ist, das die Tools die meist nicht komplett abbbilden oder da Fehler drin sind. Ich schreibe nicht sehr oft Software und wenn, dann muss die nicht portierbar sein. Ich schlage mich also nicht mit Codegeneratoren und Libs herum, sonder schau mir die Hardware an und setze die Register direkt. Codegeneratoren setzen Dir nicht die Hardware wie Du sie willst. Sie generieren Code der das tut, aber aufrufen musst Du den. Du willst bare metal und Du bekommt bare metal. Hier wird Dir absolut nix abgenommen. Ist Dir das für den Einstieg zu schwer, schau in Richtung Arduino. Die PICs sind auch Fluch und Segen zugleich. Die Stärke der PICs ist ihre unglaubliche Vielfalt. Du kannst PICs finden die eine ganz spezielle Hardware haben und ganz spezielle Dinge tun können, die nur damit geht. Du kannst bei sorgfältigem Studium der Doku wirklich geile Tricks finden Hardware Dinge fast ohne CPU Eingriff Dinge tun zu lassen. Du kannst Dir auch ganz furchtbar die Karten legen. Und ja, 700S Familiy Reference sind echt ne Ansage und MC bekommt immer wieder den Trick hin die alles entscheidende Information für Dein Problem in 700S Fließtext in einem Nebensatz zu erwähnen. Aber da musst Du durch. Das ist Stoff für Leute die vollen Zugriff auf alles ohne Beschränkungen wollen und das ist eben kein Bällebad. Du mußt ja nur die wichtigen Abschnitte lesen. Alles was die Hardware betrifft die Du benutzen willst. Das Clock System, der IRQ Controller, die Timer, die IO Register. Nicht jeder Timer kann alles, aber das was ein Timer kann geht oft weit über PWM hinaus. Ich bin kein Freund von Assembler. Es ist meist ein Trugschluss das man mit ASM besser ist als der Compiler. Selbst wenn, spielt das einfach keine Rolle bei den Taktfrequenzen. Die Zeiten in denen ich Taktzyklen zählen musste sind einfach vorbei. Ich benutze C, weil es viel übersichtlicher ist und ich nicht jedes Mal das Rad neu erfinden muss. Mein Rat an Dich: Verwende die MC Tools und werde warm damit. Du wirst für Lau nichts besseres finden und das Zeug funktioniert gut. Fange mit einem 'hello world' Programm an. Bei MCUs ist das eben mit einem Pin zu wackeln. Dein erstes Projekt wird nicht sein Dein Ladegerät zu bauen. Dein erstes Projekt wird sein die Toolchain und Deine MCU kennenzulernen. Setz den Debugger ein, lerne IRQ Routinen zu schreiben, wackel mit Pins. Und vor allem: Beschreibe Deine Aufgabe, gliedere sie in schaffbare Abschnitte, kommuniziere klar. Du kommst hier wie der zerstreute Professor rüber, der vor sich hinbrabbelt aber niemand versteht wirklich was gerade das Thema ist. Ich habe z.B, kein Stück verstanden wie PWM irgendwas für Dich tun kann um einen Kondensator zu laden und pulsweise auf einen Akku zu entladen. PWM Hardware brauchst Du für sehr schnelle Vorgange, hohe Auflösung bei hoher Wiederholrate. Nochmal: ASM macht die Sachen nicht leichter. Du brauchst auch keinen ausgebufften ASM Profi hier. Was Du brauchst ist ein strukturiertes Vorgehen und kleinere Schritte. Du willst aber hoch hinaus ohne die Anfänge zu beherrschen. Nehm Dir Zeit. Das wird ein Marathon und kein Sprint.
Rudi R. schrieb: > Wie sind die Einsteiger damals bloß klargekommen? Mit dem PIC16C54 angefangen, der hat nur 192 Seiten. Auf der anderen Seite dafür auch ohne Debugger und sooon neumodisches Zeug: Programm schreiben, brennen, Toggle-LEDs beobachten, UV-Löschen und weiterschreiben.
Rudi R. schrieb: > Hier zb. mein anderer Thread von heute :) > > Beitrag "Frage zu Instruktionsbefehlen C-Complier Mplab 5.45" Wir merken uns nicht von jedem der irgendwie auf der Brennsuppen daher geschwommen kommt alle seine Threads. Nebenbei, es wird hier sehr ungern gesehen wenn man zu einem Thema mehrere Threads gleichzeitig auf macht. Rudi R. schrieb: > Wie sind die Einsteiger damals bloß klargekommen? Deine Postings sind doch nur Betteln um Aufmerksamkeit. "Vorabfrage"? Was soll der Bullshit? Nun gut, bekommst du halt ein bisschen Aufmerksamkeit: Wir haben damals nicht so rumgeheult und rumgezickt. Wir haben uns auf den Hintern gesetzt und alles durchgearbeitet was wir in die Finger bekamen. Wir haben klein angefangen und uns über Jahre weitergebildet https://norvig.com/21-days.html Als letzter Tipp, es ist nicht besonders schlaue Leute, von denen man sich Hilfe erhofft, direkt im Betreff als "Freaks" zu beschimpfen. "Vorabfrage"-Bullshit hin oder her.
:
Bearbeitet durch User
mkn schrieb: > ASM macht die Sachen nicht leichter. > Du brauchst auch keinen ausgebufften ASM Profi hier. > Was Du brauchst ist ein strukturiertes Vorgehen und kleinere Schritte. > Du willst aber hoch hinaus ohne die Anfänge zu beherrschen. > > Nehm Dir Zeit. > Das wird ein Marathon und kein Sprint. So isses. Und versuche C zu lernen. Dann brauchst Du Dich nicht mit tonnenweise BANKSEL abzuquälen.
Hallo mkn schrieb: > Wenn der Compiler mault, dann weil er Dich darauf hinweist > das DU einen (potentiellen) Fehler gemacht hast. Das ist doch nett von > dem und kein Grund böse zu sein. Ich bezeichne mich immer noch als Einsteiger und lernender der erweiterten Grundlagen und das in C bzw. C++ in der "Arduinovariante". Jeder der Compiler die ich bisher kennenlernen durfte, aber auch OT diese ganzen Fehlercodes die verschiedenste Geräte bzw. System ausgeben sind so gut wie immer Hinweise mit den nur ein erfahrener und schon eigentlich "alles" im jeweiligen Gebiet beherrschender etwas anfangen kann. Klassiker: Der "Arduino Compiler" meldet irgendeinen für den Anfänger recht kryptischen Fehler - natürlich auf englisch (o.k. ist halt so - damit muss man einfach leben)und dann noch in Worten die nicht unbedingt zum typischen "Schulenglisch" gehören was die meisten so einigermaßen noch beherrschen. Ursache ist dann aber gar nicht mal so selten ein vergessenes Semikolon und ähnliches triviales - das steht aber nie als Hinweis im Fehlertext - nicht mal in der Art: "Hast du eventuell nur ein Semikolon vergessen?" also halt mehr ein Vorschlag aus der Praxis heraus als ein technisch super sauberer Hinweis. So was würde nicht nur den Anfänger wirklich helfen. Ganz ähnlich sieht es bei den diversen Fehlercodes aus: Abgesehen von den seltenen Fall eines guten Wartungshandbauch (was wenn es verfügbar extrem teuer bezahlt werden muss und meist nur bei Produkten gibt die mal abgesehen von PKW,und dann sowieso nicht vom eigentlichen Nutzer zu bekommen, seltenst zu hause bei sich stehen hat (Stadtbahn, Flugzeug...) und sich generell auch wieder an echte Fachleute wendet sind alle dies Fehlercodes kaum ein Helfe: "E 4711: Fehler im ...system" - Na Super... Warum nicht "E4711 Fehler im ...system - Typischer weise hat sich der Stecker zur Sonde X0815 gelöst oder öfter ist auch mal die Versorgungsspannung nicht mehr unter allen Umständen stabil" Das ist was ich wirklich sinnvolle Hinweise auf potentielle Fehler nennen würde - genau das wäre doch ein sehr sinnvolles Gebiet wo Updates sinnvoll sind - sowohl bei reiner Software wie ein Compiler (zumindest in der Hobby- und Einsteigerumgebung) und erst recht bei Geräten und Systemen... Aber nein: Wer mit all diesen Fehlermeldungen wirklich was anfangen kann hat sowieso schon viel Erfahrungen und wenn der "typische" Fehler nicht vorliegt ist wie Anno 1970 stundenlanges, nervendes Suchen, ausprobieren oder bei Hardware lustiges (teureres) Modul tauschen angesagt... Hennes
Hennes schrieb: > Ursache ist dann aber gar nicht mal so selten ein vergessenes Semikolon > und ähnliches triviales - das steht aber nie als Hinweis im Fehlertext - > nicht mal in der Art: "Hast du eventuell nur ein Semikolon vergessen?" > also halt mehr ein Vorschlag aus der Praxis heraus als ein technisch > super sauberer Hinweis. Den wirst Du nicht bekommen. Es ist nun mal so, dass C (und C++, weil das ist ja schliesslich, was in deinem Arduino-Code steckt) bezüglich der Syntax ziemlich - na ja - "flexibel" ist. Will sagen, dort, wo Du das Semikolon vergessen hast, könnte (syntaktisch korrekt) tatsächlich auch was ganz anderes stehen. Der Compiler kann nicht wissen, was Du eigentlich haben wolltest und versucht, sich auf das, was Du nach dem vergessenen Semikolon geschrieben hast einen Reim zu machen und die Fehlermeldung bezieht sich dann eben darauf. Ein bisschen wie beim Urinstinkt...
mkn schrieb: > Nehm Dir Zeit. > Das wird ein Marathon und kein Sprint. Ui,...ich wollte nur meine Timerplatinen,mit NE555 platzsparent und effizient ersetzen.Da wardann das Buch hier im Netz zu finden[[https://www.weltbild.de/artikel/buch/elektronik-gar-nicht-schwer-mikrocontroller-basics-mit-pic_26484885-1]]...Und da dachte ich mir Mikrocontroller?...Warum nicht probieren?...Doch jetzt wird die Zeit dafür schon fast unbezahlbar.Es sei denn ich programmiere ab jetzt ständig solche uC. Grundsätzlich ist es ja schade das man den normalen Elektroniker mit so einem Teil nicht zeitnah unter die Arme greifen kann, wenn man erst programmieren lernen muss. Da muss ich mir ja schon jetzt 100 Projekte ausdenken damit sich das nachher lohnt?? Wie lange braucht man denn nun um einen einstellbaren PWM programmieren zu können? Gibt es noch keinen Service der dir einen PIC nach deinen Vortellungen programmiert? Ich komme langsam ins Zweifeln ob ich da wirklich tiefer einsteigen sollte oder muss, weil ich ja noch mehr zu tun habe... Für wievile Projekte habt ihr denn hier PIC Programmieren gelernt??
Markus F. schrieb: > Ursache ist dann aber gar nicht mal so selten ein vergessenes Semikolon Was ist eigentlich wenn mein Zeichensatz hier nicht stimmt und er aus dem Schriftsatz bestimmte Zeichen nicht nimmt? Gibt es sowas?
Markus F. schrieb: > Hennes schrieb: >> Ursache ist dann aber gar nicht mal so selten ein vergessenes Semikolon >> ... > > Den wirst Du nicht bekommen. Aktuelle gcc und clang können das. Nicht immer, aber meistens. Oliver
> Wie sind die Einsteiger damals bloß klargekommen? Meine Meinung: gerade für Einsteiger sind die PICs vollkommen ungeeignet - die bekommen einen vollkommen falschen Eindruck von CPUs und Mikrocontrollern und machen es sich unnötig schwer. Als ich damals mit den PICs anfing (noch im Keramik-Gehäuse mit Fenster), ich hatte vorher 6502, Z80 und 68000 programmiert, habe ich nur noch geflucht. Die Teile kommen aus der Steinzeit und sind auf extremen Minimalismus getrimmt - die Entwickler haben versucht, so viele Transistoren wie nur irgend möglich einzusparen (Programmierer sind billiger als HW). Herausgekommen ist eine Architektur, die in Assembler beschissen zu programmieren ist und für keine Hochsprache geeignet ist. Im Vergleich zu den PICs sind 6502 und Z80 luxuriös, AVR ne ganz andere Liga. Die Rettung: der Programmspeicher war so klein, dass man eh keine längeren Programmen schreiben musste ;-) Wenn also jemand meint, mit Assembler anfangen zu wollen (was ich nicht verkehrt finde, wenn auch nicht allzu lange), würde ich ihm nachdrücklich von PICs abraten, alle anderen sind besser geeignet.
Ach so: > [...] habe mir entsprechede Lesezeichen im PDF setzen müssen, > sonst wird man da irre! > > Wie sind die [...] damals bloß klargekommen? Die haben Papierschnipsel oder Finger zwischen die Seiten gelegt, PDF gab's noch nicht ;-)
Ich habe Assembler auf einen 8085 und später Z80 gelernt. Als ich viele Jahre später wieder Lust bekam habe ich mir PICs geschnappt, um nicht so viel unnötiges Zeug zu brauchen. Die super Oszillatoren in den Dingern können ohne Quarz meist genau genug, und die 8 Pinner haben für vieles genug on Board. So werkeln die seit Jahren rund um die Uhr in meinem Wohnwagen und warten auf die IR Fernbedienung um das Licht zu steuern und laden täglich meine E-Autos. Weiter Projekte warten zum Teil seit Jahren darauf das ich wieder Zeit finde. MfG Michael
foobar schrieb: > Wenn also jemand meint, mit Assembler anfangen zu wollen (was ich nicht > verkehrt finde, wenn auch nicht allzu lange), würde ich ihm > nachdrücklich von PICs abraten, alle anderen sind besser geeignet. Eine Ausnahme bilden die PIC32, die sind MIPS ;) MIPS lässt sich sehr gut in ASM coden.
foobar schrieb: > Wenn also jemand meint, mit Assembler anfangen zu wollen (was ich nicht > verkehrt finde, wenn auch nicht allzu lange), würde ich ihm > nachdrücklich von PICs abraten, alle anderen sind besser geeignet. Ooch, gerade für Autodidakten war das vor Jahren gar nicht schlecht. 30 Befehle, alle im Datenblatt gut erklärt, einen relativ guten Simulator und das Kostenlos, mit dem jeder zuhause bit für bit durchexerzieren konnte, ... Keine Interrupts, ... Wenn man dann noch die paar Config-Bits richtig hatte, tat es jeder Programmer und die LED blinkte.
Rudi R. schrieb: > Ich habe noch Probleme mit Codebeispielen aus der Dokumentation des > PIC16F18877(zb.PWM-Initilisierung) Jetzt kenne ich deinen PIC zwar nicht näher, aber bei deinem weiter unten gezeigten Quellbeispiel geht es mir deutlich zu konfus zu. Das ist gewiß zum Teil dem aus meiner Sicht miserablen PIC-Assembler von Microchip geschuldet, aber es liegt auch an dir. Versuche du mal, deine Quelle systematisch aufzubauen. Also: - zuerst Bemerkungen für dich zum Zweck des Ganzen als Kommentare - Konfigurationsdatei für den verwendeten PIC einbinden - I/O-deklarieren und Portverwendung hinschreiben - Variablen im RAM deklarieren - Konfiguration, User-ID's usw. hinschreiben - dann der Codebeginn, Einsprung für den Interrupt beachten Anbei mal eine ältere Quelle zur Ansicht, wie ich das im Allgemeinen so halte. Schau sie dir mal an, auch wegen des optischen Eindrucks. Allerdings verwende ich meinen eigenen Assembler, eben weil der von Microchip mir überhaupt nicht zusagt. Bei demvon Microchipmüßtest du einiges, was bei meinem eben eingebaut ist, durch eigene Makros ersetzen. Zum Beispiel anstelle BTFSS Port,Bit und BTFSC Port,Bit eben SKIP Bit und SKIP NOT Bit und auch sowas, um eindeutig und zentral einzelne Bits zu deklarieren: Karlheinz: BIT PortB,3 und auch das Arbeiten mit Segmenten. Die PICs sind ja Harvard-Maschinen, also muß man unterscheiden zwischen Code ( SEG CODE ) und Daten ( SEG RAM ) und da auch die Codebreiten sich unterscheiden, zwischen verschiedenen Code-Sets im Code-Segment: CORE12, CORE14, CORE16 - das Fehlen der Segmente bei den Tools von Microchip hatte mich damals (so Anfang der 90er) auf die Palme gebracht. Das geht zwar, wenn der Assembler lediglich als Nachbrenner für einen Compiler gedacht ist, aber für das Arbeiten in Assembler ist das der blanke Brechreiz. Kurzum, bringe Struktur in deine Quelldateien, dann kannst du dir damit auch quasi eine Vorlage machen, die du dann für Projekte in Assembler benutzt. Es ist auch sinnvoll, daß du dir Codesequenzen für Standarddinge wie z.B. Lesen und Schreiben des eingebauten EEPROM und den Rumpf für den Interrupt usw. schreibst. W.S.
*****Mein Problem mit dem PWM-Modul PIC16F18877 ist voerst gelöst!***** Also vorerst hat mich der MCC unterstützt...mal sehen was die Dissamblerdatei sagt...vor allem wie lang der Code dort im Vergleich zu einer reinen Assemblerdatei ist? Ich habe eine alte Version des XC8-Compilers (v2.0)integrieren müssen,... wurden wohl die instruktionen nicht erkannt,lag villeicht am Format eingefügten Code(long,long oder long,short.. hab ich noch keine Ahnung von...) ich hab es ja irgendwie geahnt, das hier irgendwas mit der "Schnittstelle" nicht stimmen muss. Lehrbuchautoren die Fehler machen??(und das bei mehreren Beispielen...nee wäre doof gewesen Die Code aus dem Lehrbuch sind schon richtig, man muss nur die gleiche Softwareversion haben auch wenn es schon 2 Jahre zurückgeht! Angefangen hatte das Buch mit Mpasm-Beispielen, da hatte ich schon den ersten Schock...Mpasm war bei der aktuellen IDE 5.45 nicht dabei! Der Autor selbst hatte auch Probleme mit nur leicht abweichenden Versionen des Compilers XC8 der IDE v4.20 erwähnt. Nun ja...jetzt gehts erstmal weiter...ich werde mir natürlich etwas C-Programmierung aneignen müssen, ist klar,sonst kann ich ja eigne Ideen nicht einsetzen. Mpasm gefällt mir trotzdem irgendwie, es reizt mich schon irgendwie das mal mit "Uraltcode" umzusetzen auch wenn es knifflig wird!? Ist allerdings auch ne Zeitfrage? Habt ihr hier eigentlich alle hier nur diese eine Hobby Elektronik... welche unkomerziellen, experimentellen Schaltung habt ihr denn so mit einem uC zum Laufn gebracht?? Danke erstmal für eure Anteilnahme, ich gehe mal die neuen Nahcrichten hier durch...sind ja viele zugekommen...;)
foobar schrieb: > Meine Meinung: gerade für Einsteiger sind die PICs vollkommen ungeeignet > - die bekommen einen vollkommen falschen Eindruck von CPUs und > Mikrocontrollern und machen es sich unnötig schwer. Der "böse" Lehrbuchautor hat mir also gleich ein schwieriges Teil vorgelegt oder wie?? Aber wenn ich so sehe was der alles könnte(700 Seiten Dokument) Dann lerne ich doch lieber an einen zwar kompliziert der sehr universell ist. Vielleicht brauch ich dann nur noch diesen uC?? Tja und dann läuft er aus und man kriegt den nicht mehr!?:( Bisher habe ich nur ein Projekt damit...dafür kann der schon viel zu viel. Ich werde eventuell 3PWM-Module davon brauchen,wenn man damit klarkommt würde man sich ein Haufen Programmierung sparen. Vielleicht kann ich den ADC-wandler noch nutzen um die Spannung auszuwerten...?War schon lustig das ich anfangs mit einer Schleifenprogrammierung einen PWM simulieren wollte(bezüglich einer festen PWM-Frequenz) Ey warum schrein ich schon wieder so viel....? Das Forum bei Microchip,sieht da anders aus...da sind immer ziemlich kurze Fragen und dementsprechende Antworten? Soll heißen wir deutschen schreiben gleich immer über Gott und die Welt...:o)....macht leider die Sache hier immer unübersichtlich,oder? Werde mal versuchen mich ab jetzt kürzer zu fassen.
Wenn du dich an alten PIC-Tutorials und alten PIC-Buechern erfreuen willst, dann nimm halt auch die PICs dazu. Dazu dann MPLAB 8.92 mit dem dazugehoerigen Assembler. Es muessen ja nicht die gaaaanz alten mit einem Guckloch sein. Der Assembler des XC8 ist nicht kompatibel mit dem MPASM. Allerdings ist es schon lohnenswert, sich eher mit diesem zu beschaeftigen. Spaetestens wenn man mal eine Interruptroutine in Assembler schreiben will, und den Rest in C. Und ganz ehrlich, was Microchip auch an "Spielereien" in die "neuen" PICs klatscht, interessiert mich nicht die Bohne. Wenn den "alten" etwas fehlt, dann wechsele ich eher gleich zu einer anderen Familie. Z.B. STM-8, etwas von Renesas oder ein passender ARM. Und das sich ein MIPS in Assembler einfacher programmiert, halte ich auch fuer ein Geruecht. Das man mit dem eher aufmerksam umgehen muss, dafuer sorgt schon die Prefetchqueue. Fuer MPLAB 8.92 braucht man uebrigens XC8 V 1.45.
Wenn man sich auf Assembler-Ebene mit 8-Bit PIC Prozessoren beschäftigt, wird man mit Strukturen und Lösungen der Vergangenheit konfrontiert, denen man zukünftig wahrscheinlich nicht mehr begegnet - es sei denn, man bleibt bei dieser Familie. Adressraumselektion über Bankumschaltung ergab Sinn, als diese Familie jung war, in den 70ern und 80ern des letzten Jahrhunderts. Die Hardware war auch danach noch sehr praktikabel, zumal Microchip für Kleinkunden weit bessere Angebote hatte als die Konkurrenz. Aber die Programmierebene riecht längst etwas modrig. Zwar sind die Typen mit 16-Bit Befehlsbreite moderner, aber die Programmiertechniken weichen besonders bei der Speicheradressierung weiterhin deutlich von dem ab, was der modernere Rest der Branche so treibt (8051 müffelt auf ASM-Ebene ähnlich, sobald man jenen Bereich verlässt, für den diese Architektur gebaut war). Wenn man sich also für diese PICs entscheidet, und deshalb auch ASM lernen will - OK. Geht es eher darum, Assemblerprogrammierung allgemein zu lernen, scheint mir diese Familie der falsche Weg zu sein. Der Trend der Architekturen geht in völlig andere Richtungen.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Wenn man sich auf Assembler-Ebene mit 8-Bit PIC Prozessoren beschäftigt, > wird man mit Strukturen und Lösungen der Vergangenheit konfrontiert, > denen man zukünftig wahrscheinlich nicht mehr begegnet - es sei denn, > man bleibt bei dieser Familie. Also es wäre für mich schon sinnvoll ersteinmal bei einem PIC zu bleiben, denn bisher sind meine Projekte nicht so umfangreich!? ...eventuell 3 PWM-Module nutzen und ein Signal messen und auswerten. LCD-Display werde ich vorerst nicht brauchen,... ein paar LEDs die Zustände anzeigen reichen mir völlig. Ich glaube es gibt einen gewissen Punkt der Möglichkeiten eines PICs,wo für den Hobbybereich alles abgedeckt wird. Viele werden wohl bald eher wieder auf ältere PICs zurückgreifen. "Warum einen Mercedes nur zum Einkaufen fahren benutzen wollen"?:)
Hallo also das sehe ich nicht so. Der 16F18877 ist ein aktueller PIC. Ja, der kann deutlich mehr als seine Vorgänger, aber man muss sich in einen alten mit weniger Peripherie genauso einarbeiten wie in einen neuen. Und der neue hat mehr Features. Was gegen den Neuen spricht ist lediglich der Schwachsinn mit Funktionen, denen erst per Befehl ein Ausgang zugeordnet werden muss. Und das ist im Datenblatt leider schlecht dokumentiert. Aber ich habe auch schon mit dem PIC16F18877 gearbeitet und ich finde ihn schlecht. Es gibt auf jeden Fall kinen Grund sich zuerst mit nem 16F84 oder einem 628 zu beschäftigen. Gruß gerhard
Franko P. schrieb: > Es gibt auf jeden Fall kinen Grund sich > zuerst mit nem 16F84 oder einem 628 zu beschäftigen. M.E. gibt es überhaupt keinen Grund, sich (als Neueinsteiger) mit einem PIC zu beschäftigen. Die Dinger (auch die "modernen") haben m.E. nur dort eine gewisse Berechtigung, wo es darum geht, vergangene Investitionen in diese Architektur so lange wie möglich "auszulutschen". In allen anderen Fällen ist der Neueinstieg m.E. reiner Masochismus.
foobar schrieb: > Wenn also jemand meint, mit Assembler anfangen zu wollen (was ich nicht > verkehrt finde, wenn auch nicht allzu lange), würde ich ihm > nachdrücklich von PICs abraten, alle anderen sind besser geeignet. Ich finde den 8051 Assembler sehr gut durchdacht. Mit den Bitbefehlen MOV C, ANL C, ORL C kann man Logikgleichungen quasi direkt hinschreiben, mit MOVC bequem Tabellenzugriffe (z.B. 7-Segment) implementieren, mit MUL/DIV 8Bit Berechnungen direkt ausführen, mit DJNZ, CJNE komfortabel Schleifen erstellen. Beim PIC sind beliebte Fallgruben, wenn die 256 Word Pagegrenze überschritten wird, die falsche RAM-Bank ausgewählt ist oder der Hardwarestack überläuft.
Rudi R. schrieb: > Für wievile Projekte habt ihr denn hier PIC Programmieren gelernt?? Für keines. Ich hab mit 8051 angefangen und dann AVR. Der größte Anfängerfehler ist, einfach drauf los zu schreiben und sich nicht erst einen Programmablaufplan in Textform zu erstellen. Das Denken in Abläufen ist der größte Lernschritt. Eine Hochsprache hilft dabei sehr. Alle Befehle werden nacheinander ausgeführt und jeder Befehl kostet Zeit. Prozedurale Sprachen verschleiern das leider wieder.
Peter D. schrieb: > Der größte Anfängerfehler ist, einfach drauf los zu schreiben Ja. > Das Denken in Abläufen ist der größte Lernschritt. Absolut. > Eine Hochsprache > hilft dabei sehr. Nicht unbedingt. Kommt einfach drauf an. Vieles wird in einer Hochsprache klarer und einfacher ausgedrückt, das stimmt. Aber anderes, insbesondere maschinennahe Sachen, ertrinken manchmal förmlich im Ballast des nötigen Syntax-Zuckers drumherum...
(prx) A. K. schrieb: > Wenn man sich auf Assembler-Ebene mit 8-Bit PIC Prozessoren beschäftigt, > wird man mit Strukturen und Lösungen der Vergangenheit konfrontiert, > denen man zukünftig wahrscheinlich nicht mehr begegnet - es sei denn, > man bleibt bei dieser Familie. Ich sehe das nicht so. Schließlich ist es nicht das Ziel, sich auf irgend eine Plattformfamilie zu "dressieren", sondern das Ziel ist eher, Sich Algorithmen und Herangehensweisen anzueignen. Und dieses eben einmal ohne den vom c-hater genannten "Ballast des nötigen Syntax-Zuckers drumherum". Erinnert sich hier jemand an die Diskussion über "weak"? Dieses Wort, was zum Auflösen des Interrupt-Geschehens bei den Cortex-Architekturen nötig ist und wo C-Programmierer ohne Assemblerkenntnisse sich ernsthaft gefragt hatten, ob und wie man das auch für ganz andere Dinge benutzen könnte? Daß bei den Architekturen die Ansichten, wo man sich eher "heimisch" fühlt, auseinander gehen, ist normal. Zu früheren Zeiten hatten sich auch einmal die Lager der Motorola-Leute und der Intel-Leute gegenseitig nicht recht verstehen wollen. Und jetzt ist das ganz genau so. Peter ist mit dem 8051 aufgewachsen, ich selber habe die PIC schätzen gelernt und andere haben wohl noch ganz andere Präferenzen. Ich sehe das Programmieren auf Assemblerebene als das softwareseitige Gegenstück zum Erlernen der Grundlagen der Elektrotechnik und Elektronik auf der Hardwareseite. Wer das ignoriert und sich lieber NUR mit höheren Dingen befassen will, hat nicht den Boden unter den Füßen. Das ist für den Programmierer genau dasselbe, wie es für den Mathematiker ist, wenn er zwischen dem Beherrschen der Algorithmen einerseits und dem Griff nach einem Mathe-CAD und dessen vorgefertigten und eingebauten Funktionen andereseits unterscheiden will. Wie oft muß man hierlesen, daß einer seine "Temperaturwerte vom ADC" über den UART senden will, ohne zu verstehen, daß dazwischen Binärzahlen aus dem ADC, deren Skalierung, deren Wandlung in einen menschenlesbaren Schriftzug und dessen Transmission stehen, bis daß man auf einem Terminal lesen kann, wie warm es derzeit ist. Ich muß hier auch mal wieder die Bücher von Lampe,Jorke,Wengel erwähnen, die als Plattform zwar den Z80 genommen hatten, aber dennoch Algorithmen erklärten, die allgemeingültig sind und als solche natürlich auch auf ganz anderen Prozessorarchitekturen funktionieren. Aber eben nicht per copy&paste. W.S.
Ich betrachtete nicht Assembler-Programmierung generell, sondern spezifisch jene von 8-Bit PIC Prozessoren und deren Besonderheiten.
:
Bearbeitet durch User
Rudi R. schrieb: > Grundsätzlich ist es ja schade das man den normalen Elektroniker mit so > einem Teil nicht zeitnah unter die Arme greifen kann, wenn man erst > programmieren lernen muss. Tja, vor dem Können ist überall das Lernen angesagt. Das Schlaraffenland ist anderswo. > Gibt es noch keinen Service der dir einen PIC nach deinen Vortellungen > programmiert? Selbstverständlich gibt es so einen Service, nennt sich zumeist Programmierer. Aber der will vermutlich für seine Dienstleistung Geld haben. Und er will von dir eine exakte Vorlage haben, was das Ding tun soll. > Ich komme langsam ins Zweifeln ob ich da wirklich tiefer einsteigen > sollte oder muss, weil ich ja noch mehr zu tun habe... Woher sollten wir hier wissen, was dein eigentlicher persönlicher Hintergrund ist? Und was deine Hobbies sind, wo deine Interessen liegen? Also was du eigentlich willst, mußt du schon mit dir selber ausmachen. Was du hier erwarten kannst, sind Beispiele zum Angucken aus den verschiedensten Bereichen - aber was davon dir zusagt, ist deine Sache. W.S.
(prx) A. K. schrieb: > Ich betrachtete nicht Assembler-Programmierung generell, sondern > spezifisch jene von 8-Bit PIC Prozessoren und deren Besonderheiten. Ja. Und? Jede Architektur hat ihre Besonderheiten und wo die eine saugut ist, ist die andere nur schlecht geeignet und umgekehrt. Aber wenn ich so mal mein eigenes Resümee ziehe, dann sehe ich im Rückblick keine gravierenden Unterschiede beim Programmieren in Assembler zwischen Z80, PIC, 8086, FR3 und 78K4 - mal von der Bitbreite, der Endianness, dem Speichermodell und den völlig unterschiedlichen Befehlssätzen abgesehen. Ich habe sie alle programmiert sine ira et studio. Und was denn nun genau betrachtest du "spezifisch bei jener von 8-Bit PIC Prozessoren"? Ich vermute nichts weiter als das Verhältnis zu den jeweiligen persönlichen Vorlieben. W.S.
Hallo, zunächst Etwas zu MPLABX 5.45 und MPASMX: Die letzte von mir verwwendete MPLABX-Version mit MPASMX und den dazu generierten INCLUDE-Files wie z. B. für den PIC16F18877 ist MPLABX 5.35. Bei späteren Versionen fehlt der seperate Assembler und damit auch die INCLUDE-Files. Ich verwende aber von dieser riesigen MPLABX-Schwarte nur MPASMX und MPLAB IPE (mit PICKit 3 oder 4) und schreibe ASM-Files mit Notepad++. Zum PIC16F18877: Empfehlenswert ist auch das aktuelle zum PIC16F18877 zugehörige Errata-File durchzugehen. Generell gilt für diese neueren PIC16er: Sie haben eine eindrucksvolle Peripherie-Sammlung. Das ist ihre Stärke. Negativ ist: wenn man mit verschiedenen PIC16 werkelt, dann sind die Peripherie-Register von MC zu MC in unterschiedlichen Bänken. Vergessene Banksel bzw. MOVLB lassen einen immer wieder mal auf Fehlern rumkauen. Außerdem sind auch Interrupt-Flags und -Enables und PMD-Bits an unterschliedlichen Stellen. Beim obigen Assmblerbeispiel fehlt meiner Meinung nach das Rücksetzen der zu den PWM-Ausgängen gehörigen ANSEL-Register-Bits. Falls das dort aufgerufene .INC-File doch von der MPLABX 5.45 stammt, lass es mich bitte wissen. MfG Wuff_W
Beitrag #6710401 wurde von einem Moderator gelöscht.
Beitrag #6710408 wurde von einem Moderator gelöscht.
Beitrag #6712346 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.