Traurig, traurig, alles verlernt! Zwei Jahre nach meinem letzten Programm für den PIC18F14K22 in Assembler ist alles wieder weg und der Anfang wirft Hürden auf. Habe leider die komplette Hard-& Softwareumgebung von damals nicht mehr, vor allem ist die Festplatte mit den damaligen Erfolgen Geschichte, nur noch einige Programme existieren noch.
Habe nun die Vers. 5.35 der MPLAB X IDE installiert auf Win7/32bit und versucht, eine der letzten Versionen dieses vorigen Programms zu starten, aber nix funktioniert. Hatte zuletzt den kompletten Ordner des Programms Namens "öltemp66" in den Projekt-Ordner der neu installierten Version kopiert, dann dieses Projekt geöffnet, das Sourcefile geöffnet, als auszuführende "Hardware" den Simulator (-Modus) ausgewählt, aber außer einer niedlichen Fehlermeldung: "There is no make executable in the path"  is nix - siehe Bild 3.
Ich brauche ein einziges, kleines funktionierendes Prog., dann wirds auch wieder klappen, im Moment sehe ich nix, jedenfalls kein Land.
Grüße, picass

Die tolle Alternative, ein Prog - egal, welcher Art - auf einem anderen PC und dort unter Win7 Prof/64 bit zu erstellen, endet in nahezu gleich aussehenden Fehlermeldungen, die ich leider nicht duchschaue, siehe Bild, das von der Qualität so schlecht wie das Ergebnis ist.
Grüße, picass

Hallo
Hier mal ein Link MPLAB
Weis nicht ob du den kennst. Ganz unten ist dann der Compiler für Assembler.

Peter

Probier mal das angehängte Projekt.
Wenn das funktioniert, dann kannst du ja die Dateien ersetzen.

Beim nächsten Mal verwende am besten zum Archivieren deines Projektes das hier:
https://microchip.wikidot.com/mplabx:projects-package
Dann hast du alles drin, was man braucht und keinen unnötigen Ballast.

Zitat von: Peter in 02.03.2021, 22:01:50 CETHallo
Hier mal ein Link MPLAB
Weis nicht ob du den kennst. Ganz unten ist dann der Compiler für Assembler.

Ich glaub nicht, dass der ASM30 für einen PIC18 passt.

Der Hacken ist durch die Strümpfe!
Nach diversen Frust-Versuchen bin ich gaaaaanz von vorne angefangen:
- zuerst auf dem zuverlässigsten Arbeits-PC eine SSD freigeräumt und ein "brandneues" Win7 HomePremium 32-bit-System installiert, und den ganzen steinigen Weg über Treiber und Win-Aktualisierungen gegangen. Dazu in einem alten Ordner nach noch älteren Keys geschürft, die dunnemals Verwendung fanden. Und Microsoft war so freundlich, via Inet.....;
- aus dem Archiv von Microchip die letzte Version des MPLAB ohne X installiert, einen Schreck bekommen, so alt sollte es auch nicht sein, die also gleich wieder gekillt;
- dann pur aus Verdacht die Version 4.20 der X-Kollektion installiert, wieder gabs beim ersten Test Meckermeldungen, die aber irgendwo nachvollziehbar waren;
- dann solide ein neues Projekt für den PIC18F14K22 am vom Programm für üblich erachteten Platz angelegt, dem Prog das alte, aber passend umbenannte ASM-File untergeschoben und Tusch: die Fehlermeldungen blieben aus, stattdessen in freundlichem Grün die Vermeldung des erfolgreichen Debuggens! Ne, was schön, endlich kann mit der Arbeit begonnen werden!

Hatte mich gestern eine Runde geschämt, weil das mal wieder so holperig verlief. Lag u.a. daran, dass nach dem erfolgreichen Abschluss meiner letzten Schaffensperiode eine sofortige lange Pause einsetzte, in den Folgewochen Tabula Rasa mit Festplatten stattfand: die letzten mechanischen HDs wurden aufs Abstellgleis, bzw. in die Tonne verschoben, einige neue SSDs angeschafft, in all dem Gewusel versucht, mit Acronis True Image gelegentlich auch mal was zu sichern, nur um später festzustellen, dass die neueren Versionen - damit meine ich die Jahrgänge 2017 und 2019 unzuverlässig waren: sehr häufig hängte sich der Compi beim Versuch der Restaurierung auf, statt das Image auf der neuen Hd zu installieren, und evtl. hab ich noch'n Faktor übersehen, ach ja, meine Systematik war damals auch nicht "so ganz bei der Sache" gewesen.
Aber 'nu isses ja gut. Danke für alle wohlgemeinten Tipps.
Grüße, picass

Nun ist entgültig Frieden im Assemblerbereich. Hatte gestern dasselbe File, welches unter Win7/ 32 bit lief, unter einem anderen Win7 probiert, einem mit 64 bit: auch das klappte. Dann heute wieder mutig noch'n anderes Windows, nämlich Win10/ 64 bit und die fünft-letzte Version der MPLAB X IDE geladen und installiert, nämlich die Vers. 5.20 : auch hier klappt das Debuggen auf Anhieb. In dieser Version ist der MPASM Assembler v 5.84 vom 17.03.2019 noch integriert.
Könnte sein, dass der auch noch in der Version 5.30 der X IDE drin ist. Danach wohl nicht mehr, die neueren Versionen haben ein deutlich größeres Download-Volumen, da ist dann wohl der neue X-Assembler drin, mit dem mein File nicht lief.
Grüße, picass

Also bei mir tut die v5.35 mit MPASM 5.87 unter Win10 64bit ohne murren.
(gebe aber zu, dass ich das seeeeeehhhhr selen verwende)

Grüße,
   Volker

Nun soll es endlich losgehen mit der Erstellung des Progs für die Rollladensteuerung. Und – is klar – 2 Jahre Pause in Sachen Umgang mit Assembler waren zu lang. Das erste kleine Testprog ist fertig, auch der Debugger ist zufrieden und quittiert es mit ,,o.k.", aber beim Simulieren bleibe ich gleich hängen, hier beim Verändern der Werte von Port-Pins.
Verwendet wird MPLAB X IDE vers. 5.20 und der darin enthaltene Assembler. Die Ports A und B sind komplett auf Eingang geschaltet, PortC auf Ausgang.  Zunächst sollten PA4 u. 5 und PB6 u. 7 eingelesen werden, und deren Werte sollen im Singlestep-Modus des Simulators vor dem Einlesen und Weiterverarbeiten halt simuliert/ äh, stimuliert werden.
Meiner Erinnerung nach konnte ich dunnemals im Fenster für die Anzeige der Variablen die Werte von PORTA, PORTB und PORTC direkt ändern. Klappt aber jetzt nicht. Verändern kann man die Werte von LATA, LATB u. LATC. Leider hat das keinen Effekt auf PORTA, PORTB u. PORTC.

Nun gibt es da ein Extra-Fenster namens ,,I/O Pins", siehe Foto. Dort kann ich die vorher eingesetzten Pinne von Port B toggeln. Nicht aber die für PortA u C. Das könnte darin liegen, dass in diesem Fenster der Musterpin RA4 als analoger Input bezeichnet wird und der RC0 als analoger Output. Wer zum Henker hat denn diese Einstellungen/Differenzierungen vorgenommen - ich jedenfalls nicht bewusst?!  Was ist zu tun, um zumindest auch alle Pinne an PortA im Simulator stimulieren zu können?
Grüße, picass

Na sauber! Jetzt hatte ich beim großen Bruder, rsp. Vater - bei Microchip himself - um Hilfe bei Stimulatitions-Versuchen nachgeschaut, und dann dieses!  Siehe Bild.
Grüße, picass

Hast du denn die Pins von PORTa auf digital gestellt?
Per Default sind die vermutlich "analog" und beim Lesen vom PORT bekommt man dann immer eine 0!

Zitat von: vloki in 28.03.2021, 11:19:37 CESTHast du denn die Pins von PORTa auf digital gestellt?

Also in deinem Code, nicht im Simulator.

Der Simulator versucht wohl den PIC genau so abzubilden wie du ihn konfiguriert hast. Wenn du selbst nicht daran gedacht hast, dass man für die Pins nicht nur Ein- oder Ausgang einstellen muss, dann sind die eben mit dem Vorgabewert konfiguriert und der ist im Allgemeinen so, dass möglichst nichts kaputt geht, wenn was doch anders angeschlossen ist während der PIC noch gar nicht programmiert wurde.

Ach, vloki, ach! Das war mal wieder typisch für mich: eine schier unüberwindliche Gemengelage aus Vergessen der Grundlagen des PIC-Assemblers und fehl-leitender, rsp. methodisch mangelhafter Ausführung des PIC18Fxx-Datenblattes und zu optimistischer Hardware-Beschaltung.
So war es eigentlich immer: gleich am Anfang Schwierigkeiten, die Ports richtig einzustellen. Dazu gehörte auch, dass die - wie du vermutet hattest - nicht explizit auf digital eingestellt waren. Das ist nun nachgeholt, danke schon mal an dieser Stelle.
Dann das verdammte Datenblatt. Da haben ganz sicher Dipl-Ings dran gesessen, die ihr fundamentales Wissen um die Details der Assembler-Kunst verinnerlicht hatten. Nur hatten die keinerlei Ahnung von Methodik und deswegen in diesem Bereich bei den Ausführungen nicht nur Mangelhaftes, sondern nach meinem Geschmack Ungenügendes abgeliefert.

Auf mehreren Seiten wurde über die Ports referiert, dabei alles in dreifacher Wiederholung, für jeden Port extra das fast Gleiche. Auch ein scheinbar praktisches Programmier-Beispiel wurde angefügt. Aber dann gings los: statt über die Basics der Port-Einrichtung hinreichend zu informieren, gabs spaltenlange Ausführungen über Interrupt-Behandlung. Das gehört schon deswegen nicht dort rein, weil es einerseits Programme ganz ohne Interrupt geben kann und gleicherseits für die IRQs eine extra Abteilung folgt. Aber leider... leider wurde dabei das Basic der Notwendigkeit nicht, rsp. ungenügend behandelt, Eingangsports auch auf analog oder aber digital einrüsten. Der niedliche Hinweis in einem winzigen Kasten reicht NICHT. Wenn es nicht möglich ist, einen Port ohne diese Einrüstung sicher in Betrieb zu nehmen, dann gehört diese Info nicht am Ende in Kleinst-Gedrucktes, sondern ganz an den Anfang und in mehreren Sätzen und - auch das noch - in einem praktischen Programmier-Beispiel ausgeführt! Da haben die Herren Ingenieure eine miese Arbeit abgeliefert.

Jetzt wieder zu meinen Fehlern: Meine ersten Testprogramme wären ja gelaufen, wenn ich bei der Hardware nicht zu schnell und zu großzügig vorgegangen wäre. So hatte ich eine dieser kleinen Musterplatinen mit dem ewig langen Namen:"....low Count Demo Board..." genommen, und die vorhandenen Beschaltung - eine 7-Segm.-Anzeige - mit übernommen. Also viel Drahtgewirr. Dazu kamen dann 2 Taster und da kam meine Unzulänglichkeit ins Spiel. Einfach mal zwei Ports über Taster an Plus und das wars. Kein Kondensator, kein Widerstand, nix. Und das brachte dann - wie ich erst heute feststellte - alle Versuche zum Kollaps. Da starteten LEDs, obwohl das Prog gar nicht so weit war, auf den 2 Ausgangspins lagen Rechteck-Impulse an, das war ein wares Wunderwerk und alles so ungewollt.
Erst heute hatte ich die Eingänge beruhigt und Widerstände je nach Plus und GND gelegt und - zack - war der Spuk vorbei. Das liest jetzt keiner hier, und ich habe auch ganz ehrlich nix, aber auch gar nix gesagt: aber das hat mich Tage des Anlaufens gekostet. Schwitz. Nu ist der Spuk vorbei und das Prog tut erstmals das, was es soll. Da wollen wir mal hoffen, dass die Wiedereinstiges-Wehwechen damit überwunden sind.

Dem Simulator bin ich aber immer noch böse, will sagen, das Stimulieren der Portpins klappt immer noch nicht. Write to the latsch, read from the Port.....heißt es. Aber wenn ich einen Port Pin mit: bsf LATC,4 beispielweise auf "1" setze, was ja auch klappt, dann lässt das den Simulator völlig kalt und die anschließende Abfrage mit einem Sprungbefehl wie: btfsc PORTC,4 ergibt immer nur "0". Immer diesen verdammten Basics....
Grüße, picass

Zitat von: picass in 29.03.2021, 17:22:50 CESTDann das verdammte Datenblatt.

Hab mich ehrlich gesagt auch gewundert, wo bei PORTA die in den meisten PIC18 Datenblättern üblich "Note" ist,
in der gleich am Anfang auf die Konfiguration als analoge Eingänge hingewiesen wird. (Bei PORTC ist sie vorhanden)

Eventuell wertet der Simulator den PORT in deinem Fall nicht aus, weil der Level dort dem Simulator
nicht bekannt sein kann, da die Beschaltung nicht bekannt ist. (Im Extremfall ein Kurzschluss zu irgendwas)

Warum liest du nicht einfach das Latch? Wenn du wissen willst, was du an den Ausgang geschrieben hast,
dann ist das die richtige Wahl. Nur wenn du wissen willst, ob das, was du am Ausgang haben willst auch in der Realität,
z.B. trotz ungünstiger Beschaltung auch am Pin bereit gestellt werden kann, dann könntest du den PORT lesen und mit dem erwarteten Pegel vergleichen. (Der Simulator kann das evtl. nicht)

Zitat von: vloki in 30.03.2021, 11:22:51 CESTEventuell wertet der Simulator den PORT in deinem Fall nicht aus, weil der Level dort dem Simulator
nicht bekannt sein kann, da die Beschaltung nicht bekannt ist. (Im Extremfall ein Kurzschluss zu irgendwas)

Hmmm,
ich benutze den Simulator eigentlich nie, aber ich habe das gerade bei mir mal schnell ausprobiert,
da ich ein Projekt in der IDE habe, das in einer möglichen Konfiguration auch einen 14K22 hat.

Bei mir folgt PORTC_4 dem LATCHC_4. Kannst ja mal dein Projekt packen und hier posten oder mir schicken...

Der Simulant hatte Pause. Hatte zur Abwechslung mal wieder "in Hardware gemacht". Melde mich vorraussichtlich morgen wieder.
Grüße, picass

Nun haben sich auch die Nebel des Vergessens über meinem Simulations-Prob gelichtet, und wie immer - wenn man aus dem Rathaus kommt - : es ist so einfach.
Extra für das Nutzen der Simulation gibt es unter dem Haupt-Ordner "Window" einen Unterordner "Simulation", und der enthält 4 zusätzlich aufzurufende Fenster, eines davon heißt "Stimulus". Dort gleich im ersten Fensterbereich kann/muss man dann, nachdem das Prog "gebuildet" und im Simulations-Modus gestartet und dann gestoppt ist, eine neue Zeile öffnen und die mit dem zu stimulierenden Objekt befüllen, also z.B. RB6. Dafür gibts ein Aufklapp-Menü, und dort sind dann u.a. alle Port-Pinne angeführt, also von RA0 bis RC7. Ist diese erste Spalte befüllt, kann man rechts daneben den Befüllungswert vorgeben, also z.B. "high" oder "low". Und dann kommt das Wichtigste: am Anfang der eben eingeführten Zeile befindet sich ein "Fire" genanntes Feld, und da mit der Maus drauf. Und das war dann die Auflösung des ganzen Stimulations-Spukes !!!!

Stimmt nur nicht! Man muss dem Simulator noch einen einzelnen Step Gelegenheit geben, das umzusetzen. Also ein Schritt vor dem Befehl z.B. "btfsc" ist zu knapp, dann passiert wieder nix. Halt zwei Schritte vorher das Fire-Signal per Maus ausgeben.

Warum hat das nicht gleich geklappt, was früher definitiv so gut geklappt hatte? Vergessen, is klar, aber wohl auch anfangs - als die Nebel noch dicht waren - untaugliche Versuche gestartet, also z.B. sofort versucht, im Variablen-Fenster so'n Port-Pin zu beeinflussen, also z.B. sofort RB5 zu toggeln, rsp. zu stimulieren. Der hatte sich aber immer standhaft geweigert, dann Wühlen in den Datenblättern, sich ärgern, dass für einen einzigen Portpin gleich 3 Flags/Register eingeführt waren und zu beachten sein sollten, zunehmende Aufregung, weil so viel Zeit für nicht gelingende Manöver drauf gingen, und im falschen Fensterbereich geschaut, nämlich dem für "Debugging". Dort hatte ich alles durchprobiert, auch mehrfach. Und dann war ich irgendwann doch mal im richtigen "Simulations"-Fenster gelandet, aber beim Stochern mit der Maus mich unglücklich verhalten. Fragt einen der früheren schlichten Fußballprofis von Borussia Dortmund, der mal nach einer Niederlage des Teams den weisen Satz ausgegeben hatte: "Erst hast du kein Glück, und dann kommt noch Pech dazu".
Und das war dann immer noch nicht alles: auch die Erkenntnis, dass nach Betätigen des richtigen Knopfes im richtigen Fenster sich immer noch nichts tat, weil erst noch ein zusätzlicher (Leer-) Schritt notwendig war, musste noch erfahren werden. Aber nu' stimuliert es sich ja wieder, und hinterher ......
...und hinterher grinst man darüber, dass ein und dasselbe (Kleinst-) Prog zwar real auf der frisch gebackenen und bestückten Platine den PIC nach Tastendruck die richtige LED ansteuern ließ, das Simulations-Prog aber standhaft die Tastendrücke ignorierte.
Grüße, picass