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

Zitat von: Peter in 10.11.2025, 13:56:26 CETBestellung ist unterwegs.

Bei meiner Bestellung exakt genauso: Paket ist nach einer Woche Bearbeitungszeit von Reichelt an DHL übergeben und nun auf dem Wege.
Grüße, picass

Bestellung ist unterwegs. Hat ja nur eine Woche gedauert.
Hoffe mal das sich das bald wieder ändert und die  Lieferungen kommen
wieder schneller an.

Das jüngst bei Aldi verkaufte LED-Spot Set mit gesamt 4 Stück Spots mit Bewegungsmeldern für 12,99 € ist/war ein tolles Schnäppchen: sieht gut aus, ist klein, funktioniert bestens, jeder Spot enhält einen aufladbaren Akku - ein echter Lithium-Ionen-Akku - und schmeißt viel Licht. Aber genau das gefiehl mir nicht so ganz für meinen Anwendungszweck als kurze Lichtquelle im Schlafzimmer, wenn man denn mal nachts kurz raus und durch den total dunklen Raum muss, ohne sich am Sesselbein einzuhaken mit eventueller Flugeinlage im Dustern. Aber bei so viel Lichtfülle wird der Lebenspartner im Bett nebenan wach und man selbst braucht soviel Erleuchtung zu dieser Zeit auch nicht. Kurzum: etwas weniger hell wäre besser.

Heute habe ich das Gehäuse geöffnet, was vergleichsweise einfach gelang, indem mit spitzigem kleinen Schraubendreher zuerst ein kleiner Spalt zwischen weißem Gehäuse und dem oberen, halb durchsichtigen Deckel erzeugt wird, dann hebeln, ringsum vorarbeiten,  ein bißchen Kraft auch noch, es knackt gelegentlich, aber es lässt sich zerstörungsfrei öffnen.

Auf der einseitig bestückten Platine finden sich u.a. ein großer, schwarzer Baustein ohne Beschriftung, das wird ein MOS-Fet sein, und noch was Kleines mit 6 Anschlüssen, wahrscheinlich ein MicroController. Die drei LEDs sind alle parallel geschaltet und das macht es einfach. Wenn man an Punkt 1 die Leiterbahn unterbricht, dann wird eine LED außer Betrieb gesetzt. Unterbricht man dagegen an Punkt 2, dann werden..... na ?
Das funktioniert bestens und als Gratifikation nebenbei verlängert sich die Leuchtdauer bei Verwendung nur einer LED gleich um den Faktor 3. Der Li-Ion-A hat übrigens 500 mAH.
Grüße, picass

Hab' gerade mal im Inet geschaut: mal ist von einer neuen Halle bei Reichelt, rsp. dem Bau von Hochregalen die Rede, mal von einer Woche Herbstferien Ende Oktober. Is klar...., auch Nexperia kommt ins Spiel. Jedenfalls warten gerade Einige.
Da wollen wir mal hoffen, dass zu den genannten Gründen nicht auch noch Drohnen-Sichtungen über dem Werksgelände sich dazu gesellen. Könnte ja sein, dass die Russen was auszuspionieren haben, etwa die Anzahl der Parkplätze!
Grüße, picass