Forum: Compiler & IDEs Vorabfrage:erfahrene Assemblerfreaks hier an Bord?


von Rudi R. (microwitsch)


Lesenswert?

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é

:
von Hoschti (Gast)


Lesenswert?

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.

von mkn (Gast)


Lesenswert?

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.

von Frank (Gast)


Lesenswert?

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?

von Rudi R. (microwitsch)


Lesenswert?

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"

von Rudi R. (microwitsch)


Lesenswert?

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

von Rudi R. (microwitsch)


Lesenswert?

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...:)

von Rudi R. (microwitsch)


Angehängte Dateien:

Lesenswert?

> 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?

von mkn (Gast)


Lesenswert?

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.

von A. S. (Gast)


Lesenswert?

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.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Hennes (Gast)


Lesenswert?

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

von Markus F. (mfro)


Lesenswert?

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...

von Rudi R. (microwitsch)


Lesenswert?

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??

von Rudi R. (microwitsch)


Lesenswert?

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?

von Oliver S. (oliverso)


Lesenswert?

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

von foobar (Gast)


Lesenswert?

> 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.

von foobar (Gast)


Lesenswert?

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 ;-)

von Michael_O (Gast)


Lesenswert?

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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von A. S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Rudi R. (microwitsch)


Lesenswert?

*****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...;)

von Rudi R. (microwitsch)


Lesenswert?

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.

von ... (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Rudi R. (microwitsch)


Lesenswert?

(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"?:)

von Franko P. (sgssn)


Lesenswert?

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

von Markus F. (mfro)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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...

von W.S. (Gast)


Lesenswert?

(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.

von (prx) A. K. (prx)


Lesenswert?

Ich betrachtete nicht Assembler-Programmierung generell, sondern 
spezifisch jene von 8-Bit PIC Prozessoren und deren Besonderheiten.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

(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.

von Wolfgang W. (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.