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

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

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

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)

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

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!

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

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

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