Pardon. Wenn ich mir mein Leben malen könnte, würde ich nach Volkers Hilfe zum ersten Programm da weiter bohren. Aber leider muss ich mich um mein Auto kümmern, dessen Luftfahrwerk einen erheblichen Schaden erlitten hat und dessen Beseitigung mich entweder einen mittleren fünfstelligen Betrag - anzuweisen an die Audi-Fachwerkstatt - kosten wird, oder aber..... viel Zeit. Gettz muss ich eh' ab zum zweiten Fussballspiel.
Grüße, picass

Das hört sich sehr erbaulich an. 

Habe daraufhin mal mein mplab v6. 00 nochmal gestartet und mit dem xc8 Compiler versucht was lauffähig zu kriegen.
Sagen wir so, meine Pausen auf Montagen sind nicht lang genug. Ich schaffe es immer noch nicht Programm Teile aus zu lagern und diese dennnoch nutzen zu können. 
Solltest du da ebenfalls Erfolge haben gerne mal preisgeben. 

Gruß 
Cobra 

Eine Erklärung für die vielen Fehlermeldungen habe ich: beim dem vorigen getesten Hauptprog "main.s" handelt es sich wohl um die Neuversion des MPLABX XC8-Assemblers. Der Autor hat von jedem Lektions-Beipspiel zwei gleichnamige Ordner erstellt. Einer ist wohl für den alten Assembler, einer für den Neuen.

Um da Grund rein zu bringen, hatte ich einen dritten Versuch gestartet: es wurde das Hauptprog "main.s" aus dem anderen Ordner - vermutlich mit dem alten A. - genommen und der µC nicht geändert. Das Debuggen führte auch nicht zum Erfolg, aber die verbliebenen - wenn ich das richtig sehe - 2 Fehlermeldungen sind nur ein Bruchteil der vorigen. Dazu habe ich in der Anlage "up55.zip" den kompletten Ordner eingefügt, erstellt laut Autor vom MPLABX v4.45 und dem bei meinem Debuggen erstellten Fehlertext. Mutige vor, immerhin wirds übersichtlich.
Grüße, picass
up55.zip

Hallo pic18!
Ich bin einigermaßen erschüttert. Is klar, das liegt natürlich vorwiegend an meinen noch nicht vorhandenen Kenntnissen im Umgang mit dem XC8-Compiler, aber....
..aber der Autor dieser Zwanziger-Serie an Tutorials schrieb u.a., dass alle Beispiele sowohl beim Debuggen als auch in einer vorhandenen Hardware - gemeint ist wohl eine Platine mit einem PIC12F200 - funktioniert hätten. Da bin ich naiverweise davon ausgegangen, dass bei der Übernahme des kompletten orig. Ordners für dessen Blink-Projekt und dem Umstellen auf den geänderten µC fast alles akzeptiert sein müsste. Ggf. für den PIC18F14K22 noch die anderen Ports definieren, aber sonst....
Nix, da läuft nichts  - außer dem NOP-Befehl - , ohne dass Fehler angezeigt werden, obwohl die MPASM-Versionen nahezu identisch, jedenfalls gleich in der Anwendung, und der XC8-Compiler komplett derselbe sind.
Wenn ich mir das Listening des Files "main.c" ansehe, scheint mir da drin einiges nicht zu stimmen, das sieht mir nach recht eigenwilligen Definitionen aus.
Grüße, picass

Ok, ich habe die S-Datei in eine txt-Datei verwandelt, jetzt kann ich was lesen. Hier fehlt wohl die include-Zeile, welche die Daten vom Pic holt z.b. #include pic18f14k22

Dann müßten die ganzen Config-Parameter eingestellt werden. Evtl, muß bei den Befehlen usw noch ACCESS bzw BANKED (0,1) angehängt werden. Die Bank sollte auch konfiguriert werden (MOVLB) Bei der Schreibweise 05h bin ich mir nicht sicher, ob der Compiler diese so kennt, hier evtl. 0x05 schreiben.

Da müßte ich den Quellcode sehen um die Fehler zu lokalisieren. Es sind einige Syndax - Error Meldungen. Als Warnung fehlt die ganze Konfiguration. GPIO ist auch nicht definiert.

Der erste Anlauf brachte ein beeindruckendes "nop"-Ergebnis. Aus den in anderem Fred beschriebenen Tutorials hatte ich dasjenige raus gegriffen, welches dem "hello world" entspricht. In dessen Zwanziger-Reihe wäre es "Part 6" mit dem Namen "how to blink a led". Der Autor hatte das für den PIC10F200 geschrieben, dabei MPLABX v4.45 und XC8 v2.31 PIC Assembler benutzt. Meine MPLABx Version ist die v5.20 und als XC8 Compiler hatte ich frisch und genau den v2.31 downgeladen und installiert. Als µC kam mein PIC18F14K22 an den Start.

Der erste Anlauf bestand aus zwei Versuchen: im ersten V wurde das "how to blink"-Projekt geöffnet und auf den anderen PIC µC in den Properties umgestellt. Im zweiten Versuch wurde ein neues Projekt gleich für den 18F... erstellt und nur das "main.c" file integriert. Beim Debuggen kam es zu wohl identischen Ergebnissen, dem "nop-Ereigniss". Will sagen: die Liste der Fehlermeldung war nahezu komplett so lang wie die Liste des Progs im File "main.c". Anders gesagt: nur die "nop"-Befehle und solche Sprunganweisungen wie "goto" wurden nicht angemeckert, aber alles andere durchgängig.

In der Anlage "copy16.zip" befinden sich diese "main.c"-Datei und als Text-File die kopierte Liste der Fehlermeldungen. Is klar, da ist Grundlegendes unpassend. Falls da jemand reinschauen möchte, würde ich mich über Anregungen freuen. Die von "vloki" angefügten Beispiele habe ich mir natürlich auch down geladen, die kommen - hoffentlich - heute Nachmittag dran. Wo liegt das grundlegende Missverständniss?
Grüße, picass
copy16.zip

Das könnte den Durchbruch bringen: schaut auf den neuen Fred im Unterforum MicroController. In dem frisch entdeckten Forum sind die Programme der ca. 20 Tutorials auch in der neuesten Version des MPLAB X XC8 -Assemblers erstellt und allesamt downloadbar.
Nun also ganz viele MPLAB Assembler -Progs mit grundlegenden Eigenschaften eines einfachen PIC10Fxx verfügbar! Eine eigene Seite mit den Unterschieden zwischen altem und neuem Assembler ist auch noch vorhanden...., das könnte was werden.
Wenn die UPS-Leute mit ihrer 4-Tage-Woche (Mo-Do) nicht so schnarch-langsam wären, könnte ich die Lauffähigkeit der Progs mit meinem neuen PICkit5 überprüfen. Melde mich mit den Testergebnissen, wenn die Braunen sich wieder zur Arbeitsaufnahme entschlossen haben sollten.
Grüße, picass

Habe mir mal wieder eine ,,neuere" Version der MPLAB X installiert, die Version 5.40, ab welcher der alte MPASM nicht mehr unterstützt wird, sondern stattdessen auf den ,,PIC Assembler" des XC8 zugegriffen werden muss. Dazu blicke ich mit leichtem Frösteln in diese Lektüre: ,,MPASM to MPLAB XC8 PIC Assembler Migration Guide" . Dieser Guide hatte mich dunnemals schon abgeschreckt, aber...... aber vielleicht kommt das ja gar nicht so ganz dicke, wie die ersten Blicke befürchten lassen.

Meine aktuelle Vorstellung: Man müsste ein komplett fertiges – einfaches – Programm haben, das dann als Vorlage für Weiteres dient. Dabei denke ich daran, dass bei meiner Programmerstellung mit dem MPASM der erste Teil – also z.B. die Variablen-Definitionen und ,,Config Settings" weitestgehend immer gleich bleibt. Das übernehme ich von einem Prog zum nächsten und ändere z.B. nur die Variablen. Das könnte doch bei dem PIC Assembler genauso sein?!
Das ausführende Prog selbst müsste – wenn ich das nicht ganz falsch verstanden habe – vom MPASM-Format übernommen werden können, und dann gilt es – wieder als Beispiel – die Radix(e) von Constanten zu ändern. Das wäre dann bei Eingabe einer Binärzahl nicht ,,b" vor der Zahl, sondern ,,B" hinter der Zahl. Solches kann doch nicht wirklich das ganz große Problem sein.

Die lange Liste der ,,Assembler Directives" brauche ich doch gar nicht,  oder zumindest nur für ganz wenige Ausdrücke. Ansonsten wären da noch z.B. das ,,Relocable" und ,,register address masking". Fürs Erste habe ich irgendwo mal ein paar Zeilen gesehen, mithilfe derer man den Programmstart wie beim MPASM auf die Adresse null legen kann. Aber vielleicht ist das bei kurzen Progs ja gar nicht nötig. Das Zweite checke ich im Moment noch nicht, das habe ich nur überflogen und gleich mal verdrängt.

Also: wenn ein komplettes, funktionierendes Assembler-Prog mit diesem ,,PIC Assembler" mal vorläge, wäre der Bann ja vielleicht gebrochen. Dabei gehe ich optimistisch davon aus, dass bei meinen zur Zeit geplanten oder in Arbeit befindlichen Projekten nur recht kurze und schlichte Steuer-Progs benötigt werden. Was meint ihr?
Grüße, picass