Da kann ich Montag ja gleich mal schauen, wenn ich meine Q20, Q40 und Q41 PICs bekomme ;-)

(PS die Ordner build, debug und dist kannst du dir sparen - spart viiiiieeeeel Speicherplatz)

Die Debatte über Motive wollte ich - zunächst - auslassen, weil das einen ganz eigenen und wohl auch ausführlichen neuen Fred füllen würde. Deshalb nur in Stichworten meine neue Motivation:
- ADC mit 12bit gibts nur bei den neueren PICs, die allesamt nur unter PIC-Assembler (PAss) laufen (oder halt C).
- für den PICKit5-Programmer hatte ich 130 € ausgegeben, die wären für die Katz, wenn nicht.....
- teils unwissend über das Erfordernisse des PAss und teils in freudigem Vorgriff hatte ich PIC-Q-Typen gekauft, die bislang unnutzbar rum lagen.
- mein zwischenzeitlicher Anlauf auf MicroPhyton wurde ernüchternd: zu wenig Unterstützung zur seriösen Einarbeitung
- wenn man diverse Dokumente oder aber auch persönliche Statements von anderen Strategen liest, kann man zum Eindruck gelangen, dass die eigentlichen Assembler-Befehle weitestgehend gleich sind - mithin das eigentliche Prog nur wenig Änderungen braucht, und "nur" die Preliminarien - also die Config und die Platzierung im Speicher einer Anpassung bedürfen.
- wäre dem so wie gerade dargestellt, dann würde sich der Aufwand lohnen, denn die allermeisten meiner Programme sind eher kurze Progs für Steuerzwecke.
- habe vor Kurzem von einer Studie gelesen, dass das Erlernen neuer Sprachen das Altern des Menschen deutlich raus zögern kann, auch u.a. in Hinblick auf Demenz. Es waren zwar die Umgangssprachen der Menschen gemeint, aber die Aussage wird schon auch übertragbar sein auf "unsere" Programmiersprachen.
- es wurmt mich, bislang schon viel Zeit für Versuche zu einer anderen Prog-Sprache aufgebracht zu haben, ohne dass dies zu echten Anwendungen in einem Prog geführt hatte. Da möchte ich nicht wirklich einfach den Löffel hin werfen, sondern schon gerne mal ein Ziel auch erreichen.

Gettz zu Grundsätzlichem und da wende ich mich aus aktuellen Gründen auch an vloki, der sich vor einem Jahr helfenderweise schon der Mühe unterzogen hatte, einen Einstieg in den neuen Assembler unter Verwendung des PIC18F14K22 und anhand der bekannten Lessons anzubieten.
Meiner Erinnerung nach war ich der Unruhegeist, welcher vor Etlichem in Richtung PAss geschaut hatte und dabei "meinen" PIC18F14K22 zur Einarbeitung nutzen wollte. Aktuell sehe ich das anders, auch unter dem Eindruck, dass - wie oben beschrieben - ein User gleich 21 angeblich funktionsfähige solche Progs für "seinen" PIC10Fxxx geschrieben hatte.
Heuer frage ich mich, was so' Unsinn soll? Wozu der irre Aufwand mit Einarbeitung in einen neuen Assembler und den dann auf alte Hardware verfrachten?! Die alte HW läuft mit dem zu ihr passenden Assembler auch, ganz ohne den Aufwand. Wenn....., dann macht das Gewusel nur Sinn, indem man auch die neue Hardware nutzt. Das ist so ein wenig auch wie bei Windows-Versionen: auch die sollten zur Hardware des PC passen, ein Mischen über Generationen/Entwicklungsstufen hinweg bringt unnötigen Trouble.

Also habe ich heute den PIC18F14K22 für weitere PAss-Bemühungen ausrangiert und mein Testboard mit dem PIF18F14Q41 angeworfen. Und Tusch: die Lesson1 mit "hallo world" funktionierte ohne jedwede Änderung. Is klar: die Lesson2 mit Blinken dann nicht mehr. Angemeckert wurde u.a. die Initialisierung für die Frequenzeinstellung via "OSCCON". Das geht im PAss anders, auch der Name ist neu. Da hab' ich mal einen frechen Kurz-Queck ausgeführt - also einfach mal was gemacht - und dann die restliche Fehleranzeige über nicht passenden Speicherplatz ignoriert und Tusch2: da blinkte und leuchte Alles, was sollte,......wenn auch nicht exakt wie erwartet. Das Blinken klappt, allerdings gibt es ein kurze und eine längere Pause im Wechsel und selbst die Dauer-LED hat eine kurze Leuchtpause. Is klar, es fehlt quasi die komplette Initialisierung. Die ist leider ganz anders und scheint auch kompliziert zu sein.

Aber immerhinque habe ich einen kleinen Zeh in den Tür-Spalt gebracht. Mal sehen, wie es weiter geht. Das von vloki vorgelegte Prog "lesson2" habe ich abgeändert. Den kompletten Ordner mit dem .s - File habe ich unten angehängt.
Grüße, picass
lesson2q41.X.7z

Auf zu neuen Zielen?
Meine Gründe um eine neue MCU zu 
verwenden:
   Die Features der bisher verwendeten und kennengelernten MCU's reichen für mein Projekt nicht aus.
   Ich bin neugierig erstmal mit neuen mir noch unbekannten Features "zu spielen".

Gründe um von dem mir bestens geläufigen Assembler zu einer (verbesserten?) Version zu wechseln:
   Mein Projekt ist mit der bisherigen Version nicht oder nur unter Schwierigkeiten durchzuführen.

Fazit: Obwohl ich schon zig Projekte zumindest auf dem Steckbrett experimentiell und erfolgreich mit MPLAB 8.x durchgeführt und vollendet habe, bin ich bisher noch nicht an Grenzen gestoßen (bin ich vielleicht zu bescheiden in meinen Ansprüchen? :-)

Wollte das in dieser Diskussion einfach mal mitteilen.

Ottmar.

Ja, danke für den Weckruf! Das Murmeltier ist nach einjährigem Schlummer erwacht, hockt vor seinem Bau und beschaut - wie schon mal - ein rotes Licht, das aus der Lektion 1. Das rote Licht aus der Lektion 2 sieht verdächtig genauso aus: mit Blinken ist auch nach einer Stunde noch nichts, auch der Oskar sagt nichts anderes. Da gehe ich dann morgen mal dran und versuche vor allem, das auf so'nen Q-Typ zu übertragen, denn das wäre ja das eigentliche Ziel.
Grüße, picass

Und täglich grüßt das Murmeltier: https://www.pic-microcontroller.de/index.php?msg=2425

Die PIC16 Beispiele waren ja komplett, aber die PIC18 habe ich leider nie weiter verfolgt

VON EINEM, DER AUSZOG, UM DEN XC8 PIC ASSEMBLER KENNEN ZU LERNEN

Über die Beweggründe erst mal nichts, aber einen erneuten Versuch wollte ich wagen. Vier Tage hat der gekostet.
Es begann hoffnungsvoll mit dem Bestücken meiner neuesten Version der Lern-Platine, dem Einpflanzen eines PIC18F14Q41 und dem Raus-Suchen des PICkit 5. Aber dann doch der erste Anlauf mit Bewährtem: dem PIC18F14K22.  Weil PICkit3 und 5 dieselben Verbindungen zu den Testboards aufweisen, und weil es da im Inet jemanden gab, welcher in gleich 21 Lektionen einem PIC10xxxx angeblich das Laufen mit der neuesten Assembler-Version beigebracht haben wollte, sollte eine Umwandlung ja möglich sein, zumindest mit einem Kürzest-Programm wie......, grübel......, ja doch: ,,hello world".

Zunächst zur Nomenklatur der Umwandlung hier die offizielle Benennung von Microchip: Migration from ,,Microchip MPASM assembler" (MPASM) to ,,MPLAB XC8 PIC assembler" (PIC Assembler). Selbst verkürze ich das im Folgenden mit Ass und Pass.

Is klar: wieder eine Hd mit Microsoft-Ups aktualisieren und dann war die frisch down-geladene neueste MPLAB XC8 Version lange mit sich selbst beschäftigt: Packs laden noch und nöcher. Dann das erste Prog des o.g. User laden und ohne jede Änderung den Debugger anschmeißen. Der schmiss mehr Fehler aus, als das vermeintlich funktionstüchtige Prog an – wenigen – Zeilen hat. Es kostete einen Haufen Zeit, mit dem Lesen diverser Microsoft-Anleitungen die Fehleranzeige auf Null zu bringen, also auf fast Null, denn es verblieb immer der Hinweis, dass das Prog in einem Bereich liegen würde, welcher nicht in dem zulässigen Bereich des Speichers der GPU liegt. Irgendwann war auch das weg. Aber – is klar: der Debugger wollte das Prog nicht in die Testplatine laden. Es hieß verklausuliert, dass es keine Verbindung gäbe.

An dieser Stelle mal eingeschoben einen persönlichen Kommentar zu den Bemühungen dieses Users mit seinen 21 Prog-Versionen, zu finden auch bei Github. Da will sich jemand in die allerneueste Version des Ass nicht nur einarbeiten, sondern gleich eine formidable Menge an Progs erstellen. Und nimmt dann den ältesten PIC, der verfügbar ist. Es hätte ja auch ein kleiner 8-Pinner der neuen Q-Serie sein können, das wäre nachvollziehbar und konsequent.
Soweit, so schlecht. Dann das Prog aus einer Handvoll an Zeilen, in welchem nur ein einziger Port genutzt wird. Der wird mit einer Variablen angesprochen. Variable sind nach meinem Verständnis Wörter, welche die Verwendung von Zahlen im Verlaufe eines Progs ersetzen und damit vorwiegend eine bessere Lesbarkeit bewirken sollen. Dieser User verwendet ein ellenlanges, mit Unterstrichen und diversen anderen Zeichen angereichertes Wort-Ungetüm, was das Erfordernis der Lesbarkeit auf den Kopf stellt. PORTA,2 wäre für jeden verständlich, zumal in einem Prog aus wenigen Zeilen und nur einem Portpin, aber nein, dass ist wohl nicht fachmännisch genug.
Auch mit anderen Mitteln schafft es der User, dieses micro-kurze Prog so unleserlich zu gestalten wie eine längeres C-Prog! Entlarvend: das bekannte Kürzel ,,hello world" was auch nicht akzeptabel, es musste ein Wort-Geschwurbel aus mehreren mit Bindestrichen aneinander gefügten Wörtern sein und was ,,Weihnachten" mit dem Leuchten einer einzigen LED zu tun hat, ist wohl auch Ansichtssache.

Dann also mal den IPE ausprobiert. Dort auch keine Verbindung. Angeblich, denn beide Progs konnten problemlos die Seriennummer des PICKit 5 auslesen. Dann neue Fehlermeldung: der PIC18F14K22 würde nicht unterstützt. Was Quatsch ist, denn der taucht sowohl in der Liste des MPLAB X wie auch des IPE auf und auch in dem offiziellen Dokument von Microchip. Aber schlecht, also das lassen und doch die neu bestückte Platine mit dem ,,Q"-Typen nehmen.
Auch klar: nix rührt sich.
Dann verzweifelte Suche nach ,,code exambles"! Sowohl in der MPLAB XC8 IDE  als auch auf der Microchip-Homepage tote Hose. Dort gibt es zwar Zahlreiches, aber nix mit PAss. Angesichts der tollen Prog-Beispiele für den PICkit 3 Programmer – gleich im Lieferumfang enthalten – könnte man heulen, wenn man die Unterstützung jetzt für den Programmer 5 und PAss zu Kenntnis nehmen muss.

Weitere Suche im Inet: nur für die alten Ass-Versionen.

Vier Beispiele finden sich dann doch im Microchip Dokument für PAss mit so'nem Zusatz ,,für Ingenieure". Die Vier sind leider alles andere als kurz, aber sie waren die einzigen, die überhaupt verwendbar erschienen. Da musste jeweils nur ein Portpin auf einen anderen Port verlegt werden – von E auf C – und in der zweiten Zeile ggf. noch der verwendete GPU-Typ angegeben werden, aber der Rest musste passen.
NIX.
Der Debugger fand alles fein, auch das Laden in den PIC verlief, wie es sollte, auch durch kurzes Grün-Leuchten des Programmers belohnt, aber halt NIX. Die eine LED hätte leuchten sollen....... Hätte, hätte und irgend so'ne Kette.

Wieder Eintauchen ins Inet. Dabei dann lesen, wie es anderen so erging. Und dann kam die Ernüchterung: Frust allerorten, Wut und Ablehnung. Microchip habe offensichtlich die alleinige Verwendung von PAss nicht mehr gewollt. Allein das gelegentliche Einfügen in C-Code wäre noch gewünscht. Zudem grundsätzliche Abkehr vom PIC und Assembler, hin zu anderen, mittlerweile ins Lieferprog aufgenommene GPU-Typen.

Kann sein, dass ich doch noch den Rest-Ergeiz aufbringen könnte, am letzen Prog-Beispiel von Microchip den Klemmer zu finden. Aber eines wird wohl unumgänglich: Die von mir als mittlere Assembler-Version Bezeichnete mit z.B. MPLAB X vers. 5.35 ist die einzige, welche verwendbar bleibt. Danach – also der PAss - ....., das kann man vergessen. Schade um die 12-bit-AD-Wandlung, schade auch die 130 € für meinen orig bei Microchip gekauften Fünfer-Programmer, schade um die Zeit wie auch um die Hoffnung. Was bleibt? NIX.
Grüße, picass

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